We’re currently undergoing a process of introducing microservice architecture into one of our large monolithic web applications. We’ve made a decision to start splitting up the application into microservices and creating microservices for new functionality. I’d like to highlight some of the properties of microservices which convinced us to start the process.
We’ve had some theoretical knowledge we acquired from Sam Newman’s “Building microservices”, the GeeCON conference and various articles. We’ve also had practical insights due to our prior work on a prototype for another service.
- Firstly, the decision was dictated by the way the business operated. One module of the application had a high availability requirement. if it wasn’t online, it caused a significant loss in revenue. There were users that would rely on the service being online.So, the first thing was to separate the component that had to be online from the main monolithic application. Basically, the part of the system that always has to be online gathers events from users that use this app. It holds it within storage (its queues and so on) and then it is synchronised with the monolithic application. This was the first thing that was split up from the monolith.One of the guidelines for implementing microservices is to communicate between those two using APIs. This is not fully the case here. Some of the data is fetched directly from the database. Only the new incoming data is synchronised using the API. It was judged that using standard APIs to fetch this data (this module) wouldn’t be performant enough.
- The second reason for bringing microservices into the picture was the ability to incorporate different technologies and options for those technologies. While the monolith is PHP-based, we had some modules that we wanted to do in Java. We knew the Java tools would already be in place and this would speed up the process of implementation.
- Reason number three: the possibility to deploy those applications fairly easily. The monolith has been growing bigger and bigger. Making a small change within the monolith or upgrading a single library could affect many different features. With microservices, the programmers and testers have a smaller scope of changes to worry about.
Microservices have a few more advantages, but these were the main ones for starting the process. Unfortunately, in the world of software development there’s no free lunch…
Drawbacks?
For us, the main one is the cost of introducing microservice architecture to the project. Besides the obvious cost of extracting a functionality to a separate service, there are issues like authentication and authorization. These have to be addressed in a new way. Tools that help build, deploy and rollback the applications have to be improved. Good monitoring tools are important, as it is harder to detect if (and where) there are issues with the application. There’s the time spent on the building and consuming the APIs for the services. Lastly, creating and maintaining a good microservice template is also important. This project is a source of truth on how to implement and structure any new microservice.
Advantages
To some extent, the costs involving the creation of an application in a microservice architecture are a one-time issue. Once you build good monitoring tools and a good deployment process, you can easily plug those in all of your services and use them for new ones.
There’s additional work that has to be performed in comparison to a monolithic application. Yet, in exchange, you get small applications, with functionalities nicely decoupled from each other. You can introduce changes and new features faster and deploy them with greater certainty. You have the possibility of choosing different technologies (when it makes sense). You can also retire old services, replace them with new ones.
Modern applications are becoming larger and larger. The speed of development is critical to maintain a competitive advantage for a business. With those issues in mind, I believe microservice architecture to be a good direction for many projects. In most cases, the pros significantly outweigh the cons of such a design.
