Hey IT operations professionals, what do you think? All Hype? What's your CIO thinking? Is she already on board? Has your organization established a DevOps practice? Be it as it may, in most cases developers already have a head start at this using Agile development methodologies for years. It is about time we in operations pay attention.
The more you read about DevOps, the more confusing it may become. But trust me, it is more than just hype. For a few fundamentals, please check out previous posts in this series. "The Three Musketeers of DevOps" and “Do not hire a DevOps Engineer”?
If I had to name four significant changes in IT over the past, say, 10 to 15 years, it would be the change from waterfall to Agile in 2000, the introduction of DevOps around 2010, the constantly growing adoption of cloud computing, and the fact that most company leaders learned that IT – operations in particular – is not some group somewhere in the basement deploying servers and preventing progress. They understood, IT is everywhere and is engrained all aspects of their business. If a business wants to be successful in today's fast paced world of mobile, cloud, and services, they need a nimble IT more than ever.
Many understood. The CIO has a seat in the CxO Monthlies. Her participation in almost all business conversations is essential. Her voice is heard and she provides insight and guidance, helping making better decisions for the business.
This puts a lot of additional pressure on the CIO and her staff. Not that she needs more work. This is where DevOps can come to the rescue. How so, you might ask? CIOs and operations staff across companies of different sizes who empowered teams working the DevOps way see improvements including the following:
DevOps done right can help operations to become more agile and responsive.
For as long as IT exists enterprises foster an environment where developer and operations are conditioned to work towards very different goals. Operations tasked with keeping the lights on while at the same time mostly kept in the dark about the business as a whole. Whereas developers constantly forced to create new value for the business. More and faster vs. stability and predictability. A model that has certainly reached its limits in this day and age.
In new and emerging companies we see very different pattern. Born into fast paced, ever changing markets, and equipped with only little resources, collaboration and communication, and understanding of each other’s work are key. New behavioral pattern more often than not decide over success or failure of a project or the business as a whole.
Enterprise IT started discovering the benefits of leaner teams and closer collaboration. Here is where DevOps comes in. Looking at in it more detail, in enterprises we see at least 4 areas benefitting from DevOps:
Accelerate initial delivery and continuously update production apps by implementing DevOps practices, and as a result add more value to your business.
Optimize resources based on demand and taking advantage of Cloud economics where appropriate, through DevOps practices.
Shorten deployment times and recovery time from errors and help ensure SLAs by being involved early on in the lifecycle through DevOps.
Shorten MTTD & MTTR and help ensure SLAs by being involved early on in the lifecycle through DevOps.
Let’s take a closer look.
Pressure to innovate and to be better, faster, and smarter than the competition is rising in all industries all the time. IT has been identified as a key player at the CxO table helping mitigate the problem. Business decisions demand higher agility from Dev teams. Business requires faster deliveries in shorter time and higher quality. Bug fixes immediately. Operation is faced with an unprecedented pressure to support ever shorter deployment cycles but other than the Devs they are still stuck with the old model. Dev does what it needs to do and Ops has little to no insight what's coming and is only engaged at the last moment for deployment into production.
We all know all too well what happens. Developers (have to) resort to building stuff in the shadows, outside of Ops (Windows Azure, under their desk, etc.), and therefore sometimes outside of quality control, more often without operations integration. Operations is more than ever disconnected from Application Lifecycle Management (ALM), and are not perceived by Dev as adding value beyond basic provider of infrastructure. Shadow IT anyone?
The operations teams in IT are viewed as a barrier instead of a partner and become overwhelmed attempting to reconcile the increased Dev-driven acceleration with traditional practices.
It is not sufficient to enable Devs team to become more agile if the rest of IT stays behind. Ops must be involved as early as possible in the lifecycle. In that sense, an app is not like a child that, hopefully, once old enough leaves the house and cares for itself. An app is a lifetime commitment for the Devs as much as for the Ops teams. And an app has more than just two parents. You need Devs to build it, Ops team to secure, network, deploy, and monitor it.
The DevOps movement is all about helping to accelerate the delivery.
Plenty of work is still run in one-off mode. Only few critical tasks are automated to the extent required to support agility demanded by the business. Lengthy hardware purchasing processes due to budget and datacenter resource restrictions lead to more delays in deployments of new products or features. This situation forces development teams to reach for other solutions like off-premise, public cloud resources. Integration with existing on premise services becomes more and more difficult. Security risks of unknown proportions can arise. Different development teams not talking to each other leads to more waste and not more efficiency. Creation of infrastructure in the cloud can create an unpredictable cost model for the business. Teardown anyone? Money is wasted. Forecasting of resources becomes a nightmare.
In a DevOps model operations and developers would work hand-in-hand with other teams like security and networking. Resources could be allocated appropriately. There will be no surprises when it comes to deployments. Developers will learn from operations how to take advantage of monitoring infrastructure and operations will know about resource requirement before actual in-production deployment. Operations can help to not only automate the deployment of the infrastructure, but automate the deprovisioning of the infrastructure as well and save costs.
DevOps can help to optimize resource planning, allocation, and usage.
Whose fault is it? Problems arising in production or earlier are – in many cases – the problem of operation. They were the last to touch the code. They did not deploy according to specifications (if provided by developers). Troubleshooting becomes an issue due to teams resorting to the age old finger pointing exercise. Longer than expected outages lead to negative business impact due to lack of communications between groups. Lost business is imminent. Even worse for operations – if anything can be worse – is the damaging effect this has on operations teams’ credibility.
Early involvement of operations in the application life cycle will help mitigate situations like these. Joint planning and implementation of application monitoring supported through guidance from operations will help addressing upcoming issues earlier or prevents their occurrence. Operations providing test environments as close as possible to “real world” data will allow dev/test and Q&A to identify issues before production deployments. Predicable deployment in dev/test and production supported by automation and proper tooling, including self-service infrastructure, fosters developer independence without operations losing control or being in the way.
Best of all, once you have a predictable infrastructure and the provisioning is automated, operations can provide a “repeatable offering”. The IT operations team can now setup and configure (and tweak if necessary) and is able to support features like automatic scaling for testing and in production.
The DevOps movement can help improve overall availability.
It is an age old problem, operations is holding the bag for issues that could be avoided if they would have been involved earlier during the application lifecycle. A strict separation between development and production deployment supports lack of accountability in development teams. It is the operations people carrying pagers and being called in when apps fail, not the developers.
Lack of early involvement in the product development process and misaligned priorities between developers and operations lead to sometimes unpredictable results in application deployment and management. As a result poorly written or tested code is – due to missing knowledge transfer – poorly deployed and customers more often are the first to detect issues in production. Again, loss of customer trust and loss of revenue are the result.
In DevOps the fundamental difference is the shared accountability across the whole team. Or as Werner Vogels, CTO of Amazon, points out in an interview with acm: “You build it, you run it.” Using this approach, people are no longer abstracted from their responsibilities. Developers will directly face the consequences of writing bad code. Operations not providing appropriate infrastructure for dev and test will fail their team in making the necessary progress to deliver in time. Deployment into production will no longer be a surprise as operations will know firsthand about application requirements as they have been providing the test infrastructure and automation environment long before the app goes into production. Application problems will be discovered during the application lifecycle since test environments closely resemble production situations. Furthermore, the Operations team may have products or tools which help to even identify code-level problems and by enabling these tools prior to deployment to production can significantly enhance code quality. Think Application Performance Monitoring with System Center Operation Manager and more.
Increased application quality can be achieved using a DevOps approach.
Working in operations, DevOps can support your desire to innovate rather than focus on just keeping the lights on. This can be your opportunity to champion a different way to achieving better results for the business. A co-worker of mine draw this analogy. “Starting with DevOps, this must be like when virtualization became all the rage and operations was spearheading this effort to the benefit of the business. We in operations mastered this quite well.”
Today virtualization is common place and operations transformed the business. Cloud computing is another territory to further discover. The beauty is, cloud computing with Microsoft Azure and DevOps go hand in hand and “the cloud” supports a DevOps model extremely well. And with products like Visual Studio, Visual Studio Online, System Center, AppInsights, and other managing and monitoring services in Microsoft Azure you find perfect companions for Devs and Ops to incubate DevOps in your organization.
Many companies provide Open Source based tools and products that closely integrate with Microsoft Azure and other cloud providers. Microsoft Azure rapidly evolves and supports more and more DevOps scenarios. Industry support will only become better.
This is the time for operations to get involved. This is the time to provide additional guidance to your business and to advance your career.
As always, a list of useful resources for your consideration.
As a bonus if you read this post before May 7th, 2014, we have a great MVA Jumpstart coming where my team will address the challenges described in this post in more detail. If you have time on May 7th, between 9:00am and 2:00pm PDT, join us for a great live online event and a chance to ask your questions.
DevOps focused sessions (excuse the output format)