Perspective on multi-cloud (part 2 of 3) — On premises plus/vs public cloud
This is the second in my series on multi-cloud. For this post I am going to dig into the characteristics of on-premises deployments vs public cloud deployments. You can find Part 1 here.
Observation 1: ‘Cloud’ means many things to many people. Some of those are only really available in the public cloud today.
Let’s tease the public cloud value proposition apart into its pieces:
Don’t underestimate the economies of scale and the resulting purchasing power that cloud providers enjoy. The most simplistic view of cloud is as outsourcing your infrastructure management problem. Why not let the experts with buying power and scale deliver your basic infrastructure as a service?
The truth is that while cloud is making good progress in terms of cost effectiveness, the economics are still developing. For sophisticated users with relatively predictable workloads there are still cost advantages to running your own infrastructure. However, this will likely change.
Friendly piece of advice 1: You may be able to achieve transient improvements in efficiency vs the public cloud today, but it will become increasingly difficult to maintain those advantages as the cloud providers continue to grow and compete.
Instead of filing a ticket, you call an API or use a self-service console. Public cloud is also great for driving infrastructure agility. Amazon EC2 is short for ‘Elastic Cloud Compute’ for a reason. You can right size your infrastructure footprint to your workload in real time. The bigger thing to think about here is that cloud delivers infrastructure available on demand with an almost instant turn around time. The impact on organizational agility can often more than offset the incremental cost. Many organizations worry that this represents a loss of control and oversight (and there is some truth to that), but the cloud providers will continue to bolster their governance offerings, policy driven provisioning and auditing practices.
Finally, what about managed services? Clouds provide access a broad set of expertly managed services delivered through a provisioning API. Some of these can be hard to replicate without expert support. You probably can’t afford to buy atomic clocks for your data centers and without them you are simply not going to be able to build something like Google Spanner.
Friendly piece of advice 2: It isn’t truly a private ‘cloud’ if (1) your developers can’t provision infrastructure on demand, (2) your developers can’t provision a robust and useful set of standard services on demand.
Observation 2: There are good reasons to continue to think about running a private cloud , but security probably isn’t one of them.
For many, security is a primary driver for private infrastructure. However, the hard truth is that you will not be able to match the security posture of the major cloud providers. I can say this having had experience with the excellent security folks inside Google. Unless you are working for one of the wealthiest and most paranoid companies you simply will not be able to staff a security organization that comes close to the caliber, talent, or attentiveness of these teams. This isn’t to say that there aren’t great security teams out there in the wild, it is just a complex, multi-dimensional field. The depth of these security teams is another example of economies of scale benefiting the the major public clouds. They can average out the cost of a huge, world class security team over lots of customers.
Regulation may still be a reason for private infrastructure. While I believe eventually regulation will follow the pragmatic realities of economics, it is a slow moving space and will take a long time. For the immediate future, some highly regulated workloads are going to have to remain in private data centers. This may justifies a phased approach to public cloud adoption. Use public build new, unregulated systems. Or start by moving simpler elements over time.
Highly connected devices are driving demand for edge based computing. With many more, and more highly connected devices it becomes a question of balancing the cost of connectivity vs the availability of edge resources. As IoT scenarios become mainstream, we can expect to see a lot more compute showing up at the edge. It behoves organizations to have a strategy to deploy and manage applications there. Some of this compute may be on your premises, some will be in carrier managed facilities, and no doubt the cloud providers themselves will get in the game.
The final and perhaps most obvious point in favor of a hybrid strategy is that your current data centers aren’t just going to go away. An ideal solution would allow developers to use the same set of tools, practices and workflows to operate in both worlds. Perhaps leveraging the public cloud for testing, then deploying your production workload to the current environment.
We really haven’t seen offerings that bring together the world of on-premises deployment topologies at the IaaS level. The AWS/VMware partnership looks interesting, but it isn’t clear to me how that will work in the long run. It feels like there is a decent amount of overlap between what each providers that needs to be worked out. Even if it ends up making sense, it doesn’t bring all the attributes of cloud back to your local datacenter per my earlier point; you don’t get cloud like services on your infrastructure. OpenStack, while promising for on-premises use, really doesn’t have a public cloud analog.
Friendly piece of advice 3: Think about technologies like Kubernetes, Cloud Foundry, or Mesosphere’s DCOS. These were developed from the ground up as a way to decouple workloads from the underlying infrastructure and are a start to a true hybrid offering. The story should include not just basic infrastructure primitives, but a set of services that someone (you, or a provider) can provide to your team that are provisioned by API (vs ticket). Obviously, at Heptio, we believe that Kubernetes does this particularly well.
Observation 3: The biggest challenge for hybrid may be developer and operator skills.
In many cases it makes sense to look at public cloud as a supplemental source of compute and for new workloads. For many companies, cloud starts with dev and test before deploying on private hardware. Unfortunately this is not as simple as preparing a bootable image that runs in different environments.
The operating system itself naturally lends some level of consistency from environment to environment, and we are seeing ‘vm image bakeries’ emerge as a way to address this problem. CI/CD systems can now produce a bootable image that will run in multiple environments. The harder nut to crack is how to connect the parts of an application together. The code itself must have some way to connect to and consume services that it depends on.
Unless you live in a perfectly monolithic world there is value in thinking about environment agnostic ways to tie the pieces of complex systems together. Each new environment today includes not only new operations tools that force your operators to learn new schools, but introduces eccentricities that are difficult to account for in the application architecture.
Friendly piece of advice 4: Look at an abstraction layer as a way to become ‘cloud ready’ even if you aren’t ready to move all your applications to the cloud today. Micro-service friendly frameworks like Kubernetes help to ensure portability of both applications and skills. For the best results look beyond a simple portable image to a broader definition of application. That grants you an option on moving a workload later if needed. The platform should include the ability to find and bind to services easily. It should also support the decoupling of application pieces so that they may be moved over time.
I hope you found this perspective useful. Obviously, it is a complex space and there are a tremendous number of moving parts.
For the next post in this series I will dig into questions about availability, failure zones, federation and the complexity of operating services across multiple clouds and locations. It will be a little more technical than the series thus far.
