Organizations are reevaluating cloud strategies when the cost savings promised by the public cloud fail to materialize — or worse, when the cost of their public cloud services rises much higher than anticipated. Often this happens because leaders blindly deploy or move data to a public cloud without first understanding the data’s true value to their business. Such lack of planning creates distributed copies of data – fueling data sprawl, impeding data control and making security and compliance more burdensome and complex. In these situations, organizations inevitably look for services that can optimize their cloud spending and save money, while still delivering the agility and scale that’s necessary to achieve business results. This starts with transparency of current Cloud SLAs and consideration of downtime, flexibility and performance. With workloads increasingly earmarked for deployment on private, public and/or hybrid clouds, organizational leaders face enormous pressure to get their cloud strategy right and manage distributed workloads effectively. A dependable, always-on cloud infrastructure that scales to meet changing capacity needs is vital to this effort. But what’s increasingly clear is that IT needs a better way to manage cloud infrastructure, and that today’s CloudOps must involve more than infrastructure, operations and support. Just as self-driving cars proactively detect traffic congestion and reroute without human intervention, we need workloads that self-adjust, with architectures that are practically invisible and touchless. These are the key features of efficient CloudOps and represent a promising new approach for enterprises stuck in an environment of rising public cloud costs and complexity.
Most cloud strategies are optimized for one of two outcomes: (1) cost savings or (2) increasing the pace of innovation. If you aren’t seeing cost savings from your lift and shift initiatives, it might be time to check your assumptions on how much work is required to move your company’s workloads into a cloud environment. It’s very possible the effort required was underestimated and the fundamental ROI calculation was overly optimistic. If you aren’t seeing a faster pace of innovation from product teams using cloud, it’s often a sign that you have fundamental problems in your product and engineering Organization that are only being exacerbated by a move to cloud. You might need to train your team on more modern approaches including agile software development lifecycle and cloud-native technologies and best practices.
While it may seem counterintuitive, when you truly understand your cloud workload, what it demands, how it behaves — it is likely time to change your strategy as to where it runs. It is important to remember that the cloud is an operating model, more so than a place. Your cloud strategy is a function of that operating model and, as you mature, you will change how, and where, you run certain workloads. The public cloud (place intentional) was built on simplicity, elasticity and microservices. It, more so than anything else, taught us the cloud operating model. You go to the cloud to develop the cloud-native mentality — rapidly assembling infrastructure, applications and workflows in the service of a business problem. You go to the public cloud to understand scale. In the public cloud, simple scales, failure domains are kept small and building blocks represent the way things are built. You go to the public cloud to internalize the importance of simplicity. Simple wins in the cloud. When you have understood these things, you will also understand your workload, its behavior and its requirements. At that point, you alter your strategy and optimize for economics. That often means repatriating that data to the private cloud or changing public cloud providers (and treating them as commodity infrastructure). You still use the cloud operating model — you just alter the strategy and optimization variable.
