Your recipe for career & DevOps success in 2017 – and beyond

Source – itproportal.com

If you work in DevOps then it’s very helpful to know why businesses are so focused on continuous automation. Knowing this helps you understand the role you as a practitioner have in creating value – and the skills that will help you perform that role.

There are a number of things businesses are really trying to achieve with DevOps, which can be understood and measured with the following key metrics

Speed: the rate of software change
Efficiency: the stability and effectiveness of software change
Risk: the quality of software change.

To improve speed you need testing platforms and automation tools that help you get code out the door faster. They help you iterate more flexibly with fast feedback, rather than relying on slow batch processes or having to raise a ticket, then wait for another team to respond.

Automation can also improve efficiency because instead of starting from scratch you’ll have recipes that are already appropriate for 80 to 90 per cent of the requests you receive. This means you only have to do 20 per cent of the work you were doing before, to tailor your code.

Risk is decreased by having a standardised approach across all the platforms you manage. This makes fixing problems much easier, and takes less time. Having to patch two different Windows environments rather than six means one third of the complexity. A more predictable way of testing and releasing software also means you can make more informed decisions about what changes and innovations you’re willing and able to take on.

As a DevOps practitioner, your role in delivering on these metrics is through some of the key elements of continuous automation – infrastructure, compliance and applications. All of which can be provided and managed as code. Let’s take a look at each of these elements, and some of the skills and resources that will be of most value.

Infrastructure as code

Infrastructure as code (IaC) refers to the process of provisioning and managing data centres through machine-readable definition files, as opposed to interactive configuration tools, or even physical hardware configuration.

There will be elements of IaC some people won’t be familiar with, such as source code control – checking your work into a version control system like git., and using a language where everything is described in the code.

However, it’s vital to get comfortable with the workflow of infrastructure as code – because it underpins all of continuous automation, as well as the deployment of compliance and applications as code.

Doing this means phasing out workflows that include more old school, interactive configuration tools and the graphical user interfaces (GUIs) they come with, as well as the supporting handbooks and screen captures showing you how to use them…

And instead focusing on learning newer, more sophisticated tools like Git and Microsoft Team Foundation Server which allow you to check, manage and collaboratively develop your source code in a central repository. As well as testing it in your ecosystem before you release it.

While these tools are more sophisticated, the benefits are huge. Because they make your work repeatable – with the same outcome every time, they unlock all the capabilities DevOps has to offer, across the entire application lifecycle. This is essential for delivering against the three key metrics mentioned earlier – speed, efficiency and risk.

The new Learn Chef website is a great place to start learning about infrastructure as code – I would also recommend checking out this set of training videos on YouTube – The Joy of Automating, which go through IaC, testing and workflow in more detail.

Compliance as code

Continuous automation is valuable because it increases speed – but velocity requires safety. Without it, being fast can do more harm than good! After all, security and compliance are non-negotiable standards for every business.

The old-fashioned way of working on compliance involves waiting on patches and checks to be provided by a vendor. These standards and guidelines are often published as documents and large PDF files rather than as tools – which you then have painstakingly wade through and decode – which creates inefficiencies and confusion. Because security and compliance are so important, their requirements should be explicit and well understood by all stakeholders. When they are, it’s also much easier to manage competing priorities in compliance and security workflows

For Chef, our work in the this category has focused on InSpec. It’s an open-source testing framework for infrastructure with a human-readable language for specifying compliance, security and other policy requirements. InSpec takes those big PDF’s and turns them into code everyone can understand.

When compliance is code, you can also integrate automated tests that check for adherence to policy into any stage of your deployment pipeline. You can also ensure insecure services and protocols, such as telnet, aren’t used, and make sure web servers are only listening on well-secured ports, for example, to meet PCI DSS encryption requirements.

You can also add metadata to help you communicate compliance requirements to all your team members – so development, operations, compliance and security, all have access to compliance rules. Because the rules can be unambiguous – this also helps them everyone on your team understand them. Instead of spreadsheets filled with abstract descriptions – you have tangible tests with a clear intent.

If being able to deliver this kind of value for your organisation sounds like it would be a step in the right direction, take a look at our dedicated Compliance Automation track on the Learn Chef site.

While our engineers are always hard at work baking the latest best practices and intel into InSpec, it’s still worth keeping an eye on the news, research, identified vulnerabilities and training options coming out of the CERT Software Engineering Institute at Carnegie Mellon. The Centre for Internet Security is another good resource to keep bookmarked too.

Applications as code

Applications as code is a new, more advanced category that helps you modernise and automate your traditional apps so they can run on any infrastructure – as well as helping you build and run containers more collaboratively.

Within this category we’ve created Habitat – a tool designed to give developers and operations a consistent way to build and run applications in a Cloud Native manner. You can package any services you need with a simple Plan file and change the configuration in a declarative way. You can also integrate with monitoring and management tools through a RESTful API and manage your traditional services like you manage your containers.

Habitat also simplifies two areas of Continuous Delivery that people often struggle with – Microservices and Immutable Objects.

Microservices is where a large monolithic codebase is split into smaller pieces which need less resources to manage. The downside is that you end up with increased complexity and lots more individual applications. With Habitat – your apps are packaged so they can work in a Microservice native environment just like they can in any other.

This idea of building your app once, and having it run the same in any environment also helps with the creation of Immutable Objects. It does this by ensuring the version of the app you’re running in a test environment is exactly the same as the app that goes into production.

Applications packaged with Habitat have the intelligence to self-organise and self-configure. Habitat allows the application to be portable across independent infrastructure environments and have the intelligence to select the infrastructure features that benefit that application. This makes it easy to run applications across increasingly diverse environments such as containers, PaaS, cloud infrastructure, and on-premise data centres, while also accelerating hybrid cloud environments.

By narrowing down the different ways apps are built, and the things they depend on, with more of a strict structure, you minimise – or flat out prevent – many of the issues you can have with even small app updates.

Moving the app up the stack in this way, fixes many of these application issues we’ve seen in e.g. the Ruby and Python communities, such as wrangling with version or system vendor differences. It helps you build an artifact that’s immediately deployable, with a huge amount of engineering expertise built-in, which takes out a lot of the complexities engineers usually have to worry about.

We believe this is the future of building apps, so if you would like to be part of this new and exciting open-source community, it’s worth checking out our Habitat tutorials. They include an introductory tour of the basic capabilities, plus conceptual diagrams, videos – and an interactive terminal demo.

It’s also worth sharpening your skills when it comes to the Bash command language, as this is the Unix shell Habitat uses, and re familiarising yourself with the build tools out there, more generally.

The tougher the journey, the greater the reward

It’s important to understand there’s no single DevOps book, guide or tool you can totally rely on – success requires a holistic approach to self-education.

Some good books to read to get your head around how this all works in more detail, are Jez Humble and David Farley’s “Continuous Delivery: Reliable Software Releases Through Build, Test, and Deployment Automation”. And “Effective DevOps: Building a Culture of Collaboration, Affinity, and Tooling at Scale”, by Jennifer Davies and Katherine Daniels, as well as “The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win”, by Gene Kim, Kevin Behr and George Spafford. Our free guide to Embracing the DevOps lifestyle is a good place to start too.

Working in DevOps is demanding because it takes a lot of work and continuous self-education to stay well informed in such a fast moving area of IT. But it’s also incredibly rewarding, because of the culture, because of the career opportunities – and because of the personal growth it demands.

If you can make and honour a commitment to yourself to never stop learning, and keep in mind the key values businesses want to achieve with DevOps, you’ll be on your way to a very bright future indeed.