There is a microservice for that
At Qandidate.com we recently shifted our development process towards building microservices. We’re constantly looking to improve our way of writing software. For example, moving from CRUD applications to event-sourced applications and using Kanban to manage our process. Microservices seem to be the next step.
So far we encountered a number of advantages of working with microservices, and we would like to share our findings with you. Note that we don't run many microservices in our production environment yet. Who knows how we will be developing software in six months!
Avoids spaghetti code
Spaghetti is more of a one-pan dish, you don’t make spaghetti sauce in 10 different pans. It is far easier to write spaghetti code within a single large app than it is to write spaghetti code across multiple microservices, especially when you avoid circular dependencies between your microservices.
Single responsibility to the next level
Before we started using microservices we would have built a service class for each responsibility. When we started using microservices this shifted: each responsibility is now encapsulated by its own microservice. By building microservices you get a clearer separation of concerns (SoC) and since you have to build separate mini-applications you are forced to more thoroughly think about your design.
Goes hand in hand with rapid prototyping
The fact that these microservices are small also allows you to cut corners during prototyping while maintaining an overall design. The API of each microservice (and the links between microservices) dictate your system design, not the design of each individual microservice. As long as you take time to manage technical debt you can get away with rapid prototyping and only put in effort in the microservices that are critical for the business. No need to over-engineer a microservice that could be OK as a CRUD mini-app. If you at some point decide that the prototype is no longer adequate (not scalable, can't be extended, etc) you can always replace the microservice with a better version.
Secondly, the fact that everything is split up makes it easier for multiple developers to work on the application. Since everyone is writing a different microservice you spend less time on merge conflicts.
Design by contract allows for experimentation
A microservice should not be more than a couple of days of work. This opens the door for experimentation. Why not write an event-sourced microservice in PHP or scala!
Scalability
Each microservice can be run on its own machine. This means that instead of having a single app that runs on one machine, you can have many small apps that run on various machines. Of course this doesn’t automatically make each microservices horizontally scalable, but it’s an easy first step towards a better performing application.
Reduces the complexity of your application
Microservices require clearly defined APIs and provide a clear insight into your dependencies. Each microservice needs to be able to access its dependencies, which requires you to explicitly define them.
A downside of microservices is that you shift the complexity of your applications towards complexity in your stack. Instead of having a single (but highly complex) application you end with many (tens, hundreds, over 9000?) of small applications. Each microservice has its own stack requirements, and it becomes more difficult to keep track of the performances of your microservices. The role of devops becomes more and more important.
Conclusion
So far we are very enthusiastic about microservices. Writing microservices forces us to put more effort in the global design of our app, yet it allows us to experiment with new technologies on a very small scale. This results in less spaghetti code, and we get to constantly improve our way of writing code.
All dependencies have to be defined explicitly (a microservice can't just access the database of another microservice). The result is a clear overview of the dependencies of each microservice.
The introduction of microservices does come with an increased complexity in our stack. Managing dependencies in a production environment becomes harder, but we are sure we will tackle this problem.
We hope you enjoyed our view on microservices. In case you did:
Be sure to check them out!