22. 3. 2019
You probably already heart about the latest buzzword #microservices. Ask 10 developers and you are likely to get 12 different answers. So let's dig a little bit more into it and allow me to help you better understand this concept with some real world examples.
Microservices is architectural style that structures an application as a collection of loosely coupled services. In a microservices architecture, services are fine-grained and the protocols are lightweight. The benefit of decomposing an application into different smaller services is that it improves modularity. This makes the application easier to understand, develop, test, and become more resilient to architecture erosion. Source: Wikipedia
Basically microservice is a unique, independent piece of your business logic which is loosely coupled with the rest of the system. You can maintain and test it separately as well as deploy its own version to production. That brings you several benefits but few limitations too.
There are several reasons why developers adopt this architecture into their systems so much. The main of them are usually current monolithic applications which are hard to maintain, test and deploy. Also maybe you want to use a different programming language or framework for a single use case you have but the monolith is not allowing you to do that. Here come the benefits of microservices.
Microservices are small and contain only a limited amount of your business logic so it's much easier to maintain them or even rewrite them completely if you need. In such small codebase it is very quick and easy to perform changes and still keep the code clean. Also, documenting and testing the service is way easier. With well designed microservice architecture your system becomes more robust and reliable. If one service goes down the rest of the system can still work as expected.
Last but not least, big advantage is parallelism of work. With microservices you can easily decouple your new feature into smaller tasks. Even if they are performed on different services, they can be worked on simultaneously by the team. Smaller tasks usually lead to more accurate estimates and better architectural decisions.
Lot of small independent pieces that talk to each other bring of course several challenges which are necessary to mention. One of the biggest is of course code duplicity. Usually, it is at least some boilerplate code for logging, configuration and so on. This is not the end of the world because you are not changing those parts of your app so often. However, if you find yourself to copy & paste several files between services, it's good to start thinking about extracting part of your logic into shared library or so.
Another problem which you can face is increasing complexity of your system. Flexibility in scaling only specific parts of your system comes usually with more operational cost. Also testing the whole system end to end is getting little bit more difficult. In some cases it is not a huge problem and teams can handle it with ease. On the other hand make sure you understand all the consequences that come with growing numbers of microservices.
A good example of considering a monolithic architecture would be a start of a brand new project. at the beginning you usually don't know what features you will need in the future so it's totally OK to put your new project in a single codebase since you are working on MVP. When you start identifying clear use cases and understand better the problem you are solving, it's the right time to start thinking about microservices.
Speaking about monolithic software probably you are wondering: "How should I start?" Well, it depends on your current codebase a lot. However, let's mention a few techniques which you can apply to kickstart this process.
Usually the best piece of business logic you can move to your first microsevice should be the one which causes you the most issues. It doesn't have to only be performance and scaling issues but also testing and maintainability. If you are touching specific part of your business logic way more often than the rest of the system, it sounds like the perfect candidate for separation into its own service. There are many examples of business logic like that:
Do not expect to change your current system into microservices overnight. It is usually not even beneficial to make such a big change quickly if your app is working just fine. Much better way is to slowly move pieces of your business logic one by one into independent services and use that time to design a robust API between them to improve what is currently working OK. Also, you should consider all new features in a way of microservices.
If you keep pushing this direction long enough, you will find yourself transforming your app into small pieces talking to each other with only a small codebase of the old monolith. In this situation, you can perform a few refactorings and start calling it just another microservice too.
Transforming a monolithic architecture into microservices is not a simple task to do. It usually takes a long time depending on the codebase size. However, as your business grows and you need to be more flexible and reliable with your software, the benefits often critically overshadow the limitations we discussed. Microservices also help you maintain your technical debt way better so you can focus on your business and not fight your monolithic codebase.
At Codeac we work with our clients on daily basis on issues like finding the perfect candidates for refactoring or extracting a piece of business logic into its own microservice. Try Codeac and improve your code quality today.