You might say, isn’t that an obvious question for 2016 and almost 2017? I thought it was six months ago when I was immersed in software-defined networking (SDN) and white box switches, but now that I am immersed in cloud here at ZeroStack, I can say it is a great question and many people still have unique perspectives on the answer.

Let’s take a step back and try to build a set of characteristics that defines cloud. We may all agree at the end of this blog!

API-Driven Infrastructure

One aspect of cloud that is different than our historical siloed model is that cloud is API driven. I saw this trend growing even on the network side over the last three years, and from the application side as well. As an example, when Cisco announced their new Application Centric Infrastructure (ACI) SDN strategy around the Insieme spin-in, they went out of their way to talk about all of the APIs available. For networking this was a big deal, and for Cisco it showed they understood where the application teams are taking us.

RESTful APIs like AWS / Azure / OpenStack APIs have become almost the de facto standards and it’s a good thing. Many vendors still promote their own APIs, and of course that not only creates a lock-in for the customer, it also inhibits them from building the ecosystem that best matches their business. Hopefully over time, all vendors will offer open APIs along with their own proprietary APIs. That at least takes us into a true cloud framework.

Pooling of all resources: compute, storage, networking

When you touch an app on your smartphone, magical software just connects you to the resources you need. Similarly, when you ask for resources on a public cloud, you can get them in minutes without going through IT. No one asks for a ticket and no one tells you to wait. Imagine if Dropbox or Amazon Web Services (AWS) asked you to wait three hours! The challenge we have is that many best practices have been built to ensure uptime and isolation (for the right reasons) of assets and resources. Cloud can break that barrier, or a cloud infrastructure can abstract the user from these issues. Either way, cloud should mean you have pooled resources and the app does not have to know anything, and better yet, neither does the user. The admins and architects handle that. And of course, if you are a believer in cloud-managed infrastructure, we would manage those issues for you.

Hyper-converged infrastructure (HCI) is one way to pool and scale infrastructure resources, but there are other ways where the resources are separate and are scaled and managed independently. So although HCI is a powerful trend and many cloud vendors leverage HCI hardware, it is not a requirement to be true cloud. The main goal is to abstract out these individual resources, pool them together and make them available via an API. If you start to run out of a resource, just add more of it to the pool.

A best practice many organizations have taken with cloud is to build a cross-functional team helping to share strategies and understand issues each group has in moving to a cloud framework. This process helps to identify gaps and needs across the organization.

Elastic scaling

Elasticity in my mind is one of the earliest and still important goals or benefits of cloud. Part of the sales pitch on cloud means you can scale or decrease the resources based on usage. This idea of elasticity is a huge business benefit. Many people translate business agility into scaling or elasticity (of course agility means more than that, for example automated provisioning).

There are numerous underlying mechanisms to obtain elasticity. You can either scale within a cloud or scale across them by bursting into a public cloud. First, you need to have pooled resources as noted above, and you need orchestration tools. Now you can scale this infrastructure by simply adding more resources. Second, if you need to burst rapidly, you can deploy or migrate your application to a public cloud. This may require lots of bandwidth if you are bursting an app from one cloud to another.

Fortunately, you can even lease that in most datacenters. Bottom line, cloud vendors should have a means to deliver elasticity without having the user become a cloud expert. All that complexity should be hidden from users. And tying in those open APIs, if you have open APIs, you have the ability to interconnect clouds to optimize the right cloud for the right workload.

Applications are not islands

Building on this idea of elasticity, it’s important to have a choice in which cloud is best suited for that specific workload. Clouds are not created equal and therefore one cloud is not always well suited for what you are trying to do. Latency, IOPS, time, cost, and bandwidth are all considerations. Having an open system that easily helps you migrate workloads to the best platform is no longer a CMP’s function (cloud management platform), I believe your cloud platform should have this as an integrated function.If you are looking for cloud solutions, make sure it can not only provision but also migrate applications from one cloud to another.

Must be Self Service

I left this for last as I think self-service is the most transformative. The idea of self-service comes from public cloud and also consumer services like Dropbox. With AWS you simply open an account and go through the steps and start consuming. This ease of access has set the bar for cloud, and it is why I believe so many developers are working within public clouds – the idea of agility is partly defined by how fast you can set up and start consuming. Traditional ticket-based IT systems and procedures are moving in this direction.

And a lot of vendors claim they support cloud, hoping to stay ahead of this transition and capture mindshare. Frankly my friends, I don’t see how you can say you support cloud today without an easy-to-consume, self-service delivery model – VMware, Nutanix, yes, I mean you!

This time of year brings the holidays and some time to plan for the year ahead. If your organization is shopping for cloud in 2017, feel free to use my checklist.

Leave a Reply