2015 View of DevOps and Cloud
| DevOps |
2015 is unfurling with the same sound and fury that we saw in 2014: cloud adoption continuing to grow, significant initiatives around innovation and speed to deploy are underway across the technology industry, and the DevOps community is still the rock around which the tempest of security and innovation combine.
Over the course of the next three blog posts, we’re going to take a look at the state of DevOps and cloud, focusing in on some of the areas of interest that we hear and see with increasing frequency. We’ll consider where things stand, where they’re headed, and what it means — and what you can do to make this the year that your DevOps projects and programs stay on track.
The State of DevOps
First and foremost, the tools and technologies that describe the typical DevOps team have grown significantly over the last 12 months. In looking across the entire Conjur customer base, and from the people we speak to regularly the community, we are seeing the emergence of a reference architecture for DevOps that is markedly different from what we saw a year ago. Specifically:
- (Almost) everyone is running a hybrid platform;
- Automation (and tools to enforce it) are a given;
- Security is increasingly a DevOps function, in part or whole.
Access Management for Any Cloud
While there was never truly a heyday for single-cloud deployments, the last year has proven that hybrid cloud architecture is here to stay. As far back as April, hybrid cloud was being declared “king” by RightScale, who noted that 98% of respondents are using cloud now, and 58% of those people are doing so with hybrid cloud as the cornerstone of their strategy.
For DevOps teams, this creates a unique challenge: how to authenticate and authorize users, machines, and code across multiple different platforms, rather than relying on a single vendor/platform solution (such as AWS IAM).
Automate, Automate, Automate
The tools used to deploy machines and infrastructure across this new kind of infrastructure are more clearly delineated than they once were. From a treetop perspective, the list breaks into three parts: (1) configuration management, such as Chef, SaltStack, and Puppet, used to create machines and software-defined architecture quickly and consistently, (2) continuous integration technology, such as Hudson, Jenkins, and CruiseControl, and (3) platform abstraction technologies such as Docker, Rocket, and VMWare, often used together to create clean, consistent, and easily deployed dev, test, and production environments.
Of course, this also creates a new threat surface for DevOps – something we will look at in more detail in the coming blogs in this series. Building in security, especially around access and authorization, has been hindered by a lack of innovation in the legacy point solutions that managed this kind of concern in the on-premise world. The tools that worked inside the server closet simply haven’t remained relevant when forced to map to this new, highly-automated, and cloud-native environment.
Nobody Puts Compliance in the Corner
Audit, compliance, and security all need to be rebuilt: get this wrong, and you have a complete fail (see Code Spaces); get it right, and you avoid the kinds of outages that take major companies offline and block cloud initiatives.
From HIPAA to SOX, DevOps architecture, tools, and practices are in scope for audit teams, and ensuring that there is a complete and immutable record of all privilege-related activities is essential. Practices that are easy — putting secrets in source control systems, for example — are not necessarily wise, and one of the functions of a good audit is to ensure that shortcuts don’t put the business or the data it manages at risk.
The good news is that there are easy ways to think through the implications for DevOps. In the second part of this series, we’ll take a deeper look at the cloud landscape, and explore how and why cloud native tools have become the foundation for any DevOps-aligned security and compliance program, and cover the three problems that any team must consider when building for cloud native architecture.