Cloud vs On-premise
When you move to the cloud from your own on-premise data center, it’s instructive to think about that transition as an organizational migration from having complete and full responsibility of your own data center infrastructure, to a model of shared responsibility between you and your cloud vendor. In other words, by simply using the cloud you’re offloading increasingly risky and expensive responsibilities such as data center facility uptime and regulatory compliance, physical gear, and the availability of data platforms that are more business critical by the day. It follows then that with a shared responsibility it’s crucial that you hold up your end of the bargain (note: this requires that you know what your end of the bargain is, of course) which is best accomplished the old fashioned way: through solid policy and governance.
But policy and governance, while accomplishing the same ends as they do on-premise, are still operationalized in a much different way in the cloud. It’s not just that operators need to learn a few new portal options and interfaces to support cloud – most operations teams are already be pretty adept at learning new vendor tools that are more or less adjacent to their current experience. It’s subtler than that in this instance – in the case of cloud it’s a philosophical change, if you will, and it’s one that transcends the single-vendor ecosystems that dominate on-premise data center stacks.
The cloud is built on the foundational concepts like openness, programmability, usage-based variability, and automation. Compared with the more closed and static ecosystems of traditional data center hardware vendors, cloud is now the best way to marry the reality that digital is today’s competitive battleground for businesses with the emerging requirement in the marketplace for more effective privacy and security.
From the perspective of policy and governance, and even regulatory compliance, there are some key differences in how one approaches cloud versus an on-premise environment. In the case of cloud, the capabilities are ultimately more robust and lend themselves to better overall governance and control than you can expect to achieve on-premise. Let’s discuss the key differences between the cloud and on-premise with regard to policy and governance.
End-to-end vs shared responsibility
In the public cloud you actually share responsibility for different parts of the stack with your cloud vendor. Who is responsible for what (in terms of security) depends on the cloud service model you use (IaaS/PaaS/SaaS). With IaaS, the cloud service provider is responsible for the core infrastructure security, which includes storage, networking and compute (at least from the hypervisor and OS agent and below). If you’re in your own facility or maintaining your own gear in a colocation facility, you’re still responsible for all or a significant portion of the technology stack. The shared responsibility of the cloud reduces risks by offloading those responsibilities to the major cloud vendors which spend billions on security and top end technology.
Static perimeter vs open perimeter with ephemeral resources
In the cloud resources like app services or virtual machines are spun up and down based on need and serverless services like Azure Functions or AWS Lambda execute code based on an event trigger with no additional infrastructure necessary, so things are dynamic and always changing. Contrast that with a traditional on-premise data center environment that has a single monolithic network, which stays relatively static (physical location, IP addresses), and relies on complex physical devises at choke points to manage and secure traffic.
Disconnected tools vs built-in cloud services
In the on-premise data center world, people are accustomed to supported complicated tools to do operational tasks like performance monitoring or log monitoring for security. These disparate, disconnected tools often require substantial server and storage resources to run as well as maintenance and upgrades. You also have to make sure you picked the right tool and that it integrates and works with your stack of technology. In the cloud the tools are connected and built right into the fabric. Instead of running and maintaining your own monitoring stack in your data center, for instance, you can now program your alerts into the cloud monitoring service and it just happens. So you can take things like performance, uptime, log, and event monitoring and just use them in the cloud. It’s easy and presents huge savings in time and cost.
Sporadic automation vs DevSecOps automation
Automation in a traditional data center environment is difficult. Often times your hypervisor vendor has some semblance of an automation language, maybe you’re using something like Chef or Puppet to configure hosts, but if you’re on-premise, chances are your automation efforts are sporadic. In the cloud, automation is built in. Those monitoring capabilities discussed? There’s an API. The built in security stuff? There’s an API. Well, what about scheduling automation events? Yeah, that’s all built into the cloud too. The cloud was built to automate. From infrastructure builds, to port rules, to log retention, to backups and site recovery it’s all built into a single, consistent API for you to automate everything.
The success or failure of a cloud strategy depends largely on how well the organization understands and accepts these key differences. Once one understands the cloud model, the next step is to understand the individual cloud platforms and their built-in services for things like monitoring, security, and resource provisioning. In Azure and AWS, for example, these services are API-driven, meaning your tools should integrate with those services and help you automate and operate in a cloud-native way.
OpsCompass helps organizations become more cloud-native in their approach to cloud. Our product, Helm, is a SaaS product that plugs directly into the cloud API and provides continuous policy, governance, and compliance. Choosing a product like Helm helps companies do things like leverage their cloud platform’s built-in security capabilities more effectively, manage configuration drift, and maintain strong regulatory compliance without slowing down innovation.
