Book Image

Implementing Modern DevOps

By : Danny Varghese, David Gonzalez
Book Image

Implementing Modern DevOps

By: Danny Varghese, David Gonzalez

Overview of this book

This book follows a unique approach to modern DevOps using cutting-edge tools and technologies such as Ansible, Kubernetes, and Google Cloud Platform. This book starts by explaining the organizational alignment that has to happen in every company that wants to implement DevOps in order to be effective, and the use of cloud datacenters in combination with the most advanced DevOps tools to get the best out of a small team of skilled engineers. It also delves into how to use Kubernetes to run your applications in Google Cloud Platform, minimizing the friction and hassle of maintaining a cluster but ensuring its high availability. By the end of this book, you will be able to realign teams in your company and create a Continuous Delivery pipeline with Kubernetes and Docker. With strong monitoring in place, you will also be able to react to adverse events in your system, minimizing downtime and improving the overall up-time and stability of your system.
Table of Contents (17 chapters)
Title Page
Credits
About the Author
About the Reviewer
www.PacktPub.com
Customer Feedback
Dedication
Preface

DevOps: Organizational alignment


Up until now, we have looked at how the modern and traditional release life cycle works. We have also defined what a DevOps engineer is and also how they can help with Microservices, which, as explained, are not viable without the right level of automation.

Apart from technicalities, there is something that is extremely important for the DevOps culture to succeed: organizational alignment.

The traditional software development used to divide teams into different roles:

  • Business analysts
  • Developers
  • System administrators
  • QA engineers

This is what we call horizontal slices: a team of system administrators has a few contact points with the developers so that they get enough information to deploy and maintain software.

In the modern release life cycle, this simply does not work. Instead of horizontal slices of our company, we need to get vertical slices: a team should be composed of at least one member of every horizontal team. This means having developers, business analysts, system administrators, and QA engineers together...well, not 100%.

With the DevOps philosophy, some of these roles become irrelevant or need to evolve. The idea is that a single team is able to build, deploy, and run an application on its own without anything external: this is called cross-functional autonomous team.

In my professional experience, cross-functional teams are the best organization for delivering high-quality reliable products. The product is run by people who build; therefore, they know it inside out. A combination of analysts (depending on the nature of the business), developers, and DevOps engineers is all you need to deliver high-quality software into production. Some teams might as well include a QA engineer, but in general, automated testing created by DevOps and developers should be the holy grail: it is impossible to release software in a continuous delivery manner without having good code coverage. I am a big fan of the analyst being the one that tests the software as he/she is the person who knows the best the requirements and is, therefore, the most indicated to validating them.

The DevOps engineer plays a cross-cutting role: they need to know how the application is built (and possibly be part of its development), but their focus is related to the operation of the app: security, operational readiness, infrastructure, and testing should be their day-to-day job.

I have also seen teams built entirely by DevOps engineers and analysts without any pure developers or QAs. In this variant, the DevOps engineers are responsible for the infrastructure part as well as the application development, which can be very challenging depending on the complexity of the system. In general, every case needs to be studied in isolation as DevOps is not a one size fits all product.