Book Image

Enterprise DevOps for Architects

By : Jeroen Mulder
4 (1)
Book Image

Enterprise DevOps for Architects

4 (1)
By: Jeroen Mulder

Overview of this book

Digital transformation is the new paradigm in enterprises, but the big question remains: is the enterprise ready for transformation using native technology embedded in Agile/DevOps? With this book, you'll see how to design, implement, and integrate DevOps in the enterprise architecture while keeping the Ops team on board and remaining resilient. The focus of the book is not to introduce the hundreds of different tools that are available for implementing DevOps, but instead to show you how to create a successful DevOps architecture. This book provides an architectural overview of DevOps, AIOps, and DevSecOps – the three domains that drive and accelerate digital transformation. Complete with step-by-step explanations of essential concepts, practical examples, and self-assessment questions, this DevOps book will help you to successfully integrate DevOps into enterprise architecture. You'll learn what AIOps is and what value it can bring to an enterprise. Lastly, you will learn how to integrate security principles such as zero-trust and industry security frameworks into DevOps with DevSecOps. By the end of this DevOps book, you'll be able to develop robust DevOps architectures, know which toolsets you can use for your DevOps implementation, and have a deeper understanding of next-level DevOps by implementing Site Reliability Engineering (SRE).
Table of Contents (21 chapters)
1
Section 1: Architecting DevOps for Enterprises
7
Section 2: Creating the Shift Left with AIOps
13
Section 3: Bridging Security with DevSecOps

Introducing DevOps components

So far, we've learned how to start defining the architecture, looked at the architecture principles for DevOps, and drafted a reference architecture model. The next step is to look at the different components within DevOps. In this section, we will learn what components must be included in a DevOps architecture. This is tier 3 of our target enterprise model – the level where all the activities are executed.

The following diagram shows all the components that will be discussed briefly:

Figure 1.5 – The DevOps life cycle

Figure 1.5 – The DevOps life cycle

The reason that this has been presented as an infinite loop – or a pretzel – is because feedback from the live product that is managed by ops (operations) will be continuously looped back to dev (development) to improve the product.

The different components are as follows:

  • Plan
  • Create (in some DevOps models for components, this is referred to as Code and Build)
  • Test (in some models, this is referred to as Verify or Validate)
  • Preprod (in some models, this is referred to as Pre-release)
  • Release
  • Configure
  • Monitor

At this level, interoperability is crucial. Remember that large enterprises will likely work with several service providers, fulfilling parts of the IT delivery process. When we want all these companies to work together in a DevOps way, we need to make sure that the processes and tools are aligned. Next, we need to have a common understanding of the various activities that are executed as part of these processes. The key term here is consistency. All DevOps components must be defined and implemented in a consistent way. Every developer and operator must work according to the same definition and with the same components.

The main question is, in what stage should ops already be involved? The answer is, at the earliest stage possible, so indeed in the plan phase. Ops plays a key role in defining how products can be managed once they've gone live. They should set requirements and an acceptance criterion before going live. If a developer builds something that can't be managed by ops, the product will fail, and business demands will not be met.

The following table breaks down the components into activities:

In Chapter 2, Managing DevOps from Architecture, and Chapter 3, Architecting for DevOps Quality, we will dive deeper into this and how architects can improve their designs for these components using CI/CD pipelines to enable automation, collaboration, and integration.

In the next section, we will discuss the drivers for architecture from a business perspective, as laid down in SLAs and KPIs.