Microservices: Organizational Practices, Part 2

Welcome back! If you missed Part 1, you can check it out here.

Conway's Law

Let's first discuss Conway's Law, which is an observation published in 1967 by Melvin Conway. It states that:

"Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure."

This basically means that the architecture of our system will always resemble the organizational structure of our company. The reasoning behind this is quite simply the result of the fact that when a team is assigned a task to implement a component of software, it needs to cooperate with other teams. As an example - whenever the team reaches the boundary of some other component maintained by another team, the engineers need to agree on a stable communication protocol between these components and they create APIs.

We can also use the other side of the law, the so-called Inverse Conway maneuver. When employing this technique, we restructure the company in a way that stimulates the creation of the desired communication channels.

In our case, we want to strengthen the communication between engineers working on the same business features (from database to APIs), hence we put these engineers on the same team. Within the restructured team, strong communication occurs internally, there are no longer strong APIs on the technological level (between business logic and database, for example), instead, these APIs will appear on the boundary of the team. So we end up with REST (or similar) APIs encapsulating the business subdomain. Which are, coincidentally, microservices.

We want the team to be responsible for the full release cycle, as this bolsters the shared responsibility for the component. It is no longer possible to say that "it was developed/tested/deployed incorrectly" when the whole team owns all these activities. There is now no need to find the culprit, now it's more important to find the root cause.

Taking the Next Step

Restructuring the team and improving internal communication not only leads to the development of well designed and tested microservices, but they also lead us to the logical outcome that the strongest cross-functional team conforms to the DevOps model.

Why DevOps Is Important for Microservices

Apart from the improvement of communication channels, cross-functional teams are also far more effective when it comes to the software development lifecycle. Here, it is important to remember that in the world of microservices, this cycle does not happen only once, it happens dozens of times (each time a new service is introduced). For teams with a traditional layout, where developers only do the programming work, it is common that they need to create a support ticket to:

1. Create a Git repository.
2. Create a pipeline in a continuous integration system.
3. Create a project in a bug tracker.
4. Provision machines for testing.
5. Create a deployment pipeline.
6. Deploy a new version to production.

With this modus operandi, the team can easily spend more time waiting for others than actually working.

Implementing DevOps

Dev-Ops Axis

DevOps teams mitigate this issue by being able to act as both development and operations teams at once. One way to augment a traditional team is (if development and operations are separate entities) by inserting one operations engineer into each development team. This dedicated engineer should support the team during the setup phase (points 1-5) and supports the team with the deployment of automation (continuous delivery) and monitoring of the system in production. While initially there is limited overlap between the work done by developers and the operations engineer, the ultimate goal should be to create some redundancy of knowledge in the team. This means that each member of the team should eventually be able to set up a new project and maintain the service in production, while the operations engineer should be able to work on features with developers.

This does not mean that everyone in the team will be top-class developers or top-class operations engineers — on the other hand, the developers will be able to spin up new projects and they will know how to maintain the production environment (and debug issues, if things go sour). In this scenario, the skilled operations engineer will be able to provide feedback on code during development, making sure that potential issues are cleaned from the code early on.

Vertical Axis

These newly created teams should be given responsibility for some subdomain (vertical cut) of the product. This may be, depending on your product, something like Customer Management, Parcels, or Delivery scheduling. Being responsible for the vertical cut puts your development team in the position of being domain experts in the subdomain and stimulates the creation of microservices.

Conclusion

In this two-part article, we have described the advantages of microservices from the point of view of the organization: fast releases, reduced mean time to recovery, resources/costs savings (using autoscaling and cheaper hardware), as well as easier growth and onboarding within the company itself. We have also shown how we can use the inverse Conway maneuver to stimulate proper communication channels within the company — those which lead to fine-grained and reliable services. While ensuring that all processes are managed by self-sufficient DevOps teams.