Is being cloud agnostic even possible?

Is being cloud agnostic even possible

Is being cloud agnostic even possible?

Written by David Linthicum for Nelson Hilliard

The idea is rather simple and rather old.  If you’re going to build and deploy applications do so in such a way that those applications can run on any number of platforms (or clouds), typically without modification.

The business benefit of this is obvious as well.  The time saved in rewriting applications can be dedicated to other things, which is nice.  However, the core business benefit comes in the form of agility and time-to-market advantages; applications can be moved platform-to-platform, as needed by the business. 

However, nothing is ever perfect.  The approaches to building applications that are platform or cloud agnostic vary a great deal.  What’s more, there are always some tradeoffs to consider, including access to native platform features, performance in some cases, and even high costs.  But, the benefits could easily outweigh the downsides, when considering the concept on its whole.

While there are many different approaches, the three basic patterns to support application portability for cloud-based platforms, include:  Use of standards, use of abstraction, and use of containers.  Let’s walk through the basics of each.

Use of standards

I’m an older geek, so I certainly remember POSIX.  POSIX was an acronym for “Portable Operating System Interface,” which is a group of standards supported by the IEEE for maintaining compatibility between operating systems.  When you write your programs to the POSIX standards, you can be pretty sure the programs will port easily among a large family of Unix derivatives (including Linux), and thus why writing to the POSIX standard made sense.

The concept is pretty straightforward; force the platforms to maintain a set of APIs that are consistent from platform to platform.  However, the tradeoff is that, in order to maintain compatibility, then the non-standard APIs (or native APIs), are not to be leveraged.  Thus, you lose the benefits of those platform’s services.  It’s no different when looking at application portability between modern cloud platforms.

These days there are new application portability standards to consider.  These include OASIS, the Open Group, and OpenStack, and each come with their own degree of traction.

OpenStack has the most promise and has delivered on cloud interoperability (basically the same thing as app portability), moreso than the other standards.  OpenStack also has the most support from technology providers such as IBM, HP, Cisco, Rackspace, and others. I consider an OpenStack project as probably the most focused and most likely to accomplish something useful around the domain of application portability between OpenStack-compliant public and private cloud platforms.

However, the degree of success of any application portability standard will be the ability to expose the cross-platform interfaces.  The more capabilities the common interfaces provide, the more likely the standard will provide the value it should provide, both in support of applications on the specific platforms, as well as the ability to move applications from platform to platform without giving up most native features and functions. 

Use of abstraction

Abstraction is often an approach to application portability that provides the most simplicity, but the most number of tradeoffs as well.  PaaS providers are looking to exploit the core need to build an application once, on their platform, and move to any number of IaaS providers with very little effort.

The approach that some PaaS providers take is to provide the ability to abstract out the differences within the underlying infrastructure in such a way that, once the application is built and deployed, customers can move applications between cloud providers.  This is the PaaS providers’ approach to being cloud agnostic.

Generally speaking, the abstraction approach has a few core advantages, which include the fact that you have someone who will account for the differences in platform services using a translation layer.  The cloud provider does not need to write its platform to a standard interface, such as the ones listed in the previous section.  This means the cloud provider can support a wider array of very diverse platforms.

The tradeoff is performance, in some cases, having to go through the translation layer to access application services.  Also, this is a least common denominator approach to support each cloud platform.  These are issues to consider as you evaluate platforms that provide cross-platform application portability using abstraction.

Use of containers

Some consider containers to be the preferred approach to application portability.  This can even be an approach to application portability that can work around the issues of leveraging virtualization.

When you think containers and cloud, you have to think about Docker.  Docker, an open source project, provides a way to automate the deployment of Linux applications inside portable containers.  It’s a standard, but I believe it needs to be broken off into its own category. 

These Docker containers can move from cloud to cloud, at will, to provide application portability as well as a much more fine-grained approach to workload distribution. 

The underlying approach is not new.  We’ve been using containers for years to componentize whole systems, abstracting them from the physical platform, so you can move them from platform to platform.  Docker brings the container approach to the cloud, so you can move Linux applications from cloud to cloud.  As time progresses, this architecture may be applied to other OS’s and take on other capabilities. 

Docker is a much lighter-weight approach to application portability than we’ve had available in the past. Docker extends a common container format called Linux Containers with a Linux kernel and a high-level API that, together, run processes in isolation: CPU, memory, I/O, and network.  Docker also provides namespaces to completely isolate an application’s view of the operating environment, including process trees, network, user IDs, and file systems.

Most consider Docker’s lightweight platform abstraction as much more efficient than traditional VMs for creating workload bundles that are transportable from cloud to cloud. In many cases, virtualization is too cumbersome for cloud portability, and thus not listed in this short report.  However, it’s another approach to application portability that deserves consideration.

Picking a path

The approaches listed above, and the technologies that support them, will provide application portability for those who need it.  Of course, all approaches have their good and bad points.  You need to carefully weigh your options before selecting the right path for your apps. 

As time progresses, I suspect that the use of containers as an application portability approach will be just too compelling.  We seem to like more lightweight approaches that can be easily broken apart.  What’s more, containers better support a complex and highly distributed model, and that seems to be where cloud computing is headed.

As we move to the cloud, including the migration of applications, portability needs to be a key consideration.  Now is the time to select strategic paths to the best approaches and enabling technology.  Do your homework and pick well.

Remember to Subscribe to our Youtube Channel for the Latest Cloud Computing Tech Jobs, News, and Cloud Shows.


David S. Linthicum is a managing director and chief cloud strategy officer. David is internationally recognized as the worlds No.1 cloud computing industry expert, pundit and thought-leader.

(Disclosure: David Linthicum’s views in the blogs, video shows and podcasts are his OWN and are NOT financially sponsored by Nelson Hilliard)

Connect with David on LinkedIn and Twitter

At Nelson Hilliard we specialise in cloud technologies, sourcing the top 20% of cloud professionals inspired to work for you through our specialised marketing and profiling. If you are interested in having a quick talk to me regarding your employment needs please feel free to reach out.

You can also check my availability and book your 15 minute discovery call here.

Brad Nelson