If we say, "This is an era dominated by technology from left to right," it would not be a metaphor. Equally, it is important for everyone, apart from the engineering team, to keep pace with it, understand the jargon, and focus on how it operates behind the scenes. It also becomes essential if you are a product manager, regardless of whether you recently started in this position or are experienced. As a product manager, a crystal-clear understanding of technology is essential.
So, we are going to delve into the journey of a product manager with microservices.
These days, the term "microservices" is quite common, and we encounter it during our daily journey at the office. At the very basic level, microservices represent an architectural design pattern; they are not programming languages. This architectural style can be adapted to work with any programming language, assuming an ideal case study. Think of microservices as building blocks, where each block holds its importance. However, the key distinction is that they do not function like traditional building blocks. If you were to remove one block from a building, it might cause the entire structure to collapse or lose its meaning in terms of completeness.
In the realm of microservices, each unit is independent and possesses full completeness within itself. You might wonder why we need the microservices pattern, and this is a valid point that the product team may raise. The fundamental principle behind the emergence of microservices is the elimination of dependencies. When we refer to dependencies, they could manifest at the code level, in business processes, or even in reliance on specific individuals. Therefore, instead of having a single, monolithic codebase cycle, it is divided into multiple independent components, each of which continues to function as expected even when detached from its parent structure. So, if the engineering team is constructing something entirely self-contained in every context and still satisfies the business process requirements, we can say they are building with the microservices concept.
The essential elements that come with microservices are flexibility and a modular approach in engineering. Although it's possible to achieve these aspects in other contexts as well, microservices completely decouple them. This adaptability provides a competitive edge to the product team, enabling them to continually request the development of new features within one block without considering the impact on the others.
On the other side of microservices, there's the ability to independently scale up or down according to the specific needs of the business. This exercise assists in improving the overall performance and reliability of the application and, from a business perspective, enhances flexibility while reducing costs. Understanding the core principles of microservices or any other architectural pattern aids product managers in their decision-making processes when considering the needs of the business.
In the context of understanding the product team broadly, there are three major components:
- Frontend and Backend Code
- APIs
- Database
Please note that we are not discussing micro frontend architecture at this time. When considering the code, it is divided into two sections: frontend and backend code repositories. Additionally, there is a database (which may involve various database approaches) and APIs to facilitate communication between the frontend and the database, as well as vice versa.
It's important to note that in the context of engineering, these components represent an overview, and we are not delving into the detailed implementation architecture of microservices here.
Examples of microservices:
Social Media: As we discussed the importance of flexibility, major social media platforms like TikTok, Facebook, and Twitter have adopted the microservices pattern. When we consider various use cases, the social media platform is ideally suited for this approach. For instance, functions such as subscriptions, liking/disliking, post management, notifications, document uploads, and comments all operate separately and independently from each other.
E-commerce: Amazon serves as an excellent example to understand how microservices are applied within an e-commerce platform. Key functions like item purchasing, payment processing, product features, invoice generation, and order management are all independent services.
Cloud Services: AWS and Azure services also integrate microservices into their applications. In this broader context, modules like user management, document management, subscription, and permissions are excellent examples that are part of different services.
Another perfect use case for microservices is seen in OTT platforms, and Netflix has already adopted the microservices architectural design pattern across all its services. Given the user base and the need for scalability, microservices fit seamlessly into this style. These are just a few examples, but the point here is to highlight and understand the use cases and success stories of enterprises using microservices.
While we've discussed the broad advantages of microservices, it's crucial to acknowledge that there are also grey areas to consider. Ignoring these aspects could potentially turn microservices into a nightmare for enterprises.
Complexity: The independence of all services can lead to increased complexity. Despite their autonomy, coordination is still necessary between these services, which can elevate complexity levels and extend development and maintainability timelines.
Lengthy Troubleshooting: Due to the nature of microservices, troubleshooting can become challenging when dealing with multiple services.
Latency and Speed: Communication between microservices can introduce overhead and latency, which may impact the overall system's performance.
Cost: Operating microservices tends to be more expensive as they require additional infrastructure to support individual services.
These are essential points to understand. However, it's worth noting that there are steps that can help mitigate the risks associated with microservices. Overall, while microservices offer numerous benefits, product teams should remain mindful of their potential drawbacks. From a product perspective, one of the most challenging aspects of transitioning to microservices can occur when a company is burdened with technical debt and aims to shift from a monolithic architecture.
Let's explore some strategies to potentially address these challenges.
Evolving from a monolithic architecture to a microservices
Uncover Business Capabilities: A service-oriented architecture adopts a business-centric perspective of your application. To initiate the development of services, your first step is to pinpoint the specific business operations that each service will execute. Identify the core business capabilities inherent in your application, and then segment them into autonomous services. This typically entails dissecting the monolithic codebase into smaller, self-contained functional units.
Cultivate and Validate: Foster the growth and validation of each service autonomously, harnessing the power of continuous integration and continuous deployment (CI/CD) processes.
Establish Communication Mechanisms: Instigate robust communication and coordination mechanisms among diverse services, exemplified by the use of APIs.
Deploy with Precision: Execute the deployment and management of services using containerization and orchestration platforms like Kubernetes. This ensures their scalability, resilience, and streamlined updateability.
Post-Launch Vigilance: After launching, meticulously oversee and assess the performance of individual services and the overarching system. Continuously iterate and enhance the microservices' design to achieve optimal efficiency.
It's crucial to acknowledge that the shift to microservices can be intricate and time-intensive, often necessitating substantial investments in development, infrastructure, and tooling.
In an ideal scenario, the transition to a new architectural pattern should be an incremental journey, moving each component of your current architecture one step at a time. However, practicality sometimes dictates otherwise. From a product standpoint, when your team is embarking on such an architectural transformation, meticulous planning becomes imperative. This ensures a seamless transition without disrupting the existing application and maximizes the advantages of the new architecture.
Importance of architectural considerations for Product Managers
Security – Having a comprehensive overview of your applications assists you and your team in identifying potential security risks. One of the most common ways products become vulnerable to attacks these days is through endpoint exposure. If those endpoints aren't secured, they could expose your product to malicious attacks. Understanding your architecture will provide insight into the security risks your product might encounter.
Scalability – Poor architectural decisions will inevitably affect your ability to scale. If you anticipate that a new feature will be utilized by millions of customers, it is essential for the product and engineering teams to grasp how architectural choices may influence the product's scalability.
Technical debt - Tech debt often accumulates as a result of architectural decision-making over time. It is an unavoidable aspect of product development as team members change, and new decision-makers come on board. However, one principle that all teams can adhere to, even with changing team members, is this: build for adaptability, not for longevity. Competent tech leads will anticipate change and construct solutions that account for future changes.
In a broader context, product managers should cultivate a profound understanding of microservices and their potential ramifications on product development and upkeep. This expertise equips them to make well-informed choices regarding the incorporation of microservices into their product strategies.