In the last article, I talked about the importance of hybrid, multi cloud and edge for enterprises to consider for their application infrastructure going forward. I also touched upon application portability and why it is hard. To appreciate this more, it’s important to understand the application infrastructure stack, it’s complexity and implications on portability.
Application infrastructure stack
We could broadly categorize the application infrastructure stack in the following way
- Physical (and virtual) stack – this includes the compute, storage and network resources required by the application. These resources are often consumed as virtual resources that are software defined and controlled e.g. virtual machines, containers, storage management, SDN.
- Data stack – this includes databases, data warehouses, data lakes, data transformation, analytics and visualization tools.
- Middleware – this includes tools for information exchange between application components and application consumers. They include message bus, data streaming, api gateways, web servers, authentication services etc.
- Management and Security stack – this includes application management tools such as observability, visualization, CI/CD tools and security tools all the way from network to application security.
- Application logic – this includes the overall application business logic that manages the various components of the application stack to achieve the desired outcomes
There is plethora of choices available for each component of the stack as seen in the picture below.
- The choices range from open source based options to enterprise and cloud focused product offerings - an example would be MongoDB open source, MongoDB Enteprise and MongoDB on cloud.
- These components can be deployed as standalone services or consumed as SaaS, offered by both ISVs as well as cloud providers – an example would be standalone Postgres database or DBaaS from the ISVs or providers.
Application infrastructure stack with a sample of choices
The complexity
Depending on the scale and sophistication of the application, many of these components have to be stitched together to compose the application. These components need to work in concert for the application to work seamlessly at scale.
So for most applications, it becomes a complex integration exercise to stitch up an application infrastructure. In addition to integration, complexity also arises in the way the components are orchestrated, connected, secured, monitored. This is further accentuated if the components need to be geo-distributed.
Solving this problem has been the mission of many open source projects as well as companies. Many tools and technologies have been developed to address specific areas of the application infrastructure stack.
For example, Kubernetes has been developed to solve container orchestration and has become the de-facto in the industry. However, Kubernetes itself can be complex to manage and there are a dozen companies trying to simplify it and offer managed Kubernetes. Similar examples can be cited across the stack for connectivity, security, observability and application event and data management.
This is where cloud managed services have offered value to customers by insulating them from the complexities of managing a given tool or technology.
Implications of choices on portability
Based on the choices made for each component of the application infrastructure stack, it can create stickiness to a provider or a location when consumed as-a- service and can have an implication for portability.
Some services and paradigms lend themselves well to portability better than others. For example, Kubernetes based applications can be ported from one cluster or location or provider to another. Whereas, dependency on DBaaS offered by the provider can make it harder to migrate to another provider. So it is important to pay attention to the choices made.
Practical approach
As seen from the picture, PaaS choices are the ones that generally make applications sticky with a provider or a location. However, it’s not easy to walk away from the choices as they offer great value in application management.
A few worthy considerations
- Invest time in defining application architecture. Pay attention and make component and technology choices that are multi cloud capable to begin with and offer portability when needed.
- When looking at PaaS choices, look for vendor offered choices that work across different clouds, on-prem etc. For example, DBaaS offered by database vendors (not cloud providers) work on different clouds, so will make it less sticky to a cloud provider.
- It is also important to pay attention to the API choices too. For instance Kubernetes workloads can be managed with native Kubernetes APIs (kubectl based) or with APIs offered by the provider for their managed Kubernetes. Native APIs will make it more portable in this example i.e. even if the workloads are moved across providers, they can be managed with the same APIs and they need not be re-done with that of new provider APIs.
Some of these may seem more upfront effort, but will surely payback over time.
