Microservices Architecture

Microservices Architecture, one of today's buzzwords in the developer world, is a growing trend not only by small-time companies, but also by high-profile corporations. With the increasing number of users that has Internet access, be it human beings in their mobile devices, robots, self-driving cars and the software they run on, a drastic change in software implementation is needed to adapt for these users' increasing amounts of data. In the recent years, it became one of the preferred way in developing enterprise applications.

What is Microservices Architecture?

Microservices architecture is a method of developing software like a suite, or in other words, as a collection of small, modular and isolated, and independently-deployable "services". Each of these "services" , or mini-applications, running in its own process, performs a specific task and communicates through a lightweight mechanism that connects them together and function as one.

It may seem daunting to developers who encounter this for the first time, but let us give them the benefit of the doubt. If you are one of these people, this is the good time to learn about this architecture.

Monolithic vs Microservices

Monolithic vs Microservices architecture on a software. Courtesy of SourceAllies Blog (http://blogs.sourceallies.com/2015/11/microservices-in-practice-the-positive/)

Using the example above, Monolithic software combines all of the functionalities of the application into a single "module". It would mean that these functions are tightly coupled, dependent with each other, and runs on only a single process. It would also mean that when something goes wrong with one of these functionalities, the whole application can also go with it and crash. It would be an undesirable outcome.

Whereas the Microservice software runs each service on their own process, independent of each other. When something goes wrong with one of the "services" and crash, it will not affect the other services though it may or will affect your application over all. These individual services are independent and can be deployed individually, meaning your application can already start running even though some parts are still missing or is still on the way to be deployed. They can also be stopped and removed at will, without crashing the whole system.

Pros of Microservices

Developers can develop and deploy services at their will. There's no need to implement functionalities in order since they are independent of each other. For example, authenticating users can be implemented later than payments because the team determined that this is easier.
A microservice can be implemented by a small number of people. Since each service is isolated to another and supposed to be performing a specific function, use cases can be narrowed down, thus developing it is easier.
Microservices can be coded in different programming languages (a win!). In a monolithic application, one can only decide on a single programming language to use (e.g. PHP, Ruby). On a microservice architecture, one can choose the best programming language for the job (e.g chat service can use NodeJS + NoSQL, R on number crunching, PHP on generating reports). This ensures efficiency and more performance could be squeezed out of your hardware.
Easier to understand by newer team members. Since a microservice cover only the minimal part of the application, new developers can easily grasp and participate, and can become more productive quickly.
Faster deployment. Microservices are small, so it's only obvious that they also start faster.
When something needed to change, only the affected microservices are needed to be modified.
Better fault tolerance and isolation. When a microservice encounters an error, the others will still continue to work, and not crash the whole application (though it may affect the overall functionality)
Scalable. Need faster number crunching? Scale the microservice responsible for that (e.g. add more hardware to handle the load). It's cheaper because you don't need to scale the entire application.
Reusable. Did you create a microservice that handles authentication for your booking application? Did you start creating an e-commerce one and needs to implement authentication? Why don't you reuse the authentication microservice from your booking application? You just made an SSO service!
You can change your tech stack at will. If determined that your microservice uses the old tech stack and you need to update it, it will not break your other services.
If you don't know what kind of devices or applications that will use your application, use microservices. Since your application can use standard API calls such as REST, there is little worry that your application is incompatible with its consumers. This is very useful on IoT, where there could be a number of unidentifiable devices that can use your application.

Cons of Microservices

Testing can become complicated and tedious. This can be remedied by automating the tests though.
Information barrier. While microservices are designed to be indepedent of one another, still there will be the desire to share code. That is why it is important to determine the shared libraries in order prevent duplicate code across microservices, for easier maintenance.
Added complexity because developers now have to check for network latency, fault tolerance, recognized message formats, load balancing, and many more. Though it's better that developers should always consider such things whatever application they are building.
Possibility of duplication of effort. Microservices can possibly implement the same things. This is why communication between teams is important.
The more microservices being added the more complex your application will become.
Developers will have to consider the implementation of a messaging mechanism in order for the microservices to be able to talk to each other. This is not much of a problem nowadays, since there are now softwares created to address this problem. A good example would be RabbitMQ.
Handling use cases that spans different microservices could require communication and cooperation between different teams. This is not much of a bad thing though.
Increased RAM consumption. Since each microservice runs it is own process, it will also require more memory in order to operate efficiently. Good thing microservices can be scaled independently.
Dividing the application to individual microservices is a challenge. It requires extensive planning.
So many Git repos! Each microservice might require its own repository. You will have to pay GitHub or similar hosting services to accomodate multiple private repos for just a single application! This is not a problem if your company has its own private Git server. But if your application generates much profit, the GitHub fee is a very little price to pay.

There would always be cons for every software architecture, but in Microservices architecture, the pros always outweigh the cons. Is it worth it? Probably, if you are going to convert an existing monolithic application in microservices. But if you are going to create one from scratch it is more than worth it to implement it into microservices in the very start.