Setting Microservices Up for Success: Real-World Advice
Once you’ve built a microservice-based system, you’ve got to keep it running and make it successful for your organization — and that can be harder than you think.
Sarah Wells knows a thing or two about managing a microservices system successfully. In this episode of The New Stack Makers, she described her experiences in a conversation with me. Wells has written a brand new book from O’Reilly called “Enabling Microservices Success,” in which she provides detailed, practical information on what it takes to keep a microservice-based system running once you’ve built it.
Now an independent tech consultant, Wells has over 20 years of experience as a developer, principal engineer and tech director across product, platform, site reliability engineering (SRE) and DevOps teams.
She also spent over a decade working at the Financial Times (FT), as the internationally renowned news organization transitioned from 12 software releases a year to more than 20,000.
To achieve this, the FT moved from private to public cloud, re-architected to microservices and adopted DevOps and SRE practices, rewriting major parts of the company’s software system along the way.
One aspect of adopting a microservices architecture that’s often overlooked is that your success hinges not only on the expertise of your developers but also on the wider structures within the organization. For instance, if you are adopting microservices with a view to being able to evolve software faster, it can’t happen in an environment with a slow, rigid change-control process.
When Wells joined the FT, the firm had two separate technology organizations because, she tells us, there were parts of the business that felt things were moving too slowly. “It is a big issue,” she said, “if you can’t release features quickly, you can’t possibly experiment with them or see whether they have an impact.”
The FT merged its two IT organizations, then invested heavily in Infrastructure as Code and other forms of automation to enable developers to self-provision a server. “This unlocks the next step of looking at how you can release changes more frequently,” said Wells. This, in turn, requires a move to continuous delivery with build and delivery pipeline automation, as well as greater team autonomy.
How Engineering Roles Can Evolve
There are days when it’s particularly bad for an organization’s website to be taken down — Black Friday, for instance, for an online retailer, or a national Election Day, if you’re a news site like FT. Reducing the chances of a major outage on these occasions comes down to good communication, Wells suggested, and could have a bearing on specific aspects of team autonomy.
“If you’re a software developer, you’re not necessarily interested in closely following the news,” she said. “You need to point out to your team, ‘This is a big news day, so think very carefully about what you release.’”
There are also some broader aspects of the shift to greater team autonomy. Something Wells and I touched on is what it means for senior software engineers who may suddenly find that a role they’re in that feels safe and secure, such as being a member of an architecture review board, is no longer needed.
“You have to have conversations about whether your expertise is better used in enabling everybody else to do things right, in saying what it means to build a secure, safe and reliable architectural system, than it is defining what the architecture is for everybody,” Wells said. “The tasks you do now could change and you should be open to the idea that they are different, but the responsibilities are still there.”
In the same way that our roles can evolve, so can our services and their corresponding service boundaries. Wells talked about how you can tell when a service boundary needs to change, and how you might approach splitting or merging services.
Watch the full episode to earn more, including Wells’ thoughts about the role of engineering enablement and why she prefers this description to the term “platform team.”
