Tadas Vilkeliskis

Your startup does not need microservices

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:

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:

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.