Microservices are small and autonomous services that work together. Microservices have the following two characteristics:

1. Microservices Do Only One Thing & Do That WELL:

Within a monolithic system we try hard to ensure that our code is cohesive, often by creating abstractions or modules. Cohesion, which is the drive to make the related code grouped together, is an important concept when we think about microservices. Robert C. Martin states while defining Single Responsibility Principle “Gather together those things that change for the same reason, and separate those things that change for different reason”. This is very observed in the Microservices architecture. Microservices employ this principle for independent services. Microservices focus service boundaries on baseness boundaries. By keeping each microservice focused on an explicit boundary, engineers effectively avoid the temptation for it to grow too large, with all the associated difficulties that it can introduce.

2. Microservices Should Be Small:

Often a very common question asked about microservices is how small a microservice should be?

Below are some of the ways that precisely define it:
  • A microservice should be something that could be rewritten in two weeks.
  • Ask yourself, if the system you are working on is too big and you would like to break it down? If the answer is yes, then that system is definitely not of a size that a microservice should ideally have. Once a piece of code no longer feels too big, it’s probably small enough.
  • The codebase of a microservice should be small enough to be managed by a small team. If it is too big to be managed by a small team then breaking it down is very sensible.

3. Microservices Should Be Autonomous:

A microservice is a separate entity and should be deployed as an isolated service. It would be better if we avoid packing multiple services onto the same machine. It has a lot of benefits one of which is if a machine is down then only one service gets impacted.

All communication between the services themselves are via network calls, to enforce separation between the services and avoid perils of tight coupling.

The most important characteristices that microservices should have is that the services need to be able to change independently of each other, and be deployed by themselves without requiring consumers to change. Developers of microservices need to think what the services should expose and what should be hidden. If there is too much sharing then the consuming services become coupled to the internal representation of the microservices. This decreases the autonomy of the microservices as it requires coordination with consumers while making any changes.

Microservice exposes an Application Programming Interface or API and collaborating services communicate with the microservice via these APIs. Developers of a microservice should think about what technology is appropriate to ensure that this itself doesn’t couple consumers. This may mean picking technology-agnostic APIs to ensure that we don’t constrain technology choices.

So, to summarize the autonomy feature of the microservices, the golden rule is asking yourself as a developer “Can you make a change to a service and deploy it by itself without changing anything else or without any coordination with the consumers of your microservice?” If the answer is no then your microservice is not autonomous and will lack many of the advantages that the microservice architecture provides.

We also need to keep in mind that the microservice architecture did not emerge and became popular all of a sudden. It is a natural outcome of the continuous development of the software development and kind of problem faced while managing systems as they become larger and larger and challenges faces while trying to scale system to handle enormous loads from increased user base and consequently making the systems distributed. Microservice has emerged from the following world:
  • Domain-Driven design which tells about how to represent the real world problem in our code and modeling the system according as per the requirements. Please refer to Eric Evans’ Domain-Driven Design (Addison-Wesley) for more details.
  • Continuous Delivery which gets our software into production more effectively and efficiently, instilling in us the idea that we should treat every check-in as a release candidate.
  • On-demand Virtualization which allowed us to provision and resize our machines that talk to each other at will.
  • Insfrastructure Automation which along with on-demand virtualization gave us a way to handle our machines at scale.
  • Small Autonomous Teams: Many large, successful organizations have espoused the view of small teams owning the full lifecycle of their services.
  • Systems at Scale: Some organizations have successfully built anti-fragile systems at scale that would have been hard to comprehend a decade ago. The concept of anti-fragile system is based on harnessing the benefits of failure and disorder. For example, Netflix incites failure to ensure that its systems are fault tolerant by using their Simian Army of failure bots, the most famous of which is Chaos Monkey, which during certain time of the day will turn off random machines. Chaos Gorilla, which is used to take out an entire availability center (the AWS equivalent of data center), and Latency Monkey, which simulates slow network connectivity between machines, are also worth mentioning.
Many organizations have found that by embracing fine-grained microservice architectures they can deliver software faster and embrace newer technologies faster. Microservices give us significantly more leeway to react and make different decisions, allowing us to respond faster to the inevitable change that impacts all of us.

Microservices are actually a specific approach for Service-Oriented Architecture or SOA in the same that Scrum is a specific approach for Agile Software Development.

Lastly, we need to keep in mind that microservices are no free lunch or silver bullet, they have all the associated complexities of the distributed systems. An engineer coming from a monolithic system point of view will have to get much better at handling deployment, testing and monitoring to unlock the benefits of the microservice architecture. He also needs to very wary about getting things like distributed transactions and CAP Theorem right.

The above content is written by:

Abhishek Dey

Abhishek Dey

A Visionary Software Engineer With A Mission To Empower Every Person & Every Organization On The Planet To Achieve More

Microsoft | University of Florida

View LinkedIn profile

If you have any feedback, please use this form: https://thealgorists.com/Feedback.

Subscribe to Our Youtube Channel

Follow Us On LinkedIn