If you’re thinking about microservices for an MVP, you’re probably doing it wrong

This stems out from a conversation in the Slack group for the Philippine Tech Hackers (or Phackers). There was a question in our #architecture channel about starting an MVP using microservices, which sparked a good discussion about when to use one or not.

“Stacks of shipping containers in the Port of Barcelona” by Igor Ovsyannykov on Unsplash

The microservice ‘movement’ is fairly new — Martin Fowler describes it as ‘the hot term in 2014’. In it’s basic definition, it is a bunch of small applications grouped together to form a complex one (of course we all know it goes much deeper than that, but for simplicity’s sake, I’ll go with that).

So back to the discussion — someone asked if it was a good idea to go the microservice route for an MVP. Just to be clear, this discussion stemmed from the fact that they are building a service from scratch and they are planning to do it using microservices. That person was questioning if going microservices first was the right decision with the main reason being future scalability.

A lot of people have chimed in on this and there was no good case for going microservices first. Here were the main reasons:

Too complex to start with

If you are building a Minimum Viable Product, the most efficient and fastest way is the shortest path — the path with least resistance. Now, you can say microservices are easy to create since you will be creating smaller pieces, but think about the integration. That means you multiply each of your tasks by how many your services are. For example, if you were planning to create 5 microservices, you will be building 5 separate test suites, deploy scripts, and repositories — not to mention you will also be monitoring all 5. If you weren’t planning on doing that, then you’re doing microservices wrong and should just go monolith.

Another thing is when a spec changes. We have all been there (or you will be!) — you’re bootstrapping a green field app with well written specs and suddenly, there is a change in the spec. Everyone scrambles to change it and all is good. Except if you’re using microservices. With microservices, each change will need to propagate to another service using it, which brings me to the next point:

Team management will be hard

Let’s start with a small team. Imagine 5 people each doing their own service. Integrating them would be a nightmare at the start. How would you talk to a service still being built by someone on your team? You can assume certain inputs (or outputs) at best, but that’s it. Remember the spec change I mentioned above? Each change means you will keep changing your pacts and APIs while developing and that adds to the time spent exponentially.

When pacts are broken, fights break out! Photo by CloudVisual on Unsplash

Okay, you have a big team. Instead of things actually being easier, now you get to manage four times more people. This is all well and good when you have a definite and straightforward goal — say, when breaking an existing monolith into microservices, but starting with it? That means you need to update all twenty people every time something changes. And again, how often do specs change during development?

It is premature optimisation

We all know of that term. Basically optimisation without measuring anything — e.g. “I think we will be having lots of traffic on the get go, so we need microservices”. First of all, monoliths can scale pretty well too (some even easier to do than microservices). Second, this is based on speculation and usually when we optimise, we base it on existing measurements. Take note though that there’s a difference between premature optimisation vs preparing your architecture to be fast and scalable. In my opinion though, as an MVP, a monolith can easily be scaled as well as a microservice, so going the microservice route with the sole reason of being fast and scalable is pretty much pointless.

There were a lot more reasons, including a link to Martin Fowler’s ‘Monolith First’ article which has more in-depth insights than I could ever say. Please read it if you haven’t and re-think about your decision. Personally, I think that 95% of the time, the right choice would be a monolith for an MVP (again, I need to stress that the specific question was for an MVP). There is a huge difference between an MVP and a final product. If you plan to launch a final and polished product at the get go (and you have the time and resources for it), microservices MAY not be a bad idea. Really depends on your goals, time, and budget. I give the remaining 5% chance the benefit of the doubt that somewhere, somehow, microservices IS the answer for an MVP.

With that, I will impart two personal experiences regarding microservices in the last couple of years. My first experience was in my current company, where we built an epic feature that was supposed to be our flagship product. It was my first project to boot, and we have been discussing a month (a bit far too long!) on how to do this properly.

We have initially discussed this as a microservice. Before that, all our features were hosted under one huge Rails 3 monolith. We thought long and hard and we were all convinced that microservices would be the best way to take. A little over 2 days before we started, my boss had a change of heart and mentioned it might still be a good idea to go monolith.

First, that meant we only needed to monitor the site (like in my first point). Second, it also meant we won’t be dealing with any new technology or stack, just adding to our current Rails stack. Lastly, we were preparing for changes — we knew there would be a LOT of changes while everything was being implemented so we went monolith.

And it was a good decision. There was a time when there was a debate over where a birthday field should go. Moving it wasn’t trivial: we had to move it into another resource, check tests, and fix all integration tests. The birthday field was changed no less than three times during development (before launch) and maybe a couple more times AFTER the launch. Imagine having a microservice for that — we would have been changing the two applications every time someone thought of moving that field some place!

What about monolithic microservices?! (“Clouds over iconic Stonehenge rock formations” by Inja Pavlić on Unsplash)

My second experience was a bit more recent. I volunteered for an event called FLOW PERTH, and the project was to help Cahoots, which was a non-profit for helping kids and young people living with a disability. There were (by my count) probably a little over 30 volunteers so the plan was to split into groups and then help out one staff with their tasks (either by making a service or something) or another part of the site.

Now given this problem, ANYONE would have thought of microservices first. Why? There were multiple, independent teams. Team A did not need anything MAJOR from Team B. BUT each of the projects will be integrated into the existing site. Also, each team had different levels of experiences and languages (some knew Rails, Node, or Java).

We were all supposed to do this in a day, like a Hackathon — which was well and good, except I think we were all very optimistic (I was pretty stoked to volunteer and I would assume everyone else was as well!) which led to over-promises. When the time came to integrate them all together, everything was incoherent. Each part was all good by itself, but the UI/UX was just not there. We had a styleguide (I was tasked to do the front-end) but jumping into each project with different implementations was a nightmare. One was a node app with angular and Typescript. Another was just a simple HTML/CSS app with some jQuery — even with a unified styleguide, copying the CSS over to each app was inefficient.

Which led us to just munge everything together into a monolith. Everything was easier now and UI/UX was the same. We just had to pick a common language that majority knew (node) and we chugged along.

I know some developers who just LOVE microservices. I am one of them. They’re great to implement and use, but for an MVP, it’s really just not the right tool. Even then, it is great to ALWAYS think about what you are building. Think, rethink, and rethink some more. Ask yourself “Why?” at least five times. Even then, question your decision — do you really think that microservices is the answer, or is it just because you want to use it? Are you deciding on a buzzword, or a solution to a problem that monoliths can’t solve?