Why should you choose a microservice-based approach for your next project?

Microservices is the new king. All hail the king!!

I’ve been a Java developer for the past five years. Life’s all good. Then came micro-services to screw me up.

I first heard of microservices in a blog post on Medium around six months ago. I was hooked. I also develop in Python and Go. So it’s been easier to experiment with micro services.

P.S.: All content posted henceforth is my own opinion of the subject matter. Any humour or sarcasm is purely intentional.

What is/are Microservice(s)?

Software stacks can be broadly classified into two types.

1. Monoliths
2. Segmented (an easy word for Microservices)

There is a high probability that most of the developers have heard of, or worse, worked on a monolith project. It simply means that you take a giant box and dump all kinds of shit into it.

Microservices are a relatively new approach to software development wherein, you chunk out your project into primitive functional blocks where each block does one and only one function.

Are monoliths evil?


  1. Is your codebase large?
  2. Do you think some part of your code could be written better in another language? Say, Python?
  3. Do you face trouble when debugging, because a glitch early in the timeline blocks your development all down the lane?
  4. Is restarting your server / runtime troubling you with downtime because it’s too large to start up?
  5. Do you have too many dependencies which hinder you from working independently on one of the components only because it might break things elsewhere?

If you’ve answered yes to any one of the above questions, high chance that you’ll love working on Microservice based stacks.

How do you build this Micro …. thingy?

Aah. Now we’re talking.

Let’s discuss some thumb rules.

First solve the problem, then write the code.

Never start the project and then think about the plan. Always remember — real programmers write pseudocode.

If you’re wondering what’s a pseudocode, you probably should not be reading this article. I mean absolute offence.

If you’re able to jot down the pseudocode, half the job is done. Because writing down your plan in plain English is more like planning your holiday itinerary. It might help you categorise and mentally separate the different functionalities.

Broadly lay out the different needs you have for your project.

Next, if you have ’n’ functionalities that might be talking to each other, then you’ll be writing ’n’ microservices.

Now, when do you need to separate a particular service?

  1. Will the internals of the service have anything to do with the rest of your stack?
  2. Might you think of improving the service independently in the future hoping not to affect or break the rest of the services?
  3. Should the rest of the service gracefully continue to operate if this service goes down?

If you answer any of the above with yes, then chunk the heck out of it.

Program the needs one by one.

Start programming the modules one by one. Remember that you’re not doing any extra work by writing `n` services. You’re only writing many small services instead of one Hulk-sized service.

Once you’re done writing all of them, you now have tiny bits of services which do one thing best, and only that one thing.

Expose network Interfaces.

Now one might ask, you do you make them talk to each other?

Different people might opine differently on this. There are two ways to go about this.

  1. HTTP-based interfaces let your services ping one another, wait for the response, take back the result. Or if the remote service doesn’t respond back, gracefully timeout and continue doing other things.
  2. Queue-based interfaces where your services don’t need to wait for the response from the remote service. Instead, they deposit a payload with the remote service, and return to the main queue. The remote service can then push back the result onto a communicating-channel and notify the host service that it can now use the response.

You’ll mostly need the HTTP based interfaces. You can either implement a REST or a SOAP protocol-backed approach. If you’re daring and dashing, try out GraphQL — I heard that it’s awesome. Let me know how that works out.

If you might need a queue-based interface, there are plenty of choices like RabbitMQ, OpenMQ etc.

Give yourself a high-five.

I guess I’m done here. You can now take a deep breath.

So, what are the fruits of my efforts?

Coming right to that point. Now you’ve spent your time and effort building a microservice-based stack. What are the fruits you can reap?

Faster restarts

If you need to restart your services, you needn’t restart all of them. You just need to restart that service which you’ve updated — which brings me to my next point.

Independent development timeline

Development on one of the service needn’t block the others. Each of the services will now have independent version control, release timelines — hopefully much faster.

Better adoption of newer technologies

Injecting a major update in a monolith would be a tedious and a risky process. But when you have services which are tiny, you can easily update a dependency and make sure you handle a minimal number of changes within the service. Heck, you can even rewrite it in another language. I hear Go is the hot chick in the town?

Precise production support

If one of the services break down, the rest of your fleet remains up and running. So production support needs to spend lesser time debugging and fixing the bug in that failed service and bring it up quickly without much trouble.

Is there a pinch of salt?


Microservices sure are the way to go on, but there are some pins on the way.


As my friend Mukundan says,

Monolith is a pet bulldog, it’s scary — but you can tame it by parental care. Microservices are like twenty chicken which crap all around.

Microservices can often make you take a step back and start debugging a glitch (if any), because you have many code blocks at play here. You now need to maintain separate loggers for all services and coordinate between them in case something goes wrong somewhere.

It’s actually an exciting area of development. How do you manage one single logger instance to coordinate with all your services, keeping all your logs at one single place? Drop comments if you find anything interesting like it.

Safely fallback

It might be obvious now that there are lots of network calls between the services. It’s hence essential that you safely fallback if one of the services fails to respond or times out.

Breaking a flow just because another service is down, defeats the entire point here.


I’m done here. I guess you guys will start looking at Microservices as a viable approach to your next software project.

You’re welcome to post messages or drop me a mail at chaitanya.m61292@gmail.com if you want to chat up about technology, gadgets or anything at all. You can tweet to me too, at @iamunukutla.

By the way, I wish to talk to you guys more about this new dude named Docker. Will write on that soon.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.