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.
