What are microservices.

Most people understand what a monolithic application is, a single application that lives in a single codebase that shares a single database that is deployed altogether and that spans all logic in the business domain.

Also most people tend to confuse microservices with SOA(Service Oriented applications). A SOA is an architecture that separates different parts of the business logic into different services that communicate between them in order to execute the application task successfully.

Now what are microservices, isn’t the definition of SOA the same and microservices? Well microservices are an implementation of SOA the big difference here is that microservices each is a completely independent deployment unit. Not only each microservice run as an independent process but it access isolated data (it has its own database) and can be deployed and changed independently without touching any other microservice. Several times I’ve seen teams that say they implement microservices implementing tightly coupled SOAs or deployment monoliths.

So how do we know we are implementing a microservice application:

• Each service is completely isolated from the others in the codebase: A code change of one microservice only requires said microservice to be recompiled and redeployed and none more. If you find yourself having to compile different services from changes to a single feature then you have a tightly coupled SOA.
• Each service is running in it’s own environment: if you are using VMs/containers it means each vm/container/pod is running a single service in an isolated local environment. If you find more than one service within the same vm/container a failure of the machine/container will not only affect a single service but multiple of them at the same time hindering application performance.
• Each service has isolated data access according to business models: each microservice will have it’s own database, even if other services require the same data they should access it via the microservices that holds the business logic associated to it. If you use a single database for multiple services once again if that DB fails multiple services will fail at the same time hindering the performance of your application.

Why use a microservice architecture.

Microservices usually come with a cost of increased complexity and beforehand thought put into them. So why use such an architecture:

• Sustainability: Microservices are mor maintainable in the long run. Different teams can focus on the development of only certain services without interfering with the development of others. This also means a microservice is easily replaceable, you can change the complete codebase of a microservice as long as you keep the same contracts/api that was offered to other services. This isolation also means that bugs can be pinpointed to a microservice alone instead of the possibility of them being anywhere on the codebase of a monolith. Dependencies are not a problem between microservices since two microservices will not share the same business logic dependency since they have clear boundary between them.
• Velocity: Since the microservices are completely independent from each other, each will have its own deployment pipeline. Having complete independency means teams can deliver new features faster and without fear of disrupting the complete business when deploying their microservice. Not only that, because of the isolation required between microservices it also means that you can recover from incidents faster, if a microservice fails it is easier to rollback or restore a single microservice than the whole application.
• Free choice of tech stack: Another advantage of microservice architectures is that it allows teams to select and easily change between technologies that better adapt to the requirement of each microservice. You can have one service in java, the other running some ML in python, another running optimized code written in C.
• Robustness: Microservices by nature eliminate single points of failure. And allow scalability in a fine grained scale, you can scale microservices that require more resources and downscale those that don’t. Also you can respond to traffic spikes scaling and downscaling on demand.

What size should a microservice have?

Microservice can vary from few lines of code to thousands. The answer here is relative: The max size a microservice should have is at most as big as the head of an average developer from your team. This means that the microservice can be at most as big as the biggest mental model an average developer in your team can hold in his head.

What are the costs and disadvantages?

Microservices sound great but what are the costs, and disadvantages?

• Increased operations effort: several microservices require multiple machines to run in comparison to a monolith which only requires one.
• They must use automation to create deployments and orchestrate running microservices.
• A change that spawns multiple microservices can be difficult to implement and require coordinate deployments for it.
• Latency increase, since a network communication has inherent latency to begin with compared to a local communication in the same machine.

TL;DR

Microservices can offer teams a lot of flexibility in choosing a tech stack, responding to traffic, scaling, and allowing a fast release cadency in software. This advantages are in part the reason many people and companies are deciding to use this architecture pattern. Nevertheless microservices come with a considerable degree of complexity. As such this is a choice, a choice that must be weighted and justified, often a simple approach can deliver better results easily.

Regardless multiple organizations and startups have shown how effective this architecture model can be. When the foundation concepts of this architecture model are well understood and properly implemented they can allow an application to be more than the sum of their parts.