As established organizations move to modern software development practices, they tend to modify team responsibilities, including the ownership of various aspects of the development cycle. The famous phrase “self-organizing teams,” used in the Agile Manifesto, may describe how some software cultures make those adjustments—organically and easily, with limited confusion.
For other organizations, however, the necessary adjustments might require a little nudge from leadership. It all depends on the culture of the organization that is going through the change.
One good way to approach to microservices development is to consider the structure of the output as a direct reflection of team structure. The idea is, better team structures yield better software—in this case, microservices. And almost any organization can adopt this approach to maximize the value customers derive from that software. Here's how it works.
Higher value requires a move to independence
One way to generate higher value in software is to deliver it more rapidly, enabling faster feedback from customers. Faster delivery cycles, in turn, put software improvements back in the hands of customers, ideally enabling you to make them faster than your competitors can.
Here’s the technical part: In order to deliver software faster, software must be built as independent services that can be stitched together by way of contracts (REST APIs, for example) to form an application or system.
Monolithic systems have too many dependencies where things slow to a crawl. Teams “shackled together” are unable to work independently.
Organize your teams using Conway’s Law
There is a way to retool your software development organization so that your teams that can deliver software faster by building services independently. I recommend following Conway's Law, which states that organizations that design systems “are constrained to produce designs which are copies of the communication structures of these organizations.”
You can relate Conway’s Law to fractal theory, chaos theory, or or other theories about organizational structures. But the implications for software development are not complicated: The structure of your software is likely to reflect the structure of your software development organization.
Consider how Conway’s Law predicts a sub-optimal software system. Imagine an organization with separate horizontal teams, each of which owns a different element of a service (see the diagram below). One team owns the API layer, another owns the business logic, and another owns the database layer. This means that a virtual team that's building a service from all three elements must constantly negotiate against the priorities of horizontal teams.
These siloed teams have their own priorities, so a team building microservice A must negotiate separately with each of these teams separately, which slows down the process. Papering over those communication boundaries is not going to achieve the speed, quality and risk profile that you need to deliver value faster.
Now consider the advantages of creating vertical teams for each service, where the team owns the API, business logic, and the data layers (see the diagram below). The teams are no longer dependent on any other team. The key is the API layer. You an use it to form contracts between different vertical teams so that each can move at its own pace, and each can use the API to integrate or leverage services from the other teams.
In order to deliver value faster to your customers, teams must be organized in a way that allows them to own what they’re responsible for, end to end. This is what Amazon calls “you build it, you own it,” or “build and run” teams, responsible for development and production throughout the entire lifecycle for a chunk of software.
The best path to clear accountability is to empower small teams that own something end-to-end, which in this example is a service. A service does one thing and one thing well, a concept based on Robert (Uncle Bob) Martin’s single responsibility principle. Whether you call it a microservice or not doesn't really matter.
Building your “build-and-run” team
A build-and-run team ideally consists of six to eight people, but certainly no more than 10. This team owns everything from development to operations, including testing and product management. So developers are on "pager duty," because the team is responsible for the quality of their service in production.
Unlike a monolithic architecture, a microservices architecture lets you scale the teams and number of deployments as you grow the business.
Containers let you build and deploy microservices with portability and speed, while also reducing costs. Containers are much more efficient than standard virtual machines. You can run multiple containers on a single virtual machine, enabling you to optimize the use of your existing virtual infrastructure. But you can also run containers directly on physical, "bare metal" servers without using virtual machines. This is highly efficient.
The impact of tech changes on culture
If you’re a modern software company, you have already incorporated some of these organizational shifts into your delivery process. Teams want to see their work being used. It’s human nature. A modern software company has one to a few businesses, but they typically have hundreds or thousands of services running as part of a system. Their teams ship multiple times a day—at Amazon that’s 136,000 deploys per day, or roughly 1 per second! Modern companies like Google, Facebook, Twitter, Gilt, and SoundCloud have fewer systems with massive web scale. Speed is critical for them to adapt to disruptive shifts while empowering their developers.
But large enterprises that have been around for decades consider themselves, unlike Google, Facebook, LinkedIn, or Twitter. What those businesses do doesn't apply to them, they say. What they mean by that is they don't always have the web scale requirement of those companies. But the sheer diversity of their applications makes continuous delivery even more challenging. The goal is to deliver value at speed and scale without sacrificing quality, and a shift in team structure around the principle of Conway's Law can help with that goal.
It's not just about adopting new technology or tools for software development, it's fundamentally about changing the culture of how you build software. In this case, that cultural shift begins with a simple alignment of people around the build process.
A few suggestions to get you started
1. Containerize your monoliths. This will give you efficiency and portability. Efficiency will reduce your infrastructure costs, as containers have smaller footprints than do virtual machines. Portability gives you the ability to move that workload to any infrastructure as a service (see Step 4). Note: If you’re thinking that running your monolith in a container might be unwise, consider this: Goldman Sachs plans to containerize 90% of its 5000 apps before the end of this year. This will enable its teams to learn about containerization more quickly, and begin decoupling functions from its monolithic architecture in order to recreate them as microservices. See the diagram below.
2. Start by picking one feature that you can build as a small service and plug it back to the monolith via an API gateway. That's how you can incrementally adopt microservices, one re-built service at a time.
3. The software that you create should be treated as a valuable asset. As with any other asset, you need a system to track it, reuse it, share it, know how its being used, and so on. Put your assets in a central repository system based on Git (such as Github, GitLab, etc.).
4. Decide on the platform and infrastructure on which you will deploy and run your workloads, and look for features that empower your teams to deliver to production easily and quickly, while still optimizing the use of your distributed hardware and virtualized infrastructure.
Lesson learned: Just get started
All four of these steps can be done in parallel. For Step 2, it’s best to start off any new service in a source control system based on Git. The key here is that you don't need months to discuss how to re-architect your application. It took SoundCloud more than two years to identify and recreate features within its Rails monolith as microservices. It may take you months or years to fully re-architect your own monolith as a microservices-based syste—and that's OK. The point is, just get started.
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
