The Microservices Leap
During my work with delivery teams on solution designs, I noticed a common set of misconceptions regarding Microservices architecture and Azure Kubernetes Service (AKS).
I will use the following simplified solution to highlight the key points in this article. It represents a typical AKS solution with the key components that include a load balancer, web application firewall (WAF), Identity Provider, Networking components, Monitoring platform, ingress controller, secret management service, and one or more backend data stores.
In this article, I will share 3 of the most common pitfalls in thought process when evaluating Microservices architecture and Azure Kubernetes Service (AKS) in the design phase.
Pitfall#1 More Control
Teams, especially who are new to the organization, would sometimes prefer containerization as a way to gain more control over their solutions with the hope of being abstracted away from the organization’s landing zone controls, processes, and people.
This is a misconception, as the containerized solution will still be dependent to a certain degree on the encompassing landing zone’s structure, networking, IAM, governance and security controls.
Even more control
Other times, the development spirit would be so high in the team when evaluating PaaS solutions against Container-based solutions. In one case, a technology enthusiast wanted to leverage Kubernetes-based Event Driven Autoscaler (KEDA) with Kubernetes to achieve the PaaS autoscaling capabilities and thus have more control.
While KEDA has its valid uses cases, you should be careful of being dragged to develop everything yourself just to get a false sense of control. After all, cloud platforms’ PaaS offerings abstract us away from this type of technical plumbing to mainly help us in achieving productivity gains and agility.
Pitfall#2 Solution Portability
“Having a containerized solution would make it platform agnostic, so it would be portable to any other platform, and the solution will become future-proof“.
Let’s try to re-phrase the above statement a bit to make it more objective: “A containerized solution will be less coupled to the underlying platform, it will be leveraging proven, mainstream container platforms of today that probably will remain relevant in the near future“.
Aiming for a portable solution in our example means that the solution should strive to avoid leveraging Azure’s native workloads such as Azure’s Load balancer, WAF, Azure AD, Key Vault, Azure SQL, Azure Monitor, Application Gateway Ingress Controller (AGIC), and even the IaC ARM templates that are used to deploy those resources.
Instead, vendor-neutral equivalents for those native resources should be used whenever possible. In this case, NGINX could be used for the ingress controller, Prometheus for monitoring, HashiCorp Vault for secret management, Terraform for IaC, and so on.
An alternative technique would be to introduce an abstraction layer between the containerized application code and its cloud’s native dependencies. A configuration-based tool like Distributed Application Runtime (Dapr) would be perfect for creating such an abstraction in flexible manner, it will provide a level of indirection to the application code when integrating with cross-platform dependencies.
Regardless of which technique is used, it is quite obvious that aiming for a higher solution portability will increase the solution’s complexity and cost, so this decision would better be backed by a well-thought-out multi-cloud strategy, or at least a clear business requirement.
It is important to highlight that realistically, a true vendor-agnostic solution would not be possible, you can’t completely eliminate all of the underlying platform dependencies. In our example, think of Azure’s VNET, DNS, user-defined routes, VPN Gateway, Resource Groups, to name a few.
Consequently, solution portability can be achieved to a certain degree, you can think of it as a spectrum showing the possible degrees of solution portability on a target platform, in this case it is Azure.
The solution, denoted by a cube, which is on the far left of the spectrum is highly coupled to Azure, which means that it is highly integrated to Azure ecosystem and therefore is less portable.
On the opposite side of the spectrum, the other solution is loosely coupled to Azure and thus less integrated to its ecosystem which makes it more portable.
Notice here that I am intentionally avoiding the use of the word “platform-agnostic”, as it implies that a solution is completely independent of its underlying hosting platform.
Pitfall#3 The Leap
Sometimes, teams can get obsessed with container technology platforms and their impressive features and they would often recite their numerous features as a way to justify their selection. This is actually an unintentional leap towards Microservices architecture.
Microservices is an extreme architecture style which has legitimate use cases. It is like any other architecture style; it comes with benefits and drawbacks which could drastically vary in different contexts.
Accordingly, opting for this architecture style and its accompanying technology platforms should first be justified by the business requirements and its overarching goals.
Starting from the technology standpoint will lead to an accidental architecture that may not be the best fit for the business context. Instead, the business context should derive the architecture style which in turn should guide the technology selection process.