DevSecOps in Kubernetes

Chapter 1. Software Development Life Cycles

The problem with software development, as an intellectual activity, is that you can’t manage development projects in the same way you can other projects. With a project like building a house, adding more people to the project (as long as they can operate construction tools) can shorten the overall time it takes to complete the house. In software development, the relationship between people and time to complete is much more complex.

In this chapter, we’ll take a quick look at the origins of software development. We will examine the process’s benefits and the essential stages that any methodology must include. Then we’ll dive a little deeper into the pros and cons of several of the most popular methodologies.

The Value of Processes

Why bother with a methodology? Developers and project managers have learned a lot since the early days of serious software development projects of the 1960s. They’ve created a variety of methodologies to help get large-scale software projects (and even small ones) done faster, more efficiently, and with higher quality. Sometimes the new methodologies spring from a desire to solve a problem the developer experienced with another methodology.

Different methodologies have different goals and different problems. A methodology that works wonderfully for one organization might be a bad fit for another. One thing is clear, though: having a methodology is vital.

Repeatability and Consistency

One goal of any process or methodology is repeatability: you know how to do it again. When you are building something to be sold, you want consistency. You want to know that you’ve done everything as well as it can be done and in the same way as all the other things, without variation. Variability can lead to defects, which will of course make it more difficult to sell your product. In software, defects are bugs, and no one wants to release buggy code. Consistency is one way to help limit the number of bugs that are in your released software.

Process Improvement

With a process, you can evaluate how you’re doing something and learn from how well it works. You can constantly improve your process to remove defects. (Some methodologies emphasize reducing defects, such as Six Sigma.)

Focusing on process improvement is one of the hallmarks of a mature organization. In Capability Maturity Model Integration, a maturity model developed at Carnegie Mellon University, the highest level of maturity an organization can reach is Optimizing. This is where the organization has developed a process that it follows regularly and puts effort into learning lessons and improving that process over time.

There may not be as much concern for individual projects or even very small projects getting repeatability, consistency, and process improvement, but commercial organizations should be concerned with these. Without the right methodology to help organizations focus on these factors (or, worse, without any methodology at all), the quality of the product is likely to be poor or inconsistent.

DevOps

Historically, there have been a lot of problems with software development methodologies. Long-standing methodologies like waterfall result in long development times with limited communication. This can lead to high cost and low quality, which are not good results from a software development process.

Communication problems are nothing new in software development. As companies move toward web applications and web-based deployments, operations teams have become bigger stakeholders than they have in the past. There are several great comics and graphics that highlight how software development used to happen before DevOps became popular. These illustrations usually involve a developer on one side of a wall tossing a software project over to the other side of the wall where the operations person stands. There is no communication and there may not even be much of anything in the way of documentation.

DevOps is not so much a methodology, as it is a culture. The culture of DevOps is meant to more tightly integrate the operations staff with the development staff. The operations staff is meant to be there through the requirements gathering to ensure they can deploy and manage the application when it’s developed.

DevOps focuses a lot on automation and testing. The goal of DevOps is to improve the overall quality of software development processes by automating as many aspects of software development, building, and deployment as possible. Many DevOps organizations use something called a development pipeline, which means that when software is checked in to the code repository, indicating the developer has completed a task and they want to return the file to the repository so someone else can use it, an automated process starts to perform tests, build the software, and then perform more testing. An approach like this means you can ensure the testing is completed prior to deployment rather than rushing to deployment while testing is done in parallel.

This is not to say that all tests can be automated. In some cases, the testing team will still need to perform testing while deployment is going on, but with short development cycles, any bugs that are found can be resolved quickly and moved into production quickly.

All of this automation means that processes can be fully tested. When you move to automation, you have another piece of software that can be tested because the automation is a program or script. This removes the human potential for error from the equation. The automation programs or scripts can be fully tested to ensure they do exactly what they are supposed to do prior to using them. Any changes can similarly be tested prior to moving into production.

Kubernetes and the Software Development Life Cycle

When developing software, whether it’s a complete application or just an application programming interface that can be used by either a web-based or mobile frontend, someone needs to be thinking about the whole application life cycle—not just the part where the developers are building software. Kubernetes can help support these efforts. During the requirements gathering phase, a team may find that the best way to support the overall goals of the project is to implement Kubernetes. This will not only resolve some requirements, potentially, but also introduce other requirements. Applications are not usually fully formed out of the gate, but instead a picture of what the application should be arises from an iterative view of requirements. One requirement begets another requirement and so forth until the entire view of the application or project is complete.

When a development project commences, there is a requirements phase during which a lot of decisions about the direction of the project are made. This is where Kubernetes comes in, since it is best to decide to select Kubernetes as the orchestration platform up front. This will direct some of the development efforts since Kubernetes was designed for containers. The developers and operations staff know from the very beginning that they will be working with a virtualized application environment. This also means additional development is necessary, or at least a lot of communication is required here since the operations team will be responsible for deploying the project, which means they will probably also be responsible for developing the orchestration scripts and configurations that will be managed through Kubernetes. This is where DevOps and DevSecOps comes in handy as a practice, which we will get into in more detail in Chapter 3.

One problem, historically, with testing has been that test environments look different from development environments. Developers write software on their systems, which are configured entirely differently from test systems. Testing containerized applications can be made considerably easier in a Kubernetes environment, since Kubernetes will help make sure every instance of the application space looks the same every time. This means the testing team can be working in exactly the same environments as the development team. When you abstract away from the individual system and virtualize the application, you get the benefit of the application running in an isolated space with only the prerequisites and dependencies necessary for the proper functioning of that application.

Operations teams have spent years trying to make their lives easier, first by writing scripts and creating frameworks to support large numbers of physical systems, and then later doing the same for virtual machines and all the networking and other supporting infrastructure necessary for a complete and complex web-based application. In both deployment and post-deployment, Kubernetes supports operations teams by providing a management framework that takes care of all orchestration that teams had to previously perform manually due to a lack of knowledge or resources, including provisioning of compute resources, storage, and networking, to name a few.

Deciding to use Kubernetes can have a big, positive impact on the overall development of an application from requirements through deployment and operation of the application. It’s important to ensure all team members are aware of the benefits and requirements of the use of a tool like Kubernetes, though.

Summary

Software development is a complex task with a lot of people involved in addition to the software developers themselves. Just writing code is a complex endeavor. It helps to have a development methodology to ensure the software that is developed is what the business, the user, or the customer is looking for. As always, identify the problem before identifying the solution.

There have been a lot of different development methodologies over the years. In some cases, a development methodology is a philosophy or a culture as much as anything else. This is especially true when it comes to DevOps. DevOps fits very well with modern software development practices, though it can be a challenge to implement due to the strong focus on communication. For entrenched development teams used to walls or silos constraining the different teams, this can be a challenge that needs to be overcome. Focusing project management, development, testing, and operations around a single platform like Kubernetes can help guide the necessary communication across teams because everyone is working in the same direction on the same technology, which has not always been the case with development teams.

Additionally, DevOps fits well with Kubernetes, which requires support from all of the team members across the SDLC. Deciding to use a tool like Kubernetes during the requirements/design phase of the life cycle can introduce additional requirements but can also provide a lot of answers to other team members like developers and testers, which may make life easier and contribute to the overall quality of the application.

Beyond this teaser, we will spend the rest of this book looking at other practices within DevOps that will be beneficial for high-quality application development.