Microservices have a somewhat secret meaning in software engineering, which is different from the one you'd most easily discover reading through different technical articles on the subject. The real first-class reason that microservices are gaining so much popularity is that they promise going back to simplicity. Back in the day, things in software were happening quicker. That is because requirements didn't have to be all written down precisely, bugs retrospectively managed, and most of all - teams were just two or three people at most - therefore, they didn't have to be managed according to any sophisticated methodology.
The true reason why we want microservices is the need of stepping back to how the software was built when large systems were scarce and most of the software was built small and delivered quickly. Today, we all decide to accept all disadvantages of microservices in exchange for the productivity and manageability of small software projects. Developers want to be safe to experiment, yet productive and shipping software sooner, instead of going to all sync and status meetings with ever-growing crowds of technical staff building large systems slowly. Instead, we want our software to be small programs again, yet open for change and integration like no large system before. This is what microservices are supposed to be enabling. The real change is not even technical in the first place, because in fact it needs to be organisational first.
The first change on the path to microservices is dividing your teams into domains managed by individual microservices and then designing your systems around those domains and those teams. Secondly, microservices are about building mindsets of independence first. Any technical aspects or benefits of microservice architecture comes second. The autonomy of development teams is by far the most important one. If your microservice teams are forced to use a common framework, or they all fall under the same business management or detailed architecture supervision of their internals - you will fail at building microservices in all other aspects."Aren’t we supposed to be doing big things with big teams? Heavens, no! Big things don’t get done by big teams; big things get done by the collaboration of many small teams doing many small things. This is what the programmers in the 1950s and ’60s knew instinctively. And it was this that was forgotten in the 1970s." - Bob Martin
Taking microservices seriously, we need to build teams that are truly autonomous, even if not completely independent. That means each microservices must be provided with clear boundaries of their domain of interest. Each microservice must be provided with an autonomous team, even if team members are not completely isolated from each other and often times sharing their time with other teams within the company. Most importantly, each team must be provided with the right to choose their own software development methodology, their own leadership and representation, as well as the autonomy of choosing their own technology stack. The important bit of autonomy is completing complete representation of team members allowing independent delivery by the microservice teams. This means that each microservice team must consist of internal indepdendent members, ie. decide if the teams needs roles of leaders, architects and testers, as well as making sure that all required roles are managed internally within the team.
Thinking about the extent of autonomy, all microservices teams must adhere only to common technical inter-service communication protocols, align with the company's business standards and comply with business regulations. Each team obviously must follow the company's ethics, meet the company's mission and targets (both external and internal) - just to maintain the ability to align and re-align with different teams, as well as continue effective communication across the company. The limited scope of autonomy really comes first in order for each team to reach those goals on their own terms.
Companies adopting microservice mindset must accept some level of "controlled chaos" and adopt wide meaning of diversity in terms practices and technologies adopted by each microservices team. Technical, quality and procedural unification must be sacrificed here to a large extent, at least in the short term. Microservices mindset plays well for the evolutionary long run - allowing teams to maintain independence and allowing voluntary sharing of best practices, technologies and processes across teams, on their own terms and in their own pace, as they see them fit.
"In fact the only way to remain true to the original ideas of agile is to build products out of lots of small programs by many small teams." - Bob Martin.
- Author
Maciej Zagozda
Company founder, and director of engineering.
- Comments
- Leave a Comment