Stop the Micro-Services insanity

Ok, I get having a monolithic app isn’t ideal. And I get having to deploy your 25k LOC code-base for a CSS change isn’t ideal, but I feel some people have gone too far in the other direction.

Case in point, I was recently looking at an acquaintance’s startup which had maybe, 10 users. They had zero or no usable functionality on the app. And yet, they had 5 micro-services on the back-end. And the icing on the cake — each micro-service had it’s own DB and it was something completely different than the rest. Neo4J, Postgres, MongoDB. I mean come on!! How crazy do you have to be do design something like that, with no usable functionality on the front-end and no active users!

YAGNI

If I could count the times I’ve heard — “You ain’t gonna need it”, “Keep it simple stupid” or “Premature optimization is the root of all complexity”, I’d be rich. And yet, people consistently ignore this. The most common pattern I’ve seen — they have worked on a project where they had to scale the system in a certain way and they are applying that over here.

The downsides of micro-services

As I grow older, I realize nothing in life is free. There is a price to pay for things and a sensible thing to do, is weigh the price against the benefit, for your situation and make a judgement call. Micro-services are not the silver bullet that is going to solve all your web-scale/IoT scale problems. You cannot just throw micro-services at the problem and hope it magically resolves itself. It just doesn’t work like that.

Here are couple down-sides with going the micro-services route:

  1. Slows down development time: It’s a lot harder to implement features when you have to look at an API rather than a Model object. Throw in some access_token crap on it and it becomes almost unusable.
  2. Versioning Hell: You soon realize that one version of a micro-service doesn’t talk to another and end up coming with some git branching strategy to keep things in sync. In other words, more headache.
  3. The API spec: It’s no longer enough to have an API spec for your back-end so your Javascript front-end knows what it is talking to. Now, you have to maintain APIs for all your back-end services, to prevent point #2, Versioning Hell.

The sane approach

Just build a monolith app. It’s fine and it’ll give you amazing mileage and most importantly you’ll be able to build out features and get those users a lot quicker. Once you do hit scaling issues, then by all means break out your app into smaller pieces. It’s a lot easier breaking out a well-structured app than working on a poorly architected micro-services based one.