Virtualization Technology News and Information
Article
RSS
Three Definitions of Cloud and Why You Need to Know the Difference

Article Written by Edward Hsu, VP Product Marketing, Mesosphere

 

We all hear about the importance of cloud computing.  With "cloud" already an overloaded term, "cloud-native" is the latest addition to the mix. And what "cloud-native" means can vary greatly depending on who you ask. What are the actual decision points available to you in your IT strategy, and how does "cloud-native" compare with other "cloud" decisions? And where does the Cloud Native Computing Foundation fit in?

The Three Definitions of Cloud

There are three top-level definitions of cloud, and your decisions along each of these definitions affect your organization, from staffing and talent, to operating processes, to the technology you use. In fact, there's a unique hype cycle for these distinct definitions, each in very different phases of maturity.

The three definitions are:

  • Cloud as a Sourcing Model
  • Cloud as an Operating Model
  • Cloud as an Architecture (as in Cloud-native)

Why do these definitions matter?  Because while one decision along these definitions may influence others, each are in fact distinct concepts that can be managed separately. Anyone who tells you otherwise probably has a business model that's driven by combining two of these definitions, or a partial definition. In order for you to develop a well-informed cloud strategy, you need to accurately see the entire cloud picture. 

Recognizing the right combination for your business is critical to making sure you don't end up down an unintended (and difficult to reverse) path. Looking at the history along each of these definitions provides some guidance as to what we can expect in the future.

Cloud as a Sourcing Model

Who runs it?  

By the 1990s companies recognized that they needed to outsource functions for which they had little to no competency internally, or had no means perform cost effectively. Recognizing this trend, IBM transformed itself to a services business, and by the late 1990s IBM's revenue from services had exceeded that from mainframes and servers.

Variants of this phenomenon included offshoring, where the driver was primarily around lower staffing costs. At the turn of the century, offshoring to countries like India was all the rage, as businesses sought to reduce costs for what they then identified as non-core processes. Examples included customer support, contact center, and later, software development. India-based companies like Wipro and Tata Consulting Services (TCS) were core to these efforts. Between 2000 and 2010, both Wipro and TCS quintupled their revenues.

However, aggressive outsourcing and offshoring eventually led to challenges of its own, driven by three factors. First, the success of offshoring led to greater local demand for technical English-speaking staff, which drove up labor costs and sometimes turnover. Second, language gaps, coordination costs, and quality of output were sometimes not as expected. Third, companies began to re-think their decisions on the strategic nature of outsourced business processes. These three factors changed the equation for offshoring and led to a re-examination of sourcing strategies.

Nearshoring often came next, where companies looked for staff in nearby countries that can speak the same language and operate in the same time zone, with the aim of improving service quality. The approach often meant looking at MSA's (metropolitan statistical areas) as a target for outsourcing. If the ultimate target was back in the same country, we called this "onshoring." For many businesses in the USA, this meant expansion of datacenters or service centers in non-coastal states for the right balance of talent and costs. Given the proximity of the resources, companies often decided to insource these centers.

Today, even as the debate continues on the benefits and limitations of IT outsourcing, the most likely answer is that both will co-exist in foreseeable future.

Cloud as an Operating Model

How is it used?

Cloud as an operating model essentially means "on-demand", or more broadly "as-a-Service", when we include the ongoing lifecycle maintenance of these services. In enterprise IT, the opposite is probably "project based interaction."

Corporate IT organizations have long faced the challenge of deciding whether to provide their business partners what they want vs. what they need. For example, a business owner may expect their ambitious project to explode and demand a large amount of high-end compute, storage, and networking capacity from IT, only to end up not using much of the capacity. In some cases, the request will demand specific server models & configurations. Because IT services can take months to provision in some companies, users overestimate their needs, exacerbating the problem. Dedicated resources get allocated, but never used, driving up costs.

In high-performing IT organizations, interactions with the business are more balanced - business owners describe their needs around performance and availability, and the rest of the decision is left to IT. IT defines the services catalog, which can include low level infrastructure services (like a server) to higher level services like databases. They also build and operate the bill of materials and track their costs so they can ultimately showback or chargeback to the business.

Cloud as an operating model was enabled by virtualization technologies. Why? Because prior to virtualization any request for IT services required something physical to occur, and someone from IT to step away from their desk - whether it was a server showing up at the loading dock, plugging in a server, or installing software (and we didn't have robots yet to do this for us).

We have Amazon to thank for making the cloud operating model mainstream with EC2 (virtual machines as-a-Service) and S3 (storage as-a-Service). Because of this, people initially thought "cloud" could only mean outsourced IT, but VMware championed that "cloud" could be defined as an operating model that is agnostic to whether it's insourced or outsourced, and delivered software to enable this. In 2009 Gartner's Tom Bittman proclaimed "private cloud is real, get over it." Private cloud refers to insourced, public cloud is outsourced. 

By 2010, virtual workloads exceeded physical workloads worldwide, most of it insourced. Eventually other technologies like Microsoft Hyper-V and Openstack caught on. In 2018, VMware had the largest market capitalization in its history, which shows the continued momentum for this operating model that champions hybrid strategies combining private and public clouds.

Today, while the enabling tech stack may vary, business technology leaders generally agree that providing IT "as-a-Service" (with guard rails) is the most effective way to help their businesses be successful while managing the complexity and cost of IT.

Cloud as an Architecture

What is it made of?

What we call cloud-native today are essentially the architectural patterns developed at webscale companies like Airbnb, Twitter, Google, and Facebook in their hyperscale datacenters in the late 2000s. These patterns are in stark contrast to earlier monolithic architectures. Dealing with the explosion of serving billions of users in real time, these internet giants sought to improve performance and lower cost.

To do this, two things had to happen on the infrastructure level. First, replacing expensive monolithic servers with lower-cost commodity servers (but in much greater numbers). Second, using sophisticated software to create massively distributed computing infrastructures. Early iterations of this approach used VMs, eventually giving way to containers as the unit of deployment. The container movement started with Linux cgroups, which are the foundation for the popular Docker file format that's used today.

On the application level, cloud-native architectures share three key characteristics. First, they are distributed systems, and therefore assume that an underlying compute cluster is available because a single machine would be insufficient.

Second, functionality is delivered as a set of containerized microservices that don't store any data internally (stateless), so they can be deployed, scaled, and killed at will. The microservices are the application code that businesses create in-house. An example of this might be a shopping cart service that exists as part of a larger e-commerce suite. These microservices are packaged in containers and launched by container orchestrators, the most popular being Kubernetes.

Third, is the data service, which is the backbone of the cloud-native application. Popular technologies in this area include tools for ingesting the data (e.g., Apache Kafka as part of an IoT application), storing the data (e.g., Cassandra, HDFS), and analyzing the data (e.g., Apache Spark). No useful business software is ever entirely stateless, so these data services play a key role.

Another key factor of cloud-native application architectures is open source software. Kubernetes was built from the ground up as a new project led by Google. Cassandra was used internally at Facebook before being open sourced. Same was true with Kafka at LinkedIn. Spark was first conceived on Apache Mesos, an open-sourced distributed systems kernel technology to stitch together datacenter resources and automate workload operations. Today, all of these technologies run elastically together on Mesos enabled by DC/OS, another open source project by Mesosphere.

With open source, cloud-native application architectures that were initially developed to solve large-scale challenges are now getting adoption at mainstream enterprises. Reasons include lower operational costs with increased workload density, faster time to ship out new functionality, and performance and scale to power data-driven applications.

Cloud-native architectures power today's cutting edge use cases like predictive analytics, IoT, and personalization. The power of cloud native architecture also comes with complexity, however. An ecosystem of yet more tools have evolved to help businesses manage the complexity. The Cloud Native Computing Foundation (CNCF) organization was founded to help businesses navigate this fast changing landscape.

Real-world Examples

With the definitions of "cloud" disambiguated, let's look at some real-world examples using the framework above:

  • Sourcing model: insource vs outsource
  • Operating model: "as-a-Service" vs project-based
  • Architecture: cloud-native vs monolithic

Let's start with the basics in the world of monolithic architectures.  These examples are also known as Infrastructure as-a-Service or IaaS:

VMware vSphere & Cloud Foundation is a software that enables insourced, as-a-Service operations for monolithic applications. VMware has other projects like Photon and Lightwave that aim to tackle pieces of cloud-native architectures.

Rackspace provides an outsourced as-a-Service experience for monolithic architectures using software it purchases from VMware and other vendors.

Amazon Elastic Compute Cloud (EC2), provides an outsourced, as-a-Service experience for monolithic applications. The software they use is proprietary, based on the Xen hypervisor.  Amazon also offers VMware as a hypervisor.

Getting to cloud-native architecture as-a-Service adds a bit more complexity, since it also requires automation of container orchestrators like Kubernetes to run stateless microservices, as well as data services like Kafka, Spark, and Cassandra. Enterprises piecing together cloud-native technologies on their own on top of IaaS, are essentially insourcing project-based operations to build cloud-native architectures.

To address the complexity of cloud-native architectures, vendors have developed various means to help companies get to the finish line.

Amazon Web Services (AWS), provides an outsourced, as-a-Service experience for cloud-native architectures covering both the application and backing data services. In AWS's case, the cloud-native data services are typically proprietary to the cloud provider.

PaaS, like Pivotal Cloud Foundry, is software that enables an insourced, as-a-Service experience for cloud-native technologies covering the application component. Data services are typically beyond the scope of PaaS deployments. Pivotal places great emphasis on change management of software development practices.

Mesosphere DC/OS, is software that enables insourced, as-a-Service experience for cloud-native architectures covering both application and backing data services. In Mesosphere's case, cloud-native application services (like Kubernetes) and data services (like Spark, Cassandra, Kafka) are typically open source. Commercially supported offerings (like Lightbend Fast Data Platform, Datastax Enterprise, Confluent Platform) are also available.

As software, both Pivotal and Mesosphere DC/OS can be deployed on premises or on top of an outsourced IaaS like Amazon EC2.

Getting it Right for Your Business

There's no answer that's right for all businesses, since each optimize for different things. But there are five factors to consider.

The first is cost. Rackspace, generally known for outsourced, as-a-Service traditional architectures (or IaaS) has a profit margin of around 6%. AWS, providing outsourced, as-a-Service cloud-native architecture, has a profit margin around 24%. There's value in automating away complexity, and it's illustrated in the profit margin. For some businesses, the cost is well worth it. For others that are running data-driven applications at scale, the costs of an all-in cloud approach can be prohibitive.

The second factor is business risk. If you're a bank, healthcare provider, or major retailer like Walmart, using a cloud provider that might become a competitor is a real risk. One approach is to leverage outsourced IaaS (now a mature space where the software used can be agnostic to the outsourcing vendor) and then running additional software on top for insourced as-a-Service automation for cloud native architectures. This way, if your outsourcing provider decides to enter your space to compete with you, you have the option to go to a different provider, and not be forced to fund your own demise.

The third major factor is service risk.  While cloud provider outages are rare, they do occur. Snap for example, made early cloud-native architecture decisions that led to business risk they captured in their S1 filing, mentioning that any significant interference or disruption of their use of their cloud provider "would negatively impact our operations and our business would be seriously harmed."  During a four-hour outage of a major cloud provider in early 2017, companies were estimated to lose over $150 million.  Vendors that fared well during this outage took advantage of multi-cloud operations. Apple, for example, is known to use both AWS and Google cloud.

Fourth is architectural control and technical differentiation.  There's been an explosion of technologies in and around the cloud native ecosystem landscape. Additionally, outsourcers like AWS offer interesting services unique to their cloud (e.g., AWS Lambda), and so does Google (e.g., Google Cloud ML).  However, using only one outsourcer for as-a-Service cloud-native technologies means your technical capabilities are constrained to their portfolio. If optionality to use specific cloud-native technologies is important to your business, look to run cloud-native technologies as-a-Service through software, as opposed to outsourcing.

The last factor to consider is data locality.  The concept of data gravity is well known in the industry.  If your data is sitting at a specific cloud or datacenter, services you build will often need to be close to the data.  But if you're in the business of geospatial analytics, operating cruise ships, or industrial IoT, application services can't run entirely in a datacenter far away. An emerging pattern today is rolling out global services with data locality, driven by data sovereignty compliance, performance, data transfer, or latency considerations. 

Most enterprises are evolving towards building and running data-driven applications across hybrid cloud infrastructures. Getting it right for your business means making decisions around sourcing, operations, and architecture separately, and finding the right balance that yields the best results for both IT and the business as a whole.

##

About the Author

 

Edward Hsu is responsible for product strategy and product marketing at Mesosphere.  Edward has a computer science background, and was previously Engineering Lead at Oracle, Engagement Manager at McKinsey, and Sr. Director of Product Marketing at VMware.

For similar topics on Kubernetes, consider attending KubeCon + CloudNativeCon EU, May 2-4, 2018 in Copenhagen, Denmark.

Published Thursday, April 26, 2018 7:36 AM by David Marshall
Comments
There are no comments for this post.
To post a comment, you must be a registered user. Registration is free and easy! Sign up now!
Calendar
<April 2018>
SuMoTuWeThFrSa
25262728293031
1234567
891011121314
15161718192021
22232425262728
293012345