What Lies Beyond a Microservice Architecture? — The Change
In the previous part, we discussed “Architectural Bad Smells” and you learned about some approaches to understanding when a potential architectural change might occur. This change isn’t solely based on feelings but is supported by metrics and the measurement of complexity using the Big-O notation.
This article will help you understand what lies beyond a Microservice Architecture and how to move forward with this architectural decision, enabling you to grow your company, develop new products, and build new teams!
What happens after a company adopts a microservice architecture? As we have observed in the market, for many companies, after adopting it, their architecture may resemble a collection of Lego pieces on a table. Don’t you think so?
This can occur when a company experiences rapid, often disordered growth, sometimes triggered by a new round of third-party investment or even an internal decision. As software developers, we never know how and when it might happen. The only certainty is that it will impact the software and architecture!
Building one architecture capable of supporting this change is not easy, even when applying the best software development practices, depending on the size of the architecture, it can be quite challenging! This scenario often brings to mind the principles I learned from Rebecca Parsons’s book “Building Evolutionary Architecture”, which emphasizes the concept that, like software, architecture is a living entity! It’s crucial to build it in a way that is open to change, capable of evolving, and adaptable.
To achieve this, in recent years, the concept of Distributed Platforms has been gaining space in BigTechs. This concept, as outlined in the book “Team Topologies” by Matthew Skelton and Manuel Pais, emphasizes optimizing the structure of software development teams to enhance software delivery and foster an effective community. From an architecture perspective, Distributed Platforms provide a means of implementing this concept not only for teams and individuals but also for your architecture.
The concept of Distributed Platforms is similar to building an entire Lego City. Similar to a real city, you will define neighborhoods, that would be seen as a Platform, with specific responsibilities. Some neighborhoods focus on commerce, while others are designed for residences. This diversity mirrors the way platforms can be organized, with each one handling a specific context
Platforms are like Neighborhoods in a city
Here are some key takeaways to help you implement this concept:
1) Set The Platforms Boundaries
If you live in a small city, you may be familiar with the practice of using streets and avenues to define neighborhood boundaries. For platforms, it's the same! Streets and avenues can be likened to communication protocols. To access them, you must use specific communication methods such as HTTP, gRPC, and Message Brokers.
By establishing a clear communication protocol for accessing your platform and understanding its usage, you can avoid exposing internal details that should remain hidden (for example, internal domains that shouldn't be exposed).
2) Implement “public” communication over “private” communication.
In architecture, the more specific communication you have, such as having endpoints dedicated to exposing data for individual services (similar to a 1–1 relation), the more complex the maintenance becomes. Like in a city: if you focus solely on building streets and avenues for cars, you will suffer from traffic congestion. Therefore, emphasizing the creation of a “public”/generic mode of communication between the services can help reduce potential issues (remember about low coupling, high cohesion?)
To achieve this, you should concentrate on exposing data that multiple clients/services can utilize. For instance, consider using more generic endpoints that provide information usable by more than one service (exposing endpoints similar to 1-to-N usage); Additionally, you can employ message brokers and implement data streaming using an event-driven design pattern.
3) Build a Community
In each platform, you may have a team working on it, whether it’s 10,20, or 100 people. Aligning your team’s purpose is crucial for building a robust and scalable platform
When something involves a purpose and a large group of people, the concept of community immediately comes to mind as the way to achieve it. Creating a community implies establishing principles that make individuals feel that they belong.
For that, I strongly recommend the reading “The Art of Community — Seven Principles for Belonging” by Charles H. Vogl. which helps you with an insightful guide for building a community.
The key insight I’ve gained is the importance of fostering a sense of belonging among people. Working with platforms is not easy, and individuals may be focused on solving their own problems, occasionally overlooking the broader context. Emphasizing this can help people realize that even while working on their individual platforms, they are part of something bigger — the company’s overarching purpose, which encompasses the collective efforts of all the platforms working together.
In conclusion to these 3 articles, you have learned why software should be viewed as a living organism rather than a static tool; You’ve also discovered how to build a case for advancing to a new architecture decision by using metrics, identifying architectural ‘bad smells,’ and applying the concept of the Big-O notation. Additionally, you’ve explored the significance of organizing your microservice architecture into distributed platforms and three key concepts to aid you on this journey!
