Microservice architecture offers no end of advantages over monolithic applications, including continuous delivery, more room for experimenting with new features, and flexibility for working with different technologies. Still, it also has its constraints. Especially, for teams who are transitioning from monolithic applications.
In this episode, we will ask Software Developer Sarah Wells about her experience in transitioning to microservices and what we should know before starting.
Edited transcript
Sarah Wells got into the software development industry in 1999. After a decade of experience as a senior, she became part of the team behind the British newspaper Financial Times’ content API.
A few years later, she filled the position of principal engineer of the team in charge of rebuilding the Financial Times website and its content publishing platform with microservices.
Continuous delivery: Microservices over monolithic
Sarah claims that the main reason the Financial Times moved away from its monolithic application was release limitations. Since releases could freeze the website, the release schedule forbade releasing code during working hours and limited releases to one Saturday a month.
Sarah recalls that this was
“mostly okay for the Financial Times because a lot of it is business and political news, but it’s always a problem when something might happen and there might be breaking news.”
More importantly, the dilated release periodicity translated into releases pushing a great deal of code at the same time. Releasing new code for different features simultaneously made it difficult to grasp what was responsible for a determined outcome like an increase in the number of people reading longer or a failure in the system:
“Something goes wrong, it’s incredibly difficult to work out which of the commits that are in this release, and if it does go wrong, you try to talk to the developer who made the code change, but they probably did it five or six weeks ago.”
Microservices, in turn, allow reliable, decentralized, and much shorter release cycles with zero downtimes, an ability known as continuous delivery. With continuous delivery, Sarah understands, they were able to experiment in a way they couldn’t with a monolithic application. In this regard, she encourages setting up a “hypothesis that could fail” and seeing what impact it has on a predetermined metric:
“If it doesn’t or if it has the impact you didn’t expect, you should be undoing it.”
Since continuous release prioritizes short release cycles, Sarah recommends keeping the people behind the microservices code responsible for it and restraining them from handing it over to a different team. In her experience, the people that frequently work with it can work faster, and attempting another team to keep up would just slow things down.
Moreover, Sarah encourages introducing teams to a mindset of responsibility towards the application: if something goes wrong with it, they are responsible for it. She understands that this responsibility has a positive effect, making developers more careful when building products:
“You do build things differently when you are the person that might have to get up and fix it”
When it comes to microservices ownership, Sarah understands building applications relying on the expertise of a single team member can be detrimental, since there is always the possibility they leave the company.
Sarah points out that while with monolithic applications “ the team that operates the monolith are expected to understand the whole thing”, with microservices “it’s very easy to get to the point where everyone says, ‘well, no, we don’t know how that service works’ ”.
To solve this dilemma, she proposes a kind of ownership of what she calls BizOps. According to this frame, microservices are owned by teams, not individuals. As such, teams will avoid relying on an individual to make things work, and no team member will monopolize the ownership of the product.
Migrating to microservices
When it comes to microservices migration, Sarah advises against application modernization, that is, replacing parts of the legacy monolithic applications with newer software or hybrid microservices. She understands that
“It would be extremely difficult to get the benefit from extracting parts of it without extracting everything”.
Moreover, in the case of the Financial Times migration, “a lot of people working on the microservice system had built the monolith”. Therefore, she and her team had the advantage of understanding the domain:
“When we were going around taking our approach to microservices, I think we understood how to split that up because we’d already seen it”.
To Sarah, the main benefit of starting from scratch instead of adapting the monolithic application has the advantage of allowing one to focus on the new architecture and not worry “by how it interacts with the existing monolith.”
Still, she does concede that “it’s really easy to have quite a long period of time where you are no longer really doing feature development on the old code base, but you are not really releasing new features for the new code base.”
At the same time, Sarah says that you must know the difference in monitoring microservices in comparison with monolithic applications. When it comes to testing, you may realize that
“Your end-to-end acceptance tests are effectively a straight jacket that’s turned your microservices system into a distributed monolith.”
Instead of acceptance tests, she recommended synthetic monitoring as a way of easing troubleshooting:
“We had a microservice that would publish an old article every minute and check that it made it through to the website by looking at the timestamp, if that broke, we knew that something was wrong, and sometimes that would be because of code release, and sometimes it would be because something went wrong somewhere on the stack.”
Organizing microservices
Despite the value microservices bring, Sarah points at issues these bring in:
“If you’ve got 150 microservices, it will take you 150 times as long to do anything that you have to do for each of those services”.
To her, the answer to this problem is automation: ” you’d really want to have a template for your bill pipelines, for example, so that you can add something into all of them.”
Another constraint is upgrading libraries, especially libraries used by many microservices:
“I think is you may not even really be immediately able to tell where you are using all of a particular library, because unless you’ve got a really good handle on here are all of our services and here’s who owns them, it could be in a repository that no one’s really paying attention to.”
In this scenario, there is no choice but to tediously search for the repository. Sarah found the solution by using different data stores depending on the parts of the system. Still, this solution also has a downside:
“Assuming that every database that you have needs to be upgraded every year or every six months, now you’re doing it three times as often because you are upgrading the document store and then you’re upgrading the graph database.”
In this way, Sarah concludes that “the more different things you have, the more work there is just keeping them all up and running and you’ve got to be conscious of those trade-offs.”
Keeping the microservices updated is so demanding to teams that it is important to be aware of the trade-off of microservices to use them:
“I don’t mind having one of my five developers basically having to keep everything maintained if we’re moving twice as fast as we used to do when we were building the monolith.”
Another form of organizing microservice is through clusters. According to Sarah, microservice clusters are ideal for encompassing all services destined to an area or task: in the case of Sarah, there was a cluster for the content publishing platform, and “a group of services altogether that we call the membership platform, which is all related to being able to subscribe and access the content.” However, these need to have fairly clear boundaries and only a group naturally fits together.
Adopting new technologies
To Sarah, despite microservices offering the possibility of working with different technologies, there are constraints in adopting them. First of all, security constraints:
“I don’t want developers to just go and sign up to something with a credit card and start using it without us having some level of understanding, and then also just the more things you have, the more risks that you have, the more cost potentially that you have, depending on how costs work”.
Secondly, operational difficulties: “how difficult is it for anyone to step in and help when there’s a problem if it’s all different things?”. Different technologies halt the flexibility of moving services between teams.
To face these challenges, Sarah proposes the idea of guardrails. Guardrails mandate a clear set of objectives from the developer, and also that if the developer wants to try out a different approach or technology, they are responsible for patching if needed and within a set time.
The bottom line
Sarah left the Financial Times at the beginning of 2021 and is now advocating writing a book on microservices to pass on her experience and expertise on microservices. Concretely, on how to succeed at implementing microservices and the organizational culture, building, and operating aspects of it.
You can find Sarah Wells on her Twitter and LinkedIn. You can also search on YouTube for a number of talks she has given in this article.
