The hype microservices. Should I switch to it?

Apr 12, 2019 • ☕️ 4 min read

Over the last 9 months, I have invested most of my time developing a real estate social networking site which using Microservices architecture. After much reading, note taking, white-boarding, and many hours coding, I feel like I have achieved a level of understanding such that I am ready to take the first step. Allow me to share what I have learned about this.

No country for old men

Back in the olden days, applications were built monolithically. The application likely consisted of the web server itself and perhaps some kind of data storage system and were just built and packaged into one or two binaries. These binaries were then uploaded to a server rack and run directly on the machine. This was fine for the internet of the 80s and the 90s

With monolithic architectures, all processes are tightly coupled and run as a single service. This means that if one process of the application experiences a spike in demand, the entire architecture must be scaled. Adding or improving a monolithic application’s features becomes more complex as the code base grows. This complexity limits experimentation and makes it difficult to implement new ideas. Monolithic architectures add risk for application availability because many dependent and tightly coupled processes increase the impact of a single process failure

The hype microservices

Microservices are an architectural and organizational approach to software development where software is composed of small independent services that communicate over well-defined APIs. These services are owned by small, self-contained teams.

Monolithic vs Microservice

Why now?

  • The first steps to reduce cost of delivery focused on process automation
  • The DevOps movement on the wave of AWS and GCP
  • The age of containers
  • Advances in CPU and network technology
  • Advances in storage & database technology


  • Agility: independent teams that take ownership of their service
  • Flexible Scaling: independently scaled to meet demand for the application feature it supports
  • Easy Deployment: enable continuous integration and continuous delivery
  • Technological Freedom: choose the best tool for each job
  • Reusable Code: a service written for a certain function can be used as a building block for another feature
  • Resilience: service independence increases an application’s resistance to failure


  • Additional complexity of creating a distributed system.
  • Testing is more difficult
  • Inter-service communication mechanism.
  • Using distributed transactions is difficult
  • Requires careful coordination between the teams
  • Deployment complexity
  • Increased memory consumption


When you start looking into Microservices, you enter a rabbit hole that’s absolutely massive. It makes Alice in Wonderland seem like a piercing. You quickly learn that you will need to manage all of these microservices and balance the load whilst monitoring everything that is happening. Oh, don’t forget that you’re going to need to care following topics which I strongly believe deserve another indepth posts

  • CICD
  • Deployment
  • Logging
  • Monitoring
  • Service Discovery
  • Communication
  • Load Balancing
  • Persistence
  • Security
  • Testing


  • Microservices are a business solution, not just a technology solution
  • Treating microservices as splitting code layers into docker-ized boxes can lead to “death by a thousand cuts.”
  • You don’t need microservices to run multiple instances of a service or worker. Good monoliths can also scale for some classes of problems
  • Microservices are a culmination of multiple engineering practices. They have a steep curve of learning, unlearning, and transformation


Before, people used to have this one application, that some parts of it were complex, and now this complexity is all over the system in different services and distributed between multiple services

One challenge is deciding when it makes sense to use it. When developing the first version of an application, you often do not have the problems that this approach solves. Moreover, using an elaborate, distributed architecture will slow down development. This can be a major problem for startups whose biggest challenge is often how to rapidly evolve the business model and accompanying application

In my opinion sooner or later you’ll use microservice architecture, the point is how much complexity you want to implement and when to implement.


More reading

A Complete Guide to JavaScript Tooling

Want to become a productive JavaScript developer? Confused no more with a complete guide to JavaScript tooling systems

The Opinionated Decision on CSS Resets

On debate of different strategies to fix inconsistent default styles across browsers using Reset, Normalize or Custom CSS

A deep look at Apple developer ecosystem after WWDC 2019

I have a tradition to write a review of WWDC event 2 weeks after it happened. As an iOS developer, this event was easily one of the most exciting events of the year to me

React Admin

The best React framework to build admin dashboard which adapts to any backend