Microservices — how to start breaking the monolith
Microservices has been a theme we have been working on for the past few years. We have been learning a lot as we go along and adapted our process to accommodate new challenges.
To share our experience, we have created a series of articles on how to build microservices. This is the first one and we will explain why we made the decision of migrating to microservices and how we started. Follow us to know first hand when the next articles are live!
At Nmbrs, we strive to make both the working environment and our services better, with quality at the heart of everything we do.
When we took the decision back in 2017 to break the monolith into microservices, we knew we had a lot of work to do to get there.
The advantages of moving to microservices were clear — they would help the development team and ultimately improve the services we provide to our customers. Switching to microservices would help the development team gain more independence compared to the previous way of working — multiple teams on the same application — which started to raise a lot of issues as the team grew. For example, if one team had a problem, then this blocked all of the other teams from working on the application.
A microservices architecture would enable us to have faster delivery of features, the ability to scale up more efficiently, independent squads and happy developers. In addition, skilled developers would also be more attracted to work at Nmbrs.
There were other reasons, such as easily experimenting with new technologies.
Sometimes, when we’re trying to find a solution to a problem, it is easy to lose sight of the bigger picture. It’s for this reason that we always define a set of principles, which have to be adhered to, to make our project a success.
Microservices enable people to use different technologies, in different teams and in different practices but any project has to align with our company-wide principles.
A key principle is that the splits of the monolith into services should be focused around either a domain, business or feature concept. In other words, the split should not be focused on technical reasoning. Of those splits, the main focus should be on domain processes because if we’re not careful, the microservices will be communicating and interacting with one another too much, and when that happens there is usually a problem with the split. So by keeping the domain very contained and making microservices around that domain concept, we can avoid any issues further down the line.
Another key principle is that microservices should not be shared between the squads as it can defeat the goal of having independent squads. There is a tendency for teams to want to go back to the way things were divided previously, but in order to stop this, when a service is being defined, the team must think of whether which squad should work on that — if not, it will always create problems as there is no real ownership or responsibility.
Finally, the guidelines should make it as easy as possible for developers to follow best practices. If not, they’re likely to forget the best practice way of doing things and go live with something that has been done in a rush, which can subsequently create a lot of problems.
Making our decision on architectural options
As we were already an avid user of Microsoft software, we decided to look at our microservices options in Azure as it would make things easier to integrate. We initially saw that a lot of other organisations were using Kubernetes and Service Fabric rather than App Services. However, while Kubernetes only seemed to be the best approach from a technical perspective, it required extensive knowledge to make it worthwhile using, which would mean an investment in learning. In addition, it is very focused on infrastructure, and at Nmbrs our policy is to be a product-focused company that prioritises releasing new features.
We then looked at Service Fabric, which at the time was not a very mature product and it required us to change the way we code into using its SDK, in order to take full advantage of it. Finally, we evaluated App Services, and we realised we could use it for our needs and did not require a lot of refactoring. It also keeps the doors open for us to change to something else in the future if it makes sense to do so.
We could also use App Services for the applications that were not microservices so we could ensure that all of our environment could deploy applications in the same way. So far we’re very happy with App Services — we have zero downtime deployments, auto-scaling, and many other features which were also advantages of the other options.
Our next step was to validate this new architecture with a real business need, instead of just creating something like a pilot project which could not be used. So we took the opportunity to work on our HR functionality by developing an independent microservice for it.
Experience working with Microservices for yourself and help us migrating our monolith. We are looking for a Senior Developer already based in The Netherlands to join our team.
