How Microservices Can Help Your Team Move Faster and Produce Better Results
How Microservices Can Help Your Team Move Faster and Produce Better Results
Beyond the tech, there are real benefits for the people involved too.
The benefits of adopting a microservice architecture are generally well known. Most organisations and developers understand that by breaking down an application into multiple services, several concerns such as scalability, code quality, deployment performance, and troubleshooting can be addressed more effectively.
Many of the more commonly known reasons for microservices adoption (such as the ones mentioned above) are technological. This is not incorrect, but it is only a small part of the story. One major aspect of a microservice architecture is that they are an organisational tool. Adopting microservices enables an organisation to run faster and better.
Here are 3 ways that a microservice architecture can help your organisation move forward and scale up:
#1 Microservices allow autonomy
Microservices encourage and enable what is known as a decentralised organisation.
One of the consequences of centralised governance is the tendency to standardise on single technology platforms. Experience shows that this approach is constricting — not every problem is a nail and not every solution a hammer. We prefer using the right tool for the job and while monolithic applications can take advantage of different languages to a certain extent, it isn’t that common. ~ Martin Fowler
A decentralised organisation can establish overarching standards and goals while giving teams the freedom to solve the problem using business logic and tools as they see fit.
Ways for the different services to communicate with each other will need to be established. As Sam Newman says:
Standardise in the gaps between services, be flexible about what happens inside them.
In the early days, this need not be a very complex exercise so long as it is clear what the inputs and outputs of each service are. As the application gets more sophisticated, things like consumer-driven contracts can be established.
The key here is that teams can focus on building their service using the best tools, provided they achieve the goals that were set out by the broader organisation.
#2 Microservices encourage ownership
One of the most powerful approaches to decentralized governance is to build a mindset of “devops” in which engineers are involved in all parts of the software pipeline: writing code, building it, deploying the resulting product, and operating and monitoring it in production. ~ Nathan Peck
This kind of ownership was made popular, among others, by Amazon with the “you build it, you run it” principle, which says that teams are fully responsible for maintaining the services they build. This approach has the benefit of preventing a laissez-faire attitude to building software. If your team is the one getting the call at 3 am on a weekend when everything is suddenly on fire, I bet you’re going to do everything possible to ensure such a thing never happens!
The other side of the ownership equation is that microservices give small teams the ability to fully understand a particular part of the system, without having to worry about how the rest of the system works.
As a system grows, it is humanly impossible to keep track of everything and to “master” the ins and outs of everything that makes up the application. It is far more reasonable (and smart) to focus on smaller subsets of the system, such as a particular microservice.
#3 Microservices improve team performance
As a team, the more dependencies you have, the slower you are going to be.
Dependencies can be personal, for example depending on a “star performer”, someone who has all the knowledge and on whom everyone depends to get stuff done.
Dependencies can also be organisational. For example, a team may need to ask for permission and go through a certain amount of bureaucracy before working on a feature or implementing a solution to a known issue.
Lastly, dependencies can be technical. This happens when many parts of the system need to be updated to implement a new feature. Each one of those parts may be a dependency on other features as well, thus slowing down the updating process and requiring extra testing and approvals before moving forward.
Fewer dependencies mean that there is less of a need for coordination between different people and teams. Teams can move forward confident that their changes will only affect the specific feature that they are working on, rather than cause ripple effects throughout the whole system.
By having product teams work more in isolation, and reducing to a minimum the need for different streams of product development to coordinate with each other, each product team can go faster. ~ Sam Newman
Avoiding too much isolation
Henry George, CTO at Trilo, has a useful engineering principle called “No solos, no silos”. It’s a reminder for teams to avoid turning things such as autonomy and ownership into isolation.
Isolation needs to be countered from both the inside and outside.
From the inside
Back in 2002, Amazon found itself being one of the early pioneers in what will eventually be known as microservices. At the time, then-CEO Jeff Bezos sent out a strict directive: that all teams should, without exception, interface with each other via a set of well defined APIs. This directive has become legendary, partly for its unique style and tone, but also become it has been the guiding light of so many microservice-based organisations over the last couple of decades.
Whether we’re a small team or an individual working on a specific microservice, all our work must be fully and independently usable by other people and teams.
At one point, Bezos says this:
All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions.
This is what it means to avoid isolation from the inside. As a team, even as you have full ownership and plenty of autonomy over how you’re going to build a service, you should build everything from the ground up to be fully usable from the outside. Your help mustn’t be needed.
From the outside
When it comes to avoiding isolation from the outside, what we need is both coordination and vision.
Amazon is again the focus of our attention here, but this time in a negative way. Sam Newman comments on this when he says:
This lack of coordination […] can result in a disjointed user experience, as different teams can make different choices about how to solve the same problems.
This is obvious to many people using Amazon Web Services. Services within AWS appear to be distinctly disjointed. The user experience, the amount of literature and help available, and even the roadmap of each service appear as though they may have been built by completely different companies. And, for all practical purposes, you could say that they are.
This complete autonomy of each team is attributed as one of the main reasons for AWS’s success. In a sense, you could say that it is all about picking your tradeoff and that this particular tradeoff is working very well for Amazon. But it is also a big vulnerability: if a big competitor threw enough money and resources at the user experience side of things, they could take away some of AWS’s market share.
There is no question as to AWS being the leading cloud provider out there, and the upsides outweigh the downsides. Nevertheless, this is a real pain point for many users. It’s the antithesis of Amazon’s customer obsession principle.
Avoiding isolation from the outside requires coordination between teams, as well as an overarching vision of the experience that we want to deliver to our customers. It is, at least to an extent, about establishing standards that all teams have to comply with, without sacrificing their autonomy and ability to iterate quickly.
The takeaway
Microservices can bring the following organisational benefits:
Autonomy through a decentralised organisation
Ownership by reducing the scope of what each team needs to understand and maintain
Increased team performance by reducing the number of dependencies
Too much isolation can become an issue, but it can be addressed both from inside each team as well as between the various teams
More reading
This article was originally published on Trilo’s Engineering Blog and has been slightly edited for clarity.