Lukonde Mwila
Microservices may very well go down as one of the top buzzwords of the last decade. This software architecture has become a popular choice when designing systems, with many companies opting to structure and build their applications based on this paradigm. However, the microservice model is not solely based on a technical shift, but also a cultural one that heavily relies on how teams are structured.
In this article, I'll explain the concept of microservices and the kind of team culture or practices that are required in order to successfully adopt this architecture design approach.
Contents
What are Microservices?
A microservice-based architecture is a type of software design that modularizes a system into a collection of services and sub-modules. The paradigm of separating software modules into services is not something new. Microservices are a similar approach to Service-Oriented Architecture (SOA) which also entails breaking down a monolithic architecture into smaller modules. A key difference between the two is that SOAs are built to perform multiple business tasks, whereas microservices are meant to fulfill a single business task.
These software modules may serve a single purpose in and of themselves, but as a whole, they fit within an application. The technical goal of this software design is to create network-accessible services with the following characteristics:
- Organized around single-purpose functionality
- Highly maintainable and testable
- Loosely coupled
- Independently deployable
- Owned by a small team
I'll use the example of an e-commerce website. These systems typically consist of order management, shipping, payments, and inventory management. When a platform like this is built based on a microservice approach, each microservice is treated as a black box that is externally accessible via its API.
Team Culture and Productivity
Contrary to what some may think, microservices are more than a technical architecture. The paradigm itself is somewhat of a culture, or at least requires a culture change. Unfortunately, this doesn't get as much attention or emphasis as the technical implementation. There's definitely an argument to be made that it should precede any of the programmatic or code details. This is typically deemed as less exciting, but it's important for a business to understand the shift that microservices bring to development teams in terms of autonomy, accountability, flexibility, and technical freedom, among other things. When a company adopts this paradigm, loosely coupled and independent teams have a clear understanding of the journey for their particular product or business domain service from end to end, which in turn produces a better quality product.
Microservice teams can focus on a specific service as opposed to the entire application. This makes it easier to customize the needs and optimize functionality for a better end product. Working on individual modules frees teams up to focus on business capabilities and how this can best translate working output.
Team Structure Meets Business Domain
Melvin Conway coined a phrase in his publication 'How do committees invent?', that was popularized by Fred Brooks in his book, 'The Mythical Man Month', where he dubbed it Conway's Law. Conway's Law (1967) states, "Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations." In simple terms, Conway was presenting the idea that the systems created by a business reflect the organizational structure within that particular business.
How does this translate to the software development domain? When you consider the challenges and constraints that exist within a business in terms of its communication structures, these same issues will be projected to how software is developed. This includes the methods that teams use to coordinate, communicate, and deliver software. All of which has an impact on the final product.
Many digital companies tend to structure their teams in silos based on departments such as marketing, UX design, front-end development, mobile app development, back-end development, database administration, IT operations, etc. This conventional approach isn't necessarily wrong or bad depending on what you're trying to achieve. A microservice culture should influence teams to be cross-functional. In this kind of model, independent teams will consist of people with all of the relevant skills to deliver a particular service from end to end.
This structure improves understanding of business requirements, team cadence, and software delivery.
Independent Deployment Teams
As mentioned in the previous sections, microservice teams work on services that are independent of other components of the larger system they fit into. As a result, teams can adopt practices such as Continuous Integration and Continuous Delivery (CI/CD) and a more agile approach to software development. Furthermore, cross-functional teams can develop, test, problem-solve, deploy, and update services independently, which leads to faster deployment and troubleshooting turnaround times.
For example, the team working on the service enabling payments in the application can add support for a new payment method and independently release it into a live application environment.
Technical Heterogeneity
One of the biggest lures to a microservice architecture is the technical heterogeneity that it presents. The upside to this is that development teams can independently choose technology stacks that are best suited for the respective microservices. Therefore, teams have more autonomy to piece together the tools that they believe will enhance the service they're responsible for. However, it's important to note that technical diversity works best in a team model of strong ownership, as opposed to collective ownership.
In strong ownership, the team owning the microservice calls the shots in terms of programming paradigms, technological decisions, deployment practices, and tools. This approach gives a team a great deal of autonomy, which has a lot of benefits but also increases the responsibilities for the team.
In a collective ownership model, on the other hand, microservices can be changed by any one of a number of teams. The main benefit here is that you can move people where they are needed.
Considering this, if a company has a collective ownership model for its microservices, then technologies will have to be selected based on the skill set of all the teams that are responsible for working on the different services, to avoid the pitfalls of key person dependencies.
Two Pizza Teams
A question that gets asked often when it comes to microservices is, "How big should a single team be?" You'll be disappointed to find out that there is no magic number that will suit all scenarios. Research that has been done in this area tends to lean more towards teams that consist of 5 - 10 people. A popular principle that was birthed out of Amazon is the two-pizza rule. This rule, as explained by Jeff Bezos, is based on the idea that each team should not be so big that it can't be fed with two pizzas.
Amazon adopted the practice of teams owning the whole lifecycle of the systems they managed, with the goal of teams being more rapid and efficient. Another example is Netflix. Netflix apparently learned from this same example set by Amazon and structured itself around small, independent teams so that the services created would be independent of each other. This helped ensure that the architecture of the system was optimized for speed of change.
Conclusion
Microservice architectures provide a number of advantages when it comes to software design. However, successful implementation of this model relies heavily on how the teams responsible for the development and delivery are structured.