Siren Song

Photo by Jason Rosewell on Unsplash

Why Micro services ?

Photo by AZGAN MjESHTRI on Unsplash
  • Be agile and respond to business needs quickly.
  • Scale out each service of the whole individually
  • Clear and explicit boundaries of subsystems — helps keep things cohesive and devolving into a Big Ball of Mud over time
  • Scale out from a human standpoint — it’s easier to bring on new people if they have to understand a smaller part of the whole at a time than the entire 800 pound gorilla.
  • Avoid technology/platform lock in.
  • Avoid having to make either/or technology decisions in the beginning when you/your team may not understand the problem well enough yet

What do you Lose ?

Photo by Felix Mittermeier on Unsplash

Compared to a monolith, you lose a lot of simplicity.

  • Deployment is a lot more complex — more moving parts all around and the failure to deploy a single service properly could lead to your qa (or any dependent teams) twiddling thumbs waiting for the system to be available.
  • Development is more complex — esp when you have a change that isn’t actually limited to one or two services
  • NO ACID — no transactions (in the traditional sense) and building systems that compensate for failure is not the same as a saying BEGIN TRANSACTION/COMMIT TRANSACTION
  • Understanding the system is more complex — since locally observing a single service doesn’t convey the full picture.
  • Debugging is harder — since all you’re going to see is a bunch of api calls at a service level. To understand the entire big picture you need to build/instrument good tracing.
  • Profiling — It’s harder to understand the performance profile of your application as a whole. A single service’s minor failure/increased latency could have a snowball effect upstream. Gaining a clear understanding of this and solving these problems isn’t going to happen without building good instrumentation in your services.
  • Testing the system is harder — While you can test individual api calls, you need to be able to orchestrate entire flows across the system. Doing this in a distributed environment is harder.

You need to be this tall…

Photo by Nicolas Ladino Silva on Unsplash

Hmm.. so what do you need to be reasonably sure that going the micro services way gives you some of the promised benefits?

And what happens in the real world

If I hadn’t seen it first-hand time and again, I’d have thought it was an exaggeration. However, the number of times it hits home is amazing.

  • Using micro services as an excuse to not design the system at all.
  • No strategic view — architecture/design in sprints in the name of agile! :)
  • Coupling all micro services with a single database
  • Deploying services by hand/no CI/CD in place.
  • Zero monitoring
  • No log aggregation
  • No ability to trace calls through the system
  • No tests — either at a service level (forget system tests)
  • Building everything as synchronous service calls.

So stay away from microservices ?

Photo by Danielle Dolson on Unsplash

We cared a lot more about how our REST API footprint looked like, we cared about how our domain was structured but we didn’t care if we were ‘doing’ microservices.

We had a good CI and CD pipeline on day 1 when setting up the solution structure.

We were our own Dev team and Ops team and everyone was responsible for their code in production. Engineering culture’s important!

At our peak we were releasing to production more than 5 times everyday

Summary

Photo by Alvin Mahmudov on Unsplash

However, this is extremely dependent on having clear boundaries of responsibility between the services.

Once you grow beyond a monolith (team size, customers, revenue etc., you can tease apart services and have a much more realistic chance of benefiting from microservices.

A microservice architecture song playlist on Spotify

If you enjoyed this blog post, please clap 👏(as many times as you like) and follow Here and LinkedIn if you can.

Disclaimer:
This is a personal account. The opinions expressed here represent my own and not those of my employer — past, present or future.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Monologues

Monologues

I love to write about Philosophy,Humanity,Music, Poems and Software Architecture. www.linkedin.com/in/santoshakhilesh