The Importance of Application Portability

I have to rant a little bit. Recently I was involved in a conversation about the wonders of devops and how it was changing the concerns of IT. The conversation spawned from the growing importance of cloud providers and the impact they are having on enterprises of every size and across industries. Specifically, with the high-quality services the cloud providers are now offering, new services seem to come out monthly, the thought of moving applications onto the cloud and rebuilding them with the cloud provider tools is a seriously interesting idea. I am fine with that, this isn’t my rant.

It was the context of devops solving the issues of ‘lock-in’ that seemed like a giant leap of faith.

The line of thinking was along the lines of, ” … with a devops approach and the idea that IT is going to continuously build and refactor their applications, the concept of being locked into a set of application dependencies is no longer an issue … ”

This I can’t buy into. Having worked with IT organizations trying to modernize segments of their application portfolio for the past few decades, not acknowledging the deep set of application dependencies that makes an application ‘sticky’ seems like denying our history and repeating our mistakes.

Applications are sticky with respect to the application languages, their tooling and architecture, the services the application leverages and depends on, as well as the surrounding business practices and processes that are formed to match the application’s resulting workflow.

This stickiness is real, and it should be acknowledged and accounted for. While it may not seem like a big deal today when you can build what seems like the perfect application with today’s coolest services at your fingertips, it may not seem so cool a few years down the road. The smart way to proceed, account for the concept of portability from the start. You never know when it may benefit your company to have options on where an application runs.

Case in point, in talking with manufacturer last month, we were talking about their interest in building applications in our (SUSE’s) new Cloud Application Platform. This is SUSE’s Kubernetes-based implementation of Cloud Foundry. During this conversation, it was stated it was their intent to build their applications in a specific cloud provider, and that they really didn’t have any current need for a data center presence. Intrigued, I asked if they were only going to target a single CSP, why were they looking at our option of creating a CSP independent layer for their workloads. The answer was very practical and straightforward, we can’t afford to put our mission critical assets in a place that could become a barrier to our pursuit of business in the future. They stated that they may need to conduct business in places or with others in such a way the their preferred CSP could not support. They were planning from the start to build applications that could always be portable.

This line of thinking I completely buy into. It is why I so much enjoy working on SUSE’s Cloud Application Platform. As alluded to, this is a Kubernetes-based implementation of Cloud Foundry. It is a unique architecture that allows one to install a full Cloud Foundry workflow into a Kubernetes cluster. By design, the cluster can be run in the data center, or it can come from a cloud provider directly.

The result, you have a platform for your workloads that can span cloud providers as well as data centers – your workloads (applications) don’t have to know or care where they are running. And in addition to that, our Cloud Application Platform is also a certified Cloud Foundry distribution, fulfilling on the promise that even at the workload level, if you need to move to other certified Cloud Foundry solutions, you can.

The implied point that I truly believe is worth building into your applications, abstraction layers. If you have the opportunity to build your applications in a way that abstracts them from specific cloud platform dependencies, but still lets you enjoy running on them, you should pursue the option. In addition, if you can ensure that the abstraction layer you choose isn’t a one stop shop option, more than one vendor supports the abstraction layer, then you are even better off. 

When you look at building or refactoring your applications, do you think about these two key levels of abstraction?