The What, Why, and How of DevOps

I learned much about what I know today about systems operations from Bill, a head of network engineering that I hired for my SaaS company about fifteen years ago. We already built separate systems for managing dev and test from production, matured source code controls, and implemented some automation around testing and deployment. What Bill taught me is that we needed to separate developers from production environments because it required a different mindset, tools, and practices in order to keep production environments stable and scalable.

He was right. After removing access, instrumenting some basic change control practices, and improving monitoring of our systems we saw better stability and performance. We also saw better developer productivity largely because they were now more focused on development tasks and less on operations. There was some grumbling about procedures and some finger pointing when things went wrong, but as the CTO I accepted most of it since the teams behaved well most of the time and there was measurable improvements in both Dev and Ops.

Today's DevOps

Flash forward to today, and many of the tools and practices Bill instituted have matured and are core elements of a "DevOps" practice. Since many production environments are now in the cloud or virtual hosts and can grow to thousands and tens of thousands of servers, the operational focus of the practice is on automation. Specifically:

  • Configuration management tools store infrastructure configurations in a database and also help automate setup and integration.  New server, install application, add storage are all operations that can be automated.
  • Code deployment tools integrated with configuration management know what environments exist, provide visuals on applications deployed and enable automated mechanisms to deploy new application version or back out ones if there are issues. 
  • Testing tools make it easier to automate tests and configure them to run during application builds or deployments. 
  • Monitoring systems automate data capture from many disparate systems and provide tools to diagnose root cause of complex performance or stability issues. 

DevOps Culture

DevOps is also about the culture of aligning Dev and Ops teams so that they have a single mindset on improving the customer experiences. For Dev teams, that usually means standardizing platforms, following an agile development process, and participating in Ops practices. For Ops teams, it means instrumenting many of the tools identified above and targeting better stability, improved costs, or better responsiveness.

Maturing agile delivery and DevOps over time, will lead teams to support continuous delivery - the ability to push code out to Production frequently. For companies in highly competitive industries and where technology provides differentiation, the ability to make frequent application deployments can be a differentiator.

What's Not to Like?


All this sounds too good, and it might be for many organizations. First, many organizations will debate tool selection especially when operating in heterogeneous system environments. Are these new tools or replacing existing ones? In many situations, it's a mix of both and the complexity of funding, selecting, and instrumenting new tools will paralyze some organizations before they start.

Second, like agile development these practices are a lot easier to instrument at startups and small companies where the infrastructure can be built from the ground up with these tools, and DevOps practices established from the start. In larger or more established organizations,  it takes investment, time, talent and executive backing to make this happen - something I predict will be a major IT transformation in the next year

Finally, like agile development, DevOps has basic principles but it does not have a manifesto the caliber that agile development has and had from its beginnings. This means that there is significant variance to what DevOps means from one company to the next. The debate on what practices to implement, how they should be implemented, and how to manage the DevOps organizational structure will require a strategy and planning.


Aligning DevOps with Business Goals

Like all IT practices, it's important to start with business goals and measures. Perhaps the organization has to improve stability? Maybe there is significant growth and a need to manage costs and complexity while the business scales? Maybe the business is in a technically competitive industry where continuous delivery is important? Perhaps you are working in a regulated industry where quality and repeatability of the deliverable is required? These drivers should lead to an IT strategy that help develop an operational strategy and prioritize  investments.

Second, management has to be very active when considering the organizational structure and cultural aspects of this transformation. In addition to aligning with goals, changes in these areas should be architected to better align IT with the business, and not just help instrument DevOps practices.


Where to Start?

The very best place to start? I suggest taking measurements of current state before instrumenting too many changes. How stable is the production environment? How frequent are application changes being deployed? How often are applications deployed with significant defects? How often are you scaling systems to meet demand? 

Of these metrics, which ones need the most improvement to match business need? Prioritize 1-2. Now you can start thinking about DevOps.

No comments:

Post a Comment

Comments on this blog are moderated and we do not accept comments that have links to other websites.

Share