How to make DevOps work

AWS DevOps team in discussion

DevOps is probably one of IT’s recent great ideas that doesn’t always work in practice a lot of the time. In reality, even the term DevOps means different things to different people, and that may explain why DevOps teams struggle to prove their worth. In this article we’ll look at some DevOps concepts and how AWS helps you build useful DevOps practices.

The DevOps Promise

DevOps has its roots in the Agile philosophy, from software development; i.e. using less formal planning and ‘grand-designs’ and encouraging flexibility, for more rapid changes in both the focus of the development activity, and the application being developed. With changes needed so frequently, the concepts of continuous development (CD) and continuous integration (CI) were invented to ensure that rapid and loose changes didn’t break the coherency of the whole application.

So, in theory, here’s how it works:

  1. Many developers are working in parallel to less of a rigid plan
  2. Developers are encouraged to commit small changes, and often.
  3. When a developer commits a change, the system automatically takes this plus the current version of everyone else’s code
  4. …and builds it, applies pre-defined tests to ensure it all still works together, and gives that change the red or green light.

In very general terms, CI and CD are the same thing, with different end-states. CI focusses on checking code changes integrate with the rest of the code. With CD, the testing idea is extended, and in some cases each committed code change results in a new build, and potentially a release of that into live production use, or at least something in a more advanced, ready-to-go state.

This requires automation ‘systems’ that integrate with developers, testers, code, development environments, source control systems, CD pipelining tools and infrastructure to test and run the code on – and a bunch of people who understand all of the above, and can make it join up and work: DevOps staff.

Why this doesn’t always work in practice

According to Gartner, 80% of companies asked said they’ve received no benefits from setting up a DevOps team. This is likely to stem from a basic non-agreement of what DevOps actually is and what its goals are. Often system administrators are labelled ‘devops’ without a very clear set of objectives, or understanding of the roles, abilities and needs of the other people involved. And then, when it becomes apparent that the new team hasn’t saved the company a bunch of money, the whole thing is seen as ‘not working’.

That’s not how its supposed to be.

How to get the best from your DevOps AWS team

Every situation and company is different and if your DevOps team is made up of brilliant people who are always on hand to rescue any situation, then DevOps is probably a success for you. If you are not so fortunate, there are three things you can do to set up your team so they have every chance of delivering:

  1. Ensure the design of the CI / CD pipeline is sound, including the philosophy behind what it’s trying to prove: sensible tests defined, that accurately reflect success and failure, and with which everyone involved agrees (there has to be a bit of ‘grand-design’)
  2. Check your developers can get answers (in a language they understand) when something other than code isn’t doing what it’s supposed to – and have it resolved quickly.
  3. Have an infrastructure guy that can speak ‘developer’ and can second-guess what they mean in the context of infrastructure and can sort it out quickly, whatever it is.

Ideally that’ll look like a unified, fully-automated code-testing and pipeline system with automated Cloud infrastructure deployments, built immutably from scripts. That lot should be built around a single, coherent description of what the target operating model is supposed to be; including how developers, testers, DevOps and release managers should work together. The advantages of this are:

  1. You get a predictable, typical release cycle with a process that is understood. This ensures the major players know who and what needs to be planned and when (or if) those rules can be broken without major headaches later on.
  2. You’ll have commonality across platforms, tools and infrastructure methodologies.
  3. It encourages agreement on the application update method.

Clearly, this is a huge and complex topic, with different businesses – and even different developers – determining their own way of working. In a nutshell: if you can incorporate automation, agreed standards and a common well-understood infrastructure that reliably builds itself every time something is changed or tested, then your DevOps will be a whole lot easier – and a LOT more productive.