Microservices vs David Heinemeier Hansson

Hearing that David Heinemeier Hansson had slammed microservices in his Rails Conf 2015 keynote was a bit disorienting as I was developing a microservice at the time. I leaned over to the other senior developer and said: “What’s his deal?” Toby Tripp, who had just watched the keynote, explained that when David’s team implemented microservices they had terrible trouble managing all the versions between 3 systems. “Isn’t that why we use a lookup call to get the URI-map?” I asked.
“Yep” he said.
“That and never remove a return key/value (pair), only add new ones until you can prove they are not used anymore” He added.
I returned to adding in some caching to our service calls. 

Later, I watched the video which is here:
https://www.youtube.com/watch?v=oMlX9i9Icno

David has a meandering style but he mostly discusses microservices between 43:00 and 52:00.  The “what’s in your backpack” stuff is all about his earlier zombie apocalypse metaphor that you can watch if you like.  He claims his team implemented microservices right, loved them on day 5 but hated ‘em in year 2 (paraphrase). I don’t understand how I will regret my microservice architecture decision if we implement HATEOAS (Hypermedia as the Engine of Application State).  You may remember HATEOAS as the thing from REST that all the eggheads complained was missing from Rails’ “RESTful-routes.” “Sure, the routes were REST but what about the discoverable URI-map?” they may have said.  They were, of course, right (jerks).

I’m not saying HATEOAS is perfect.  I was in the middle of adding LOTS of caching to our client so it almost never has to call our service for one of the two calls you must, at a minimum, make with a HATEOAS service. Why two calls? 
  1. To get the URI-map (A map of how to call the service for all resources)
  2. Actually make the call (Using the above map)
  3. What? There’s a 3? Yup, that second call could return another URI-map
  4. It could continue

I know this seems insane, to make 2 or more http calls for every one request, but the benefits outweigh the costs. Old calls will always work. Less bugs. More confident software.  Also, you can cache the hell out of all the URI map requests from the client side.  When you need to expire that cache you can do it upon release of new functionality because, this being a microservice, you own all sides of the interface. Just work it into your deploy script and you’re done. Extra bonus: No URI ever has a stupid v7 in it.  

The last call is a bit of a bummer over http. Even servers right next to each other in the cage have important amounts of latency for many services.  HATEOAS isn’t for every service. Although, with virtual machines, I run my service on the same physical box in another vm: Somewhat mitigating network latency.  Double Extra Bonus:  My service is purely functional so I can cache all of its responses forever. That bold claim, however, is another blog post.

Anyway, Tripp is leaving my team to go be the king of software at some company I refuse to promote out of spite. How would you like to work at Backstop Solutions? I’m looking for a senior Ruby dev with a bunch of Clojure experience but, to be honest, I don’t really expect to find one. So if you’ve got some decent Ruby skills and can learn Clojure while pair programming you should apply.  https://www.backstopsolutions.com/careers


Mention you read this article in the interview and you’ll get to see a man in a crazy shirt blush.

Comments

Andy Maleh said…
Don't mind David Heinemeier Hansson. He's a bit of a simpleton (in a good way), which is precisely the reason Rails is such an asset for the common developer (as opposed to the top 1% Comp Sci graduates).

He likes to make the most controversial opposite-wisdom opinions at Keynotes, probably to fire up the audience and keep them engaged at RailsConf.

Of course, some developers may say he is promoting bad practices, but then here is the catch about that! Only the developers that are not self-responsible-thinkers-and-analyzers, such as yourself, fall into that fly trap and hurt themselves if they blindly follow Dave's recommendations before the next Rails version addresses his concern (just think of how Engines were considered bad, Rails merged with Merb, and then boom, suddenly they became good and used in every library out there).

On a different note, too bad Tony Tripp is leaving your organization. Good luck to him.

Glad to know you're still chugging along (or maybe soaring?!)... Cheers!

Andy

May 3, 2015 at 7:26 PM
Post a Comment

Popular posts from this blog

What's a Good Flog Score?

I've been using Flog to measure the complexity of my Ruby code and I was wondering how others interpret Flog numbers. I'll go first with my opinions: Score of Means 0-10 Awesome 11-20 Good enough 21-40 Might need refactoring 41-60 Possible to justify 61-100 Danger 100-200 Whoop, whoop, whoop 200 + Someone please think of the children (note: these are scores for an individual method) The 20 - 60 range is interesting to me. Sometimes the complexity of what you're doing will justify the score and other times the method is in desperate need of refactoring. The highest Flog score I've seen in the wild was in the 300's. What's you're personal high and what do you think of my rankings? In other news, I've redesigned the look of my blog so if you only see my post through a reader you might want to stop on by, take a look, and tell me what you think.
Read more

SICP Wasn’t Written for You

The number of software luminaries who sing the praises of “ Structure and Interpretation of Computer Programs ” (referred to as SICP) is such a long list that you might think only a crazy person would take issue with it. However, to ignore SICP’s problems and continue to blindly recommend it seems just as crazy. SICP was the textbook for MIT’s introductory programming class and was a bit of a departure from other into to computer science textbooks at the time.  Wikipedia sums it up nicely:  “Before SICP, the introductory courses were almost always filled with learning the details of some programming language, while SICP focuses on finding general patterns from specific problems and building software tools that embody each pattern.”  Which sounds awesome, but does essentially say that abstract principles will be introduced before the nuts and bolts of a language.  If you think about that for a minute, you may see where the problems will be. When I was training to be a...
Read more

Point Inside a Polygon in Ruby

Recently my team needed to find out if a point was inside a given polygon and, as usual, we found some code on the internet that did what we wanted. And, as usual, there wasn't much explanation as to what it was doing. Here's the code (after we converted it to Ruby): 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 def contains_point? (point) c = false i = -1 j = self .size - 1 while (i += 1 ) < self .size if (( self [i].y <= point.y && point.y < self [j].y) || ( self [j].y <= point.y && point.y < self [i].y)) if (point.x < ( self [j].x - self [i].x) * (point.y - self [i].y) / ( self [j].y - self [i].y) + self [i].x) c = !c end end j = i end return c end end So, you know, it works and I'm grateful to somebody for posting it but we had no idea how it works. So we wrapped 2 tests around it (one where the point is not in the polygon and another where it is...
Read more