Why should you switch to microservices?
According to the NGINX App Development Survey, 68% of organizations were using or investigating microservices in 2015. In only 2 years, this number grew to 80% (LeanIX Microservices Survey 2017). Moreover, over 70% of these companies plan to intensify the usage of microservices by the end of 2017.
source: https://www.nginx.com/resources/library/app-dev-survey/
The companies who use microservices are much faster, more resilient and more flexible than the ones who don’t. A microservices-based architecture eschews many of monolithic architecture’s problems that can create technical debt, and in turn, brings measurable cost savings in both time and speed. Applications based on microservices are easy to scale, faster to develop and they often perform better than the monolithic apps. According to the LeanIX Microservices Survey 2017, the majority of companies who use microservices deploy new releases multiple times per week compared to multiple times per year in the companies who don’t use microservices.
How to refactor a monolithic application into microservices?
You start with a huge monolithic system. It is split according to layers not bounded contexts and it is extremely hard to break into microservices. And even though you know that it would be nice to refactor this mess, you usually don’t have enough test and knowledge about how the system works and how it is supposed to work. You want to introduce the newer, easier to use technology, but you are aware that the huge Monolith that you’re using right now is probably one of the most important systems in your company. It’s old, expensive to change and you still use it because everyone is afraid that breaking this system will literally break your company.
Having laid out what we are dealing with (let’s call it The Monolith) and how careful we need to be when refactoring it into microservices, I’d suggest following these guidelines:
1. Don’t refactor everything all at once – it’s impossible to do it right.
2. Treat The Monolith as a black box with some APIs. They don’t necessarily have to be RESTful APIs – think of ways to interact with it.
3. If you need to interact with The Monolith (you’re making changes or introducing new features), create a separate service with the API you need. Use only that API from then on.
4. When adding new features, create separate (micro)services with an API for each of them and have them interact with The Monolith’s APIs.
5. After some time you will see that the pieces of your Monolith are being accessed only through your new APIs. Even though they are still a part of the monolith code base.
6. Once you see bounded contexts bubble up, it might be convenient to chop them of The Monolith and have them working as separate services.
7. With microservices, you will need much more automation than before. Think in advance about Continuous Integration and Continuous Deployment (CI/CD), containers & repository, central logging, and monitoring.
How to introduce the changes?
Changing the way how your company works in an instant is not a good idea. The ideas described above should be introduced gradually – in a way similar to how you change the architecture (to understand why one is tied to the other, see: Conway Law). A few things to have in mind when refactoring a monolithic application into microservices:
- Teams need to own their microservices from the first line of code to production deployment & operations. It’s nearly impossible to work with microservices if you have separate departments like UI, APIs, databases, ops.
- Start with one team working on one bounded context and build this team around an expert who is experienced in working in an extremely agile environment.
- Once your team gains some experience, pull a person or two and build new teams around them.
- You might consider outsourcing some work to create a team consisting of 1–2 external members and 2–3 people from within your company. Despite their best effort and great skills people from your company might be used to “ways of doing things”. If so, you will end up with the very same processes and tools just being renamed as “agile”, “CI” and 2–3 services considered “microservices” – each doing “everything”.
We’ve done quite a lot of that work in Neoteric already (both for our products and external customers). If you need any help, schedule a 15-minutes call with me and I will direct you to the right person at our company for a free consultation.
