Microservices Architecture, The Hard Parts : Multiple Technology Stack — Boon or Curse
Microservices represent a form of Distributed Architecture that offers numerous advantages if implemented correctly. Some of these advantages include —
- Independent Scalability: Each service can be scaled independently based on its specific requirements, allowing for efficient resource utilization and improved performance.
- Independent Deployability: Services can be deployed independently of one another, enabling faster and more frequent deployments without impacting other services.
- Team Autonomy: Teams responsible for individual services have the autonomy to develop, test, and deploy features without the need for extensive coordination with other teams. This fosters faster innovation and reduces dependencies.
- And many more benefits exist, making microservices a compelling architectural choice for modern applications.
Among the numerous advantages, one notable benefit is that teams can leverage the technology stack best suited to implement the business requirements. This could involve adopting a new programming language, utilizing a different database stack, or incorporating a new middleware solution.
While it’s advantageous for teams to have the autonomy to choose the technology stack that best fits their service requirements, it’s uncommon to find multiple technology stacks being utilized in general.
This advantage is something which can easily turn things into nightmare, not for the service owner but when you widen your perspective and look end to end in the context of a running a product as a whole.
Listed below are some of the challenges —
A) Dev Utilisation
When a product comprises hundreds of services, not all services necessitate changes with every release. Some remain stable, requiring no feature enhancements. Consequently, teams overseeing these services may find themselves with insufficient tasks, leaving developers with idle time. To mitigate this, it’s crucial to allocate developers to other services. Yet, transitioning developers is smoother when the technology stack remains consistent. Conversely, with varied technology stacks, there’s a steep learning curve and potential apprehension among developers.
Moreover, there are scenarios where permanent reassignment of developers isn’t ideal, but loaning them temporarily to aid another service with a major feature release due to time constraints is necessary. However, if the technology stack differs, the learning curve becomes a significant impediment to loaning developers from other teams.
Needless to say, the challenges of hiring developers are well understood. Introducing new technology stacks exacerbates this challenge. Each new technology stack necessitates finding developers proficient in that particular technology, further complicating the hiring process.
B) Customer Support Team Struggle
Having a limited technology stack simplifies the task for the Customer Support (CS) team in aiding customers with issue troubleshooting. Conversely, with each new technology stack introduction, training becomes necessary for the CS team to comprehend the service implementation.
Furthermore, this places additional responsibility on the Developer Team as they must now create a Runbook detailing the specifics of the new technology stack for the CS team to effectively troubleshoot issues.
C) Operational Challenges
Numerous operational challenges arise when dealing with multiple technology stacks. Here are some of the primary ones:
1) Challenge in creating a new microservice — In the Microservices paradigm, it’s common to observe multiple features that could function as independent services being consolidated within a single microservice. This consolidation isn’t necessarily due to teams being unaware of the issue.
Instead, it may stem from a lack of well-defined boilerplate templates for creating new services. Consequently, whenever a new service is needed, teams must invest time into crafting a new microservice. Unfortunately, time is often a scarce resource for teams.
Therefore, they may opt to integrate the new feature into an existing microservice where it fits well.
However, if your product employs multiple technology stacks, developing and maintaining boilerplate code for each technology, while adhering to best practices and standards, along with implementing continuous integration and continuous delivery/deployment, can become a costly endeavor.
The boilerplate code will encompass several crucial elements, including a well-defined code structure adhering to best practices, comprehensive testing strategy, efficient database connection pooling, robust logging mechanisms, and more. Additionally, it will incorporate a Continuous Integration/Continuous Deployment (CI/CD) pipeline that covers essential stages such as Build, Test, Code Coverage analysis, Deployment, and others.
2) Challenge in giving Access to Teams — When employing different types of database technology stacks, managing access for Development (Dev) and Customer Support (CD) teams becomes challenging due to each database’s unique access management methods. Thus, each new technology stack presents additional challenges for the Operations team, particularly from a security perspective.
3) Challenge with Security Risks — From a security standpoint, every shared library utilized across various technology stacks necessitates vigilance for newly discovered vulnerabilities and prompt resolution. Additionally, comprehensive guidance and best practices must be provided for developing microservices with the new technology stack, prioritizing security considerations throughout the process.
D) Sharing Code across Services
In the realm of Microservices, sharing code is typically discouraged to prevent potential dependencies if not carefully managed. However, there are instances where utilizing a shared library may be justified.
Consider this scenario: if your product employs multiple technology stacks and a minor feature update is requested for the shared library, implementing this update across all technology stacks could become a labor-intensive task. Over time, this could evolve into a significant maintenance challenge.
You can read more on Sharing code in Microservices Architecture in my blog —
E) Debugging Complex Issues and Performance tuning
There will inevitably come a time when performance issues arise within your services. Identifying these issues is no simple task and requires a profound understanding of the technology stack utilized in constructing the service. If multiple technology stacks are employed across various services, finding individuals with such deep expertise in each area becomes exceedingly challenging. Moreover, seeking assistance from other teams becomes impractical, as they may lack familiarity with the specific technology stack in question.
After understanding the challenges associated with employing multiple technologies in a Microservices Architecture, you might be inclined to believe that the solution lies in solely utilizing a single technology stack for all Microservices. However, this isn’t necessarily the case. It’s essential to establish certain boundaries. Instead of allowing individuals to independently choose the technology stack, it’s advisable to designate a central team responsible for conducting due diligence concerning Security, Support, and other crucial aspects.
Hope you enjoyed reading this blog. Do share this blog with your friends if this has helped you in any way.
Follow me here on Medium and/or on LinkedIn to read more of such blogs on Microservices, Event Driven Architecture, Kubernetes, DevOps and many more.
Happy Blogging…Cheers!!!
#Microservices #MicroservicesMultipleTechnology #MicroservicesChallenges
