How to tell the Difference between Cloud-Native and Cloud-Enabled – and Why it Matters

sorry, no photo for this author is available
Oct 27, 2016 - By Imagine Communications
Subject Matter Expert

It’s easy to confuse Cloud-Native and Cloud-Enabled. In addition to a strong resemblance, the two hyphenated words are frequently used interchangeably to describe an application that has been abstracted from underlying hardware and is now accessible from a virtualized setting.

But that’s where the resemblance ends. When it comes to seizing the inherent benefits of a cloud environment and injecting your media operations with new orders of agility and efficiency, the gulf between Cloud-Native and Cloud-Enabled couldn’t be wider.

Here’s how a blog on IBM’s developer web site distinguishes the two adjectives:

You can say that a cloud-enabled application is an application that was moved to cloud, but it was originally developed for deployment in a traditional data center. Some characteristics of the application had to be changed or customized for the cloud. On the other hand, a cloud-centric application (also known as cloud-native and cloud-ready) is an application that was developed with the cloud principles of multi-tenancy, elastic scaling and easy integration and administration in its design.

As software-defined networking (SDN) and the cloud have gained prominence in the media & entertainment industry, more and more technology vendors are reaching for the heavens to describe their efforts to relocate applications residing on premises-based appliances to virtualized settings by simply encasing them in what amounts to an IP wrapper.

Baby Steps

These cloud-enabling efforts, don’t be mistaken, represent a vital step in the evolution of media production, playout and distribution processes. Shedding applications of their dependency on specialized hardware is a very meaningful prelude to a full embrace of all the performance, scale, reliability and efficiency benefits of the cloud.

But to tap into these capabilities and to fully exploit their benefits requires designing and building an application from the ground-up with virtualized environments in mind. What makes the cloud such a powerful and hyper-efficient environment is that it comes with specialized orchestration and automation built into it. Cloud-native applications have the capability to seamlessly tap into all the goodness of a distributed and geo-diverse environment, which includes scaling resources up and down as needed, robust reliability and easily setting up redundancy and business continuity scenarios.

Cloud-enabled applications, by contrast, are designed for static environments. Applications that have been merely enabled for the cloud can be positioned tantalizingly close to these performance-enhancing and cost-efficient capabilities, but lack the ability to tap into them. It’s a high-tech case of “water, water everywhere but none to drink,” and media companies that mistake cloud-enabled for cloud-native will barely get a sip of the business-sustaining benefits of full-scale virtualization.

Cloud-Native Certified

A complication for media professionals anxious to pursue a cloud-native architecture is that technology vendors are beginning to conflate the two terms, making it difficult to sort out what is truly cloud-native. Sadly, a Cloud-Native seal of approval or certification has yet to emerge.

Until one does, here are three foolproof questions to help you separate the Cloud-Enabled from the Cloud-Native:

 

Is the application based on a microservices architecture?

If the application you’re interested in is based on microservices, you can be assured that it’s cloud-native — but also capable of running in on-premises or hybrid environments.

A microservices approach to application development is a deconstruction of monolithic application design. As the name suggests, an application based on microservices is composed of small, mostly autonomous components that often perform a specific function or capability, such as encryption or compression. A cloud-native application will be composed of multiple microservices that interact through a shared fabric. A major advantage of microservices over monolithic design is the ability to troubleshoot, monitor and update on a service-by-service basis, rather than dealing with the entire application.

The Internet uses microservices design principles, giving applications based on the architecture similar attributes, including the ability for specific capabilities to be updated, modified or replaced without disrupting the overall application.  Most importantly, a microservices design enables the near-instantaneous incorporation of new functionality and features. Applications based on microservices are easily augmented with third-party capabilities, for example, which can often be added in a matter of days. This is a stark contrast to monolithic applications that often follow annual or biannual update cycles.

If the application you’re interested in is based on microservices, you can be assured that it’s cloud-native — but also capable of running in on-premises or hybrid environments.

Does the application support continuous software delivery?

Continuous software delivery, or innovation, is a more formal way of describing the ability of cloud-native applications to reside in a perpetual state of updatedness. The component nature of an application that was born in the cloud makes it possible for media companies or their vendors to continuously augment their operations with the latest technology and advanced features.

The technology landscape is evolving faster than ever and continuous software delivery is the only way to future-proof your workflows without suffering through frequent and wholesale replacements of applications and platforms. Continuous software delivery is all about being able to augment applications with the latest technology without requiring a wholesale upgrade. If your technology vendor tells you that support for a popular file conversion option, for example, won’t be available until after the next upgrade cycle, chances are they are still dwelling in the cloud-enabled realm.

How long has your technology supplier been talking about SDN and Cloud?

Designing cloud-native applications doesn’t happen overnight.  An authentic cloud-native application is likely the result of years of extensive research and development. Many technology suppliers lack the resources to fully commit to a cloud-native development program or they have been rendered flatfooted by late-to-the-party recognition of the need for a new technology foundation to support evolving video consumption preferences and business models.

Unless you can uncover evidence that your technology supplier had started down a software-enabled, IP-based path, at least a couple of years ago, the odds of it being very far along in its shift to the cloud are considerably long. Beware of makers of cloud-enabled applications that are now jumping on the Cloud-Native bandwagon.

Whether you’ve already started down the path of shifting your operations to a software-centric model or you are early in the planning stages, knowing the differences between cloud-native and cloud-enabled is fundamental to the future of your business. 

For more information about cloud-native services and the virtues of virtualization, read this excellent blog from Microsoft, an Imagine Communications partner and leading cloud services provider.