DevNation Live Blog: DevOps moves to production

Following on an incredible Keynote demonstration today showing the power of DevOps and Open Source (see the Summit YouTube page), Lori MacVittie of F5 Networks gave her talk on DevOps. More specifically, the session describes the underlying elements of DevOps methodologies and challenges.

Code doesn’t have business value until it is in production

We all know the challenge of getting code in production, late night on Saturday nights only to have the change reverted and told to go try again.

The goal of DevOps is to go from [predefined maintenance] windows to whenever

Unfortunately, there is an incredible amount of hype about DevOps out there, but it doesn’t actually match what organizations implement as “DevOps”. When this model is adopted within a company, it fails to deliver the promised utopia. The biggest problems with rolling your code into production are:

  • Inconsistent Environments
  • No automation in the deployment process
  • Lack of access to production and to teams

But, the problem goes far beyond this into complexity. The Ops side is enormously complex.  The Dev side is similarly complex. Far too many complexities for fully automated build, test and deployment processes.  The stark reality is that the automated tools don’t work well together. More significantly, the approval process is manual by-design and by-fiat.  We, as an industry, need to get past this.

Continuous Delivery systems today still often include one manual step: deployment to production.  Dev and Ops still don’t share common tool sets and common processes.  We need to introduce DevOps to production.  There are four Ops in Ops: Security, Network, Systems and Storage.  DevOps doesn’t tend to include all the Ops.  Network operations have the same issues as DevOps.  Network operations are measured by completely different metrics. They are measured by uptime, SLAs, and performance rather than by change and ease of deployment.  DevOps might get development talking to the sysadmins, but not the rest of the operations groups.

The tools available today for development use is fairly incredible.  However, there just are not similar tools available for this in traditional network environments.  The same network environments that currently run your production workload.  SDNs are cool, but enterprises rarely have built their infrastructure around them.

In order to truly realize the benefits of DevOps, we need to get the other operation teams on board.  This means new tools.  What is needed is a way to automate the network, security checks, storage, etc.

Treat Infrastructure as Code

Almost everything has APIs today, including network devices. Use them. Templates provide an excellent way reduce risk with using APIs and screwing something up.  The templates should be stored off the device and stored in a source control system, giving you that rollback mechanism. The basic models of this:

  • Imperative Model
    • implicit API calls
    • OpenStack, Open Daylight touching the devices directly
  • Declarative Model
    • Template based, policy based
    • Open Stack heat templates
    • Golden images

Finally, we need to find commonalities in tool chains across development and all the ops teams.  Get the network guys comfortable with using Git, use that as your network configuration storage. Look at what the network team uses for monitoring, chances are that it can be used to monitor a lot more things programmatically.  Settle on tools, such as Ansible and Puppet that can work in multi-platform environments.

DevOps requires consistent, predictable and repeatable deployment processes across all the components, not just on the Linux configuration level.  Involve all your operations teams in DevOps, not just developers and systems administrators.

 

 

 

About the Author

Brian J. Atkisson is a Senior Principal Systems Engineer and the technical lead on the Red Hat IT Identity and Access Management team.  He has 18 years of experience as a Systems Administrator and Systems Engineer, focusing on identity management, virtualization, systems integration, and automation solutions. He is a Red Hat Certified Architect and Engineer, in addition to his academic background in Biochemistry, Microbiology and Philosophy.


Join the Red Hat Developer Program (it’s free) and get access to related cheat sheets, books, and product downloads.

Share