published on 13 July 2017

The move to the cloud is the most important sea change we have experienced in the technology world since the web revolutionized how businesses interact with their customers. The benefits most often associated with cloud computing are around agility (the ability to create virtual resources in minutes) and capital efficiency (the ability to stand up infrastructure with no up-front capital costs).

While agility and capital efficiency are critical drivers, the most important shift we are seeing is that customers expect vendors will take over an increasing amount of the operational burden of running software on behalf of those customers. This is most obvious in software-as-a-service (SaaS), with well-known examples like Salesforce, or Microsoft's Office 365. But we are seeing the same phenomenon in infrastructure-as-a-service (IaaS) — for example, Microsoft's Azure and Amazon's AWS offering automated patch management — and platform-as-a-service (PaaS), where we see AWS RDS and Azure SQL Databases offering automated database backup services.

So what does all of this have to do with DevOps? Everything. As organizations move to the cloud, they are revisiting their core assumptions about how they deliver software. Cloud platforms offer APIs for provisioning and management of resources, making it far easier to automate the application delivery process.

Organizations that move to the cloud without taking advantage of this automation opportunity are missing the essential point: The cloud represents a once-in-a-generation opportunity to increase agility, increase safety, squeeze out manual costs, and shift as much of the operational burden as possible to the vendor. These are all core parts of the DevOps philosophy, and are all made easier because cloud platforms are built for automation.

There are a few core decisions to make in your journey to the cloud. The first involves looking at the tradeoffs between taking as much advantage of a vendor’s platform as possible, versus the risk of vendor lock-in. We find that most organizations either commit to a single cloud provider and make deep use of all their APIs, or adopt abstractions that allow them to take advantage of automation, without becoming tied to a single cloud vendor.

The second decision involves whether you choose to modernize your on-premises estate alongside your cloud investment, or keep these estates (and your investments in them) completely separate. Increasingly, we find that many organizations want to adopt a hybrid approach, choosing to invest in symmetric platforms that can run either on-premises or in a public cloud. This hybrid approach gives an organization maximum flexibility to deploy workloads where it makes most sense for the business. There is no one-size-fits-all approach; these decisions must be made in relation to your own priorities, need for agility, and tolerance for risk.

At Puppet, we are seeing an increasing number of our customers use our tools to model their workloads so that they can safely migrate them to cloud platforms — public clouds such as AWS or Azure, or private clouds such as Nutanix or VMware. Whatever the final destination, your first step is to model these workloads so you can deploy and manage them in whichever environment best meets your business requirements, and do it in an automated, safe, and predictable manner.

As a final thought, migration of workloads to the cloud is one of the primary drivers for our efforts around discovery. The first step in modeling workloads is discovering the resources they rely on. We envision a world where our software is increasingly capable of identifying all the artifacts that constitute a workload — essentially, automating the creation of a model for that application. That's how we're going to help make it easier for you to move your workloads to the cloud of your choice.

Omri Gazitt is the chief product officer at Puppet.

Learn more

Share via:
Posted in:

Add new comment

The content of this field is kept private and will not be shown publicly.

Restricted HTML

  • Allowed HTML tags: <a href hreflang> <em> <strong> <cite> <blockquote cite> <code> <ul type> <ol start type> <li> <dl> <dt> <dd> <h2 id> <h3 id> <h4 id> <h5 id> <h6 id>
  • Lines and paragraphs break automatically.
  • Web page addresses and email addresses turn into links automatically.