Navigating a Cloud Native dream, while Operating within a Hybrid Cloud Reality
Virtualized infrastructure has opened up how we think of the cloud, develop artifacts for the cloud, and how we actually use the cloud. This freedoms can lead to confusion, and one such confusion lies within the desire to be Cloud Native versus the reality of operating more of a Hybrid Cloud model.
As many organizations believe that simply running workloads “in the cloud” makes their organization Cloud Native… Maybe it is more than that, maybe the perspective of looking at the End-to-End solution is needed to bring some clarity to this.
First let’s review some base concepts then explore “Cloud Native” and “Hybrid Cloud” models, as misunderstanding these concepts can lead to confusion:
What is Cloud Computing, Cloud Native, and Hybrid Cloud?
Many organizations believe that running workloads within “the cloud” makes their organization Cloud Native. Maybe not… As this foundational misunderstanding is a driving force of the confusion, let’s lay out the some key definitions so everyone is on the same page.
Cloud Computing
According to Microsoft, Cloud computing is when you access computing services — like servers, storage, networking, software — over the internet (“the cloud”) from a provider like Azure.
Cloud Native
According to IBM, Cloud native refers less to where an application resides and more to how it is built and deployed.
Hybrid Cloud
According to AWS, Enterprise environments are often a mix of cloud, on-premises data centers, and edge locations. Hybrid cloud architectures help organizations integrate their on-premises and cloud operations to support a broad spectrum of use cases…
Fantasy versus Reality
I’ve found recently that many think they are Cloud Native, when in reality they actually follow a Hybrid Cloud model. If we look at the definition provided by AWS, a Hybrid Cloud model includes both on-premises, or on-prem, data centers usually integrated with cloud workloads. If we follow this line of thinking, let’s deep dive into two examples:
The Relationship of Data Centers and “local” Hardware
The computers that development teams are typically utilizing to develop code have much more in common with an on-prem data center than they do not…
Don’t believe me? While the scale and size of the hardware differ, let’s take a look at some of the aspects where they closely align.
The resources that these development “local” machines and data centers have in common include compute resources, storage resources, networking resources, and power management resources.
Based on the above, I would argue that the “local” hardware on which development is typically completed on can actually be considered a mini data-center.
The Integrated Development Environment ( or IDE )
The IDE utilized to create, compile, and test artifacts created typically resides one of two places. Within a Hybrid Cloud model the IDE would reside on the “local” machine, while within Cloud Native model the IDE would be hosted within the same cloud hosting provider you are deploying to and running production workloads in.
While the providers of this integral component try to help mitigate the impact of hardware loss, damage, and / or corruption of data. Should hardware in a Hybrid Cloud model fail, all required dependancies must be installed again before productivity can resume.
This is a great example of a single point of failure within the Hybrid Cloud model, and this risk is typically accepted by the business before this model is chosen.
Alternatively, with a Cloud Native model, the IDE resides within the cloud environment you are deploying and running production workloads in (AWS offers a product called Cloud9). This approach allows the most flexibility for an organization, as the heavy lifting is done within the cloud environment, shifting requirements from a specific hardware specification to a browser and Internet connectivity.
This is a great example of how Cloud Native can shift the failure risk from individual hardware to the organizational IT infrastructure, and this risk is typically accepted by the business before this model is chosen.
Pipelines
Within both Cloud Native and Hybrid Cloud, the CI/CD pipelines are utilized the same way. The only difference between them is where the code originates from before it is pushed into a given repository, or repo. Granted a pipeline can be run within a datacenter, but the assumption for this example is that the production workloads are cloud based.
For Cloud Native, the code is pushed to / from the cloud environment that hosts your repo and the cloud environment that hosts your production workloads
For Hybrid Cloud, the code is pushed from the “local” data-center the code was developed on to the cloud environment that hosts your repo (including the cloud environment that will host your production workloads)
Quick Tests to Identify the Model
I’ve found a few test questions to quickly determine if you are actually in a Cloud Native or Hybrid Cloud model, here are a few of them:
- Can you replace the development machine with an equivalent machine with a clean OS install and incur ZERO impact to development productivity?
- Can you replace the development machine with a thin client (NetBook, ChromeBook, etc) with a clean OS install and incur ZERO impact to development productivity?
- Do you require Internet connectivity to continue development work (excluding pushing code to a repo)?
- Can you move to any computer, with any operating system, and continue development work where you left off, without major productivity impacts?
If your answer to any of the the above questions is no, then you are working within a Hybrid Cloud model.
If your answer to any of the the above questions is yes, then you are working within a Cloud Native model.
Final Thoughts
The reality of the current market trend to push for an adoption of a cloud native model is much the same as the market push towards synergy adoption in the 1990s. While these are great buzzwords that get executives excited to transform their organizations… it also hurts our industry by confusing those who don’t fully understand the difference between developing “in the cloud” and running applications “in the cloud”. I hope this article helped to both understand there is a difference, and provide a way to quickly test if you are operating within a true Cloud Native or Hybrid Cloud model.
