I’ve had the honor of sitting in the same room with many customers and prospects who share their business models and technology challenges. In the exact words of one of our customers, “Our cloud deployment is a horrendous process.” From others, “Our developers work in their own private cloud, and they send us the release code and it takes us days to weeks to get it running in production.”
Doesn’t the cloud promise faster, more agile development with reduced costs? Why then isn’t this promise being fulfilled at most companies adopting DevOps and cloud?
Why is it broken?
I keep hearing a recurring theme. Heavy use of open source tools and development and production environments that don’t mirror each other. Developers have their favorite list of tools and operations theirs. Neither group understands how to use and configure the tools the other group is using. Throw in multiple versions of these tools and it quickly becomes an unwieldy mess. Here’s a sample set of technologies and stacks we come across:
We commonly see development teams using these technologies:
- ADD MORE
We commonly see operations teams using these technologies:
- New Relic
- ADD MORE
And we see development, test, QA and production run on these clouds and platforms:
- Amazon AWS
- Google Compute
- Microsoft Azure
- VMware vSphere
- ADD MORE
- Windows 7, 8.1 and soon Windows 10
- Linux, Red Hat, Ubuntu
When you mix in your custom code (you are running a real business after all), the complexity of getting any application into test or production becomes that much more challenging. No one person understands every third-party application, open source tool, or custom code. And standards, when they do exist, are impossible to enforce without a unifying toolset and development process. Given this complexity, it’s completely understandable why developer productivity and the rate of enterprise innovation is slowing while the operational overhead to support the DevOps paradigm is growing.
How to fix it?
A recent article on cloud computing sums up these challenges nicely. “Forty-two percent of IT leaders cite infrastructure complexity as a top challenge to adopting cloud.” Add to that is a fear of change (40 percent), inflexible practices (40 percent), and lack of a clear strategy (35 percent).
These complex challenges and reduced speed of innovation form the backdrop of many of our customer and prospect meetings. The meetings all look very similar. Attendees include lead developers, IT and operations experts, ElasticBox representatives, and the company CIO. These forward-looking companies are serious about speed, agility, and innovation.
But what does that speed look like in these companies? A CIO.com article on DevOps and Cloud explains, “In a DevOps environment, the code is deployed continuously to production for feedback and bug discovery. Release cycles may be daily or even more often.”
Yes, DevOps is the “agile methodology” for operationalizing the development lifecycle, but it doesn’t come without challenges. For example, operational skills aren’t always second nature to developers. Practitioners agree that siloed organizations need to break down walls to get developers and operations personnel joined at the hip.”
ElasticBox’s answer is an integrated solution at the core of which is the construct of the box. Boxes are a collection of reusable infrastructure-as-code components. Boxes contain scripts, variables, and metadata to automate processes for deploying applications to any cloud infrastructure. When stitched together, boxes model complex processes like deploying or upgrading multi-tier enterprise applications.
Puppet Labs in a survey of more than 9,200 software developers last year found that DevOps organizations deploy code 30 times more frequently than practitioners of more traditional development techniques. What’s more, they experienced 50 percent fewer failures. We’re seeing this trend with ElasticBox customers who can increase 30X code commits, spin up environments 10X faster and drastically reduce tickets and latency in getting projects done.
Here’s a typical flow in ElasticBox: The IT and operations teams build out a box catalog that encapsulates their expert knowledge and processes for development tools, IT policies, and target environments. Developers can self-service a group of boxes along with their code to rapidly iterate without having to either open tickets, find “the guy,” or learn to use a number of operational tools. We’re not saying they can’t or shouldn’t. But the key here is the focus. By focusing on their core expertise, developers, are free to work on innovative ideas and new initiatives. Operational freedom and self-service open the doors for developers to innovate at speed — fulfilling the promise most businesses are after.