As an engineer, I like the idea of microservices. The microservices architecture is the ultimate playground for distributed systems. Despite all the nice things that come with microservices architecture, I want to argue that startups really don't need microservices. I was lucky enough to see SOA, monoliths and microservices throughout my professional career. Today, microservices are receiving lots of buzz, and many big and small companies are jumping on this overhyped bandwagon. Microservices is a good thing, it's a great example of what the future might look like; however, if you're just starting out with your tech company, you do not need them.
What are the goals of your early stage company?
There's really only one goal of any company: to make money. This is even more important when you're small and want to get to the positive cash flow as soon as possible. To achieve positive cash flow, startups need to do these 3 things:
- Figure out what people want.
- Build what people want.
- Sell what people want.
As you can see, microservices is not even on the list. The product can be built using any tools or architecture available. Getting to market fit will be accomplished by some sort of agile process on tight deadlines. If we look at VC backed companies, that's usually the case. Bootstrapped companies will focus even more on sales and customer acquisition than an organization that just received cash injection. They are much more leaner than a "normal" startup that's already funded.
Microservices require tons of upfront investment from your engineering team. Such investment does not align with the goals of an early stage company at all. The process of building, testing, and selling the product will become the force controlling your engineering efforts.
But aren't microservices about agility, fast iteration and fast launches, isn't this what startups want? Yes. However, they do not work at this stage of the company and I'm going to tell you why in the next section.
Microservices are nice on paper, but extremely complex in reality
Here's what Wikipedia has to say about microservices:
In a microservices architecture, services should have a small granularity and the protocols should be lightweight. A central microservices property that appears in multiple definitions is that services should be independently deployable. The benefit of distributing different responsibilities of the system into different smaller services is that it enhances the cohesion and decreases the coupling. This makes it easier to change and add functions and qualities to the system at any time. It also allows the architecture of an individual service to emerge through continuous refactoring, and hence reduces the need for a big up-front design and allows for releasing software early and continuously.
Many good bits in the excerpt above. Small, lightweight, loosely coupled, cohesive, extensible, offers fast and early software releases. All of this sounds exactly what a startup needs. Wrong. Getting up and running with microservices will incur a significant engineering tax. Here's what goes into the microservices tax:
- Easy deployments and provisioning. When you step into the land of microservices you must build tools to aid you with deployments and provisioning. Tooling is required for you to launch new services fast and iterate on new features.
- Cost to run. Microservices require additional resources just to run several of them. This includes extra machines for routing, service discovery and orchestration, and databases for each service.
- Monitoring. Not just related to microservices, metric collection and analysis is very important to service debugging. It is much more difficult to debug distributed systems.
- Service discovery. By definition microservices are loosely coupled. You need to have a way to communicate with other services and know how to find them.
- Service orchestration. Service orchestration is hard. You need systems or tools in place to figure out where the service should be run.
- System complexity. When choosing microservices, you are choosing the simplicity of a single unit over the simplicity of the system as a whole.
- Bus factor. If you have 12 microservices in a small team, you probably have a bus factor of 1 per service. Given that it's easy to launch new service, it becomes easy to fragment knowledge of your team.
- Testing. Microservices is about protocols and communication. You must have component tests and more importantly integration tests. Achieving end-to-end testing is very hard when you have many moving pieces.
- System performance. When looking at single unit benchmarks, you're probably ok. The system as a whole will perform poorly if not finely tuned.
The requirements I mention above are mostly operational requirements, and there are many more things that go into this tax. The worst part is that you have to pay this tax upfront. You can try and evade some of the points that I brought up, but you will have to pay this tax later as part of your technical debt. It's already easy to accumulate technical debt at a startup and microservices is just a another factor in the equation.
A popular pro-microservices stance is that it solves some problems better than other architectures. I advise you to read Microservices - Please Don't, if you feel this way.
I haven't seen a single startup that has implemented microservices correctly. There are many right approaches and movement towards correct solutions, but it's usually 80% there and missing the important 20%. We are also seeing a large number of new companies popping up that are all about solving problems for microservices. The concept is fairly new outside tech giants such as Google and the entire ecosystem is lacking tools required to run microservices.
Invest in foundations
This brings me back to this quote by Paul Barham on distributed computing
You can have a second computer once you've shown you know how to use the first one.
Good engineering is not about building distributed systems. This is even more true in a startup environment. It also does not mean that you should ship whatever code you can. That's just irresponsible. However, it is much easier to argue for software correctness, stability and customer satisfaction than it is for reducing technical debt introduced by microservices. The product wins in startups -- infrastructure loses.
Investing in strong foundations for building software is more important than going microservices from the start. This includes code structure, libraries, docs, right language and technology choices.
Microservices are good when you're a big company able to make huge investments in infrastructure. Going microservices first is the worst thing you can do as an engineering team at a startup.
Hut for macOS
Design and prototype web APIs and services.