Microservices

Cannot agree more with this based on experience of small startup. Let's say, you want to develop a mobile app and REST API for it hosted somewhere in cloud. There's so much hype about it, so you want to do it "right" (it's right indeed, but for some distant future until which your startup needs to survive). So, the possible solution is to take some common stack, like Spring Cloud, and build a number of microservices with service discovery, config server, OAuth and API gateway.

It appears, it's not so easy: 1. First, documentation as always is not the best, and you'll have to spend time figuring out how to wire together different parts of the system and build various configurations of it for local development, CI build and production. 2. Then, there's debugging issue. Once you've figured out how to work with Docker (good news, it's really easy today), you may want to do some debugging in IDE, but it becomes really painful to launch everything correctly with attached debugger if the services interact with each other. 3. Finally, it's production deployment setup and associated costs. Besides the complexity of deployment, do you really want to pay for 14-20 EC2 instances at the time of the launch of your service and burn the money on 0% CPU activity? It will take months, probably years to get user base sufficient for utilizing this power.

The better approach is to develop single server app with future scalability in mind. You can still have separate components for each part of domain, you just wire them together at packaging time. This server app still can scale in cloud, with correctly set up load balancer and database shared between nodes.

Fortunately, we spent not much time on building microservices (about 1m/w to figure out the costs and benefits) and were able to refactor the code to simpler design, but many developers should not care about them at all at early days of their company.

A interesting article with some good points. I think the important takeaway is understanding that monoliths are probably better for smaller companies, with less total code, and fewer total engineers. At small scales, the "costs" of microservices (network overhead, distributed transaction management, RPC complexity, dev-environment complexity) outweigh any benefits. A monolith lets you develop quickly, pivot, easily build cross-domain features, and is more efficient up to a point.

That said, I believe there is a point where monoliths begin to break down.

First, It is tough to keep code well structure in a monolith, and eventually things bleed between domains. That means, as mentioned, engineers must understand the entire codebase. This isn't practical for 100k+ LOC codebases. Strict boundaries, in the form of interfaces, limit the scope of code that every engineer must understand. You probably still need gurus who can fathom the entire ecosystem, but a new eng can jump into one service and make changes.

Second, deployment is a mess with any more than a few hundred engineers on a given code base.

Third, it becomes increasingly difficult to incrementally upgrade any part of your tech stack in a monolith. Large monoliths have this tendency to run on 3-year-old releases of everything. This has performance and security implications. It also becomes difficult to changes components within your monolith without versioned interfaces.

Fourth, failure isolation is much harder in a monolith. If any portion of code is re-used between components, thats a single point of failure. If your monolith shares DBs or hardware between components, those are also points of common failure. Circuit-breaking or rate-limiting is less intuitive inside of a monolith then between services.

TLDR; start with a monolith, migrate to micro-services when it becomes too painful.

Hi, author here - thanks for taking the time read it.

You're not wrong in that this article is meant to point out the pitfalls of the approach, and to advocate for understanding before diving into a particular architecture.

It's meant to give people things to consider before deciding breaking things into "microservices" is the right thing for their engineering org at that time.

I attempted to note several times that my intention was not to say "Microservices are bad", but rather "Please don't dive in before you consider the trade offs". It's not as simple as some folks might have you believe, so I felt it was valuable to have a "lessons learned" type retrospective coming from someone who has been involved in both approaches.

Thanks for the feedback.

In my experience scaling a monolith just costs more (i.e. hosting costs). Our product, when we started, was quite expensive to run at our high traffic times, but we were eventually able to cut our costs drastically by breaking certain pieces out into services.