Chapter 4: Scaling DevOps

DevOps started—and is in some companies still done—with a lot of manual tasks, scripts, and ad hoc tests. A lot of enterprises focus on the applications and tend to forget about the platform itself—the infrastructure—but this is also crucial to the scaling. This chapter focuses on the scaling of DevOps, both from a technical and an organizational perspective.

After completing this chapter, you will have learned how to handle scaling. First, we will learn about modern DevOps, which adopts cloud and cloud-native technology as target platforms to run applications. Before we can do that, we probably need to transform the applications; otherwise, we will develop new applications. In DevOps, we need a development method that fits to the way of working; therefore, we will discuss rapid- application development (RAD). Next, we will look at adopting DevOps throughout a whole enterprise, starting small and then expanding. Finally, we...

Understanding modern DevOps

The concept of DevOps is not new. Basically, the idea was that teams could improve their work if developers and operators were really working together as one team. The reason for that was easy to find, as we've already seen in Chapter 1, Defining the Reference Architecture for Enterprise DevOps. In this section, we will learn how DevOps has evolved over the years and what the impact of modern DevOps has been on enterprise information technology (IT). We will also study how DevOps helps in transforming legacy applications by app modernization.

A lot of enterprises decided in the 1990s that IT was not a core business and could be outsourced to suppliers. Typically, all management—operations—of commodity IT was outsourced. It created not only silos within enterprises, but also outside of them. Over time, IT got more complex, demands increased, and enterprises found themselves in a position of having to find ways to get back into the...

Working with RAD

So far, we discussed how DevOps breaks down silos between developers and operations and how it helps in speeding up the development of products, services, and systems. Implementing DevOps will increase the velocity of development, but DevOps in itself is merely a way of structuring planning of development. It helps in planning in iterations: starting with a minimal viable product (MVP) and then iterating improvements in next versions. DevOps is not about the development of code itself. We need a development methodology for writing the code, but that methodology should fit with DevOps. In this section, we will look at RAD.

Why does RAD fit to DevOps and the agile way of working? The main reason is that RAD is agile in itself. RAD starts with prototyping (the MVP) and then focuses on iterations. The emphasis is on the fulfillment of requirements, rather than on planning. It allows developers to realize quick improvements and adjustments during the development cycle...

Scaling infrastructure with DevOps

One of the key features in modern DevOps is the use of cloud technology. In this section, we will discuss why enterprises gain a lot of benefit by moving infrastructure in cloud platforms such as AWS and Azure. First, we will study the principles of scaling, since this is one of the major benefits of using cloud infrastructure. At the end of the section, we will also touch upon next-level scaling with containers, given the fact that in the coming years, there will be a big shift from VMs to containers.

In DevOps projects, developers use pipelines, as we have seen in the previous chapter. Code is pulled from a repository, changed, tested, and pushed to the next stage. Code follows a promotion path: from development to test, acceptance, and—eventually—production systems. Development and test systems might not always be needed; they simply have to be there whenever they are required in the process. If the work is done, then these systems...

Scaling DevOps in an enterprise environment

We've discussed the benefits of DevOps and what cloud adoption, automation, and an agile way of working could bring to an enterprise. The big question is: How and where to start? Opinions differ here, from a big-bang approach to step-by-step adoption.

Enterprises that have a lot of their IT muscles outsourced to different IT suppliers and that have been working for decades in a certain way are not easily changed. For one, there will be a lot of pushback from staff—remember that DevOps is also about changing a mindset or a culture. In this section, we're taking the approach of step-by-step adoption, or evolution instead of revolution.

Here are some recommendations:

• Start small: Don't start by implementing DevOps on large projects. Organize a small team and a simple project to learn and—even more important—to identify possible bottlenecks in the processes. What is possibly hindering the DevOps...

Managing mission-critical environments with DevOps

In this section, we will discuss DevOps for mission-critical environments and why it can be done to manage core applications. Let's first define mission-critical.

A very straightforward definition would be: any software that an enterprise needs to remain in business. If a mission-critical system were to fail, the enterprise would potentially lose a lot of money, either due to direct missed transactions or through things that are less tangible, such as reputation damage. These systems are identified through the process of business impact analysis (BIA).

When we start with DevOps projects, the first thing that an architect does is gather the business and technical requirements. That would include the outcomes of the BIA process, which is typically done in cooperation with internal auditors and business stakeholders. From the BIA, critical systems or system components are identified that need to be restored very quickly in...

Summary

This chapter covered a lot of ground. It's not easy to start with DevOps in large, traditional enterprises, but it is possible. In this chapter, we learned that we can start small and then slowly expand. Starting small doesn't mean that an enterprise doesn't need to have an end goal in mind: the enterprise architect has a key role in defining the target operating model and the way the enterprise will develop and operate products in the future. A CoE with SMEs can guide in this transformation.

There's a good chance that the company has legacy environments that will need to be transformed. We've discussed modern DevOps and using cloud and cloud-native technology. We also learned about different transformation strategies for applications and how we can develop new applications in DevOps mode using RAD.

In the last section, we also learned that even mission-critical systems can be developed and managed in a DevOps way, if we focus on resilience and...

Questions

1. We are migrating an application from an on-premises system to Azure. The SQL database is migrated to Azure SQL as a PaaS solution. What do we call this migration strategy?
2. Name the Kubernetes services that Azure and AWS offer.
3. To assess business-critical systems, we need to analyze the requirements of these systems. What is the methodology for this?

Further reading

The Modern DevOps Manifesto (https://medium.com/ibm-garage/the-modern-devops-manifesto-f06c82964722) by Christopher Lazzaro and Andrea C. Crawford, 2020