Primer: Understanding the Cloud Native Impact on Architecture
In today’s race towards digital transformation, architectural best practices are often sacrificed for speed. Yet the gained edge may be short-lived. Technology is developing at a rapid pace and enterprises must leverage future innovations — such as cloud native technologies — to pivot quickly and meet market demands.
While a well-designed, modular cloud native architecture requires a little more time and resources during the planning and implementation phase, it will also enable IT to adapt and extend it as new technologies hit the market. A system developed without these considerations in mind may be up and running faster but will struggle to adapt as quickly as business needs evolve.
As outlined in our previous article, there are multiple ways of organizing applications into logical components (software architecture considerations). These components are then placed on different physical machines (system architecture considerations). Clearly, technology developments impact both software (e.g. how components communicate, let’s say via a service mesh like Linkerd) and system architecture (e.g. the containerization of applications that detach them from the underlying infrastructure).
Openness, modularity, and flexibility have always been goals of distributed systems (all architecture qualities). The cloud native revolution is bringing these characteristics to a whole new level. Here’s three ways how:
1. Containers Make Apps Infrastructure-Independent
Containers allow us to isolate services by bundling them with all dependencies into a portable (movable between environments) package, making them completely infrastructure independent. That means it’s much easier and faster to adjust system architecture on runtime.
2. Kubernetes as Infrastructure Abstraction
Kubernetes can be seen as a data center operating system that manages all underlying resources. It has the potential to abstract at an infrastructure-level, creating a giant pool of resources. Developers needn’t worry about infrastructure differences anymore. They simply deploy on Kubernetes, and Kubernetes takes care of the rest.
3. Cloud Native Services, the New Cloud-Hosted Services
Cloud native services are the new counterparts of cloud-hosted services. While the latter are bound to one cloud (and if hardcoded into the app, so is the app), cloud native services work across environments.
Did you notice the common denominator? It’s infrastructure independence.
Traditionally, whether you deployed on-premise, Azure, AWS or Google Cloud Platform (GCP) you’d need to use a different stack. Each environment has its own specific technologies optimized for that particular infrastructure. Developers who built applications for a specific environment, ended up with apps bound to that particular infrastructure and services. Moving apps meant re-configuring them so they could run somewhere else. Cloud native technology, on the other hand, allow for a flexible architecture that is able to adapt to market demands — a true revolution.
This Is Why IT Cares
- By abstracting at an infrastructure level, all underlying resources merge into one giant pool of resources developers can tap into. Differences don’t matter anymore. Kubernetes will deal with all those details, not the developer.
- Containers package everything the application needs so it can be moved between environments on runtime with no downtime. As far as the containerized app is concerned, it’s running on Kubernetes, whether on-prem or GCP is irrelevant.
- Cloud native services are available across your environments. So if you move your containerized app from on-prem to GCP, you can still use the same services — no configuration required.
That being said, you can still use cloud-hosted services. In fact, if they work for you, they may be your best option. Unless you hardcode them into the app, you can still move your apps between environments. It will require some reconfiguration to switch to compatible services, but if following architecture best practices and clearly separating apps and services, you still keep a lot of flexibility.
…And Why You Should Care
This translates into unprecedented flexibility and modularity, allowing IT to pivot quickly and adopt new technologies as they hit the market. Vendor lock-in is no longer a necessary evil. The ability to rapidly adapt to market demands is key to staying competitive in today’s technology-driven market and should thus be at the core of any business strategy. While cloud native can deliver on that promise, whether it does or not depends on how these technologies are implemented (assuming architecture best practices were followed).
This is the point where you will have to engage in strategic discussions with your IT team. Understanding the implications, in the long run, is key when deciding on which route you’ll go.
Opinionated Open Source: Beware of the Quick Fix
There is often a sense of urgency when adopting cloud native technology. Enterprises wish to speed up service delivery to beat or keep up with the competition. Since internal expertise is still developing, these organizations are seeking a quick and easy way to get started. While some options may deliver on this promise, they may not be as flexible, slowing future adoption down. It is relatively easy to see how this can happen with proprietary closed source products, however, many products that claim to be open source can be prone to the issue as well.
We call this new breed of technology “opinionated open source.” It’s based on open source but tied to a particular infrastructure or technology stack, often modifying the original open source technology. Even though the modifications may be open source as well, they are specific to the direction selected by the vendor, and not supported by a wider community. While it may meet your needs today, it won’t allow you to adapt when enterprise requirements and market demands shift. Yet again, you’ll find yourself locked in and unable to pivot.
Instead, as you adopt the cloud native stack, ensure it’s infrastructure-independent and compatible with any cloud native stack. Aim for:
- Infrastructure independent applications (containerized)
- An infrastructure abstraction layer (Kubernetes)
- Infrastructure independent services (cloud native services or cloud-hosted services that aren’t hard-coded into the app)
By following these software architecture best practices, such as a clean separation of layers, you’ll gain a truly modular, flexible and open system. As for the Kubernetes layer, you can either build it yourself or use an enterprise-grade platform like Kublr that follows this approach. Either way, avoid focusing solely on meeting today’s requirements (we all know they will change). Build/buy a modular, future-ready architecture that can keep up with your fast-evolving business demands.
As usual, a big thanks to Oleg Chunikhin who was instrumental in getting all technical details right.
