Implementing DevSecOps

The typical reason why most enterprises adopt the cloud is to accelerate application development. Applications are constantly evaluated and changed to add new features. Since everything is codified in the cloud, these new features need to be tested on the infrastructure of the target cloud. The final step in the development process is the actual deployment of applications to the cloud and the handover to operations so that developers have their hands free to develop new features again based on business requirements and feedback from the customer and operations.

To speed up this process, organizations work in DevOps cycles, with continuous development and the possibility to test, debug, and deploy code multiple times per week or even per day so that these applications are constantly improved. Consistency is crucial: the source code needs to be under strict version control. That is what CI/CD pipelines are for: continuous integration and continuous delivery...

Understanding the need for DevSecOps

Before we dive into the layers of DevSecOps, it’s good to understand why DevSecOps is important in multi-cloud. First, we must understand the layers of securing the cloud. There are four layers to be considered:

1. Organizational level, or the overarching governance
2. Enterprise level, ensuring the security across accounts, auditing centralized compliance through monitoring and logging, and promoting automation
3. Subscription level, using Role-Based Access Control (RBAC), threat detection, and in-depth defense
4. Solution level, using CI/CD with validated templates, blueprints, and images

We must define security at all levels. The following diagram shows all levels of defense in the cloud.

Figure 13.1: Levels of security in application stacks

The top of the stack is formed by the application payloads. In multi-cloud, enterprises will likely use containers and CI/CD pipelines. With multi-cloud, enterprises...

Starting with implementing a DevSecOps culture

In the previous section, we already mentioned the NIST guide to secure containers. That guide starts with something non-technical: a mindset. The first advice NIST gives is:

Tailor the organization’s operational culture and technical processes to support the new way of developing, running, and supporting applications made possible by containers.

Why would we need to change the culture in the way we do IT? Because with cloud, cloud-native, and containers, the way of doing software development changes drastically. Developers and operations might be less concerned with traditional IT processes such as patching and upgrading systems. We want to integrate security in to the builds of the applications, including the way applications utilize the underlying infrastructure without having to worry about the physical infrastructure or even the virtual machines. Let software take care of it, but then the software must be...

Setting up CI/CD

Before we start building pipelines, it’s good to have a definition of CI and CD.

Continuous Integration (CI) is built on the principle of a shared repository, where code is frequently updated and shared across teams that work in the cloud environments. CI allows developers to work together on the same code at the same time. The changes in the code are directly integrated and ready to be fully tested in different test environments.

Continuous Delivery and Deployment (CD) focuses on the automated transfer of software to test environments. The ultimate goal of CD is to bring software to production in a fully automated way. Various tests are performed automatically. After deployment, developers immediately receive feedback on the functionality of the code.

CI/CD enables the DevOps cycle. Combined with CI/CD, all responsibilities from planning to management lie with the team, and changes can reach the customer much faster through an automated and robust...

Working with CI/CD in multi-cloud

The development of code for applications can be cloud-agnostic, meaning that it doesn’t matter to which cloud the code is pushed: the functionality of the code remains the same. That’s the reason why we use containers: to abstract the code from the underlying infrastructure. However, a lot of developers will discover that it does matter and that it’s not that simple to develop in a truly multi-cloud fashion.

In multi-cloud, developers also work from one repository, but during deployment, platform-specific configuration might be added and tested, even when we utilize Kubernetes platforms in our clouds. You will find that Kubernetes is the same, but the various implementations of Kubernetes platforms in clouds might differ.

There are a few steps that developers have to take to make it successful. First, the DevOps way of working should be consistent, regardless of the platform where applications will eventually land. A...

Join our book community on Discord

https://packt.link/multicloud

In the previous chapter we looked extensively at the FinOps processes and how we can implement these in an organization. We also looked at how costs are generated in the various cloud platforms by evaluating provisioning of resources. Now we have to make sure that costs are allocated in the right way and that these are booked at the right level in the organization.

This chapter we will learn how to develop and implement a cost model that allows for showback and chargeback in our organization, allowing to identify cloud costs and allocate these to the budgets of teams or units. Before we do that, we must understand the principle of cost coverage, the type of costs in cloud and how rates are set by providers.

In this chapter, we're going to cover the following topics:

• Evaluating type of cloud costs
• Building a cost model
• Working principles of showback and chargeback

Evaluating type of cloud costs

Before we get to define a cost model, we must understand what type of costs we will be faced with in cloud.

We assume that the business has specified requirements to a specific application and that application must be hosted in AWS using Infrastructure as a Service (IaaS). The architect now must design the IaaS-layer and specify the components that he needs to host the application, including disks and non-functional requirements such as availability. The list of components is shown in the table.

The process of splitting up a cloud bill and associating the costs to each cost center. We’ll look more closely at this process in Chapter 9. It’s important to have teams understand how costs are being allocated, and to have a centralized, controlled, and consistent cost allocation strategy.

Cost coverage

A typical cloud deployment model is pay-as-you-go and that’s OK when the usage of cloud is limited. Most enterprises will have larger landscapes...

Building a cost model

To build a cost model, we have to follow three basic steps.

1. Identify cost drivers: this is something that we discussed in the first two chapters of the book. Cost drivers are closely related with the business processes. Think of the number or orders that customers of a company place in a defined time. Identifying the cost drivers will help in setting up the environment. In this particular case we must think about scaling capacity when order intake spikes. But we can also think of event-driven architecture, where the placement of an order triggers a number of events, including invoicing and payment, fetching the order in a warehouse and distributing the product for delivery. This will likely involve various systems and applications that must communicate with each other. An important question would be what could be automated and creating the optimal solution, since this will have impact on the costs.

One thing that we haven’t touched yet is the fact that costs...

Working principles of showback and chargeback

In the previous sections we learned all about type of costs, the various discount programs that cloud providers offer and we built a cost model. The latter is an extensive exercise, where we list all components that we use in our clouds.

In multi-cloud an application could span services over various clouds. By choosing the perspective of the application, all services will be captured. If we have done cost modeling right, we will know exactly what resources are connected to the application and with that what running the applications costs. Then there’s one last thing to do and that’s coupling the application to the application owner and with that the team, department, or business unit.

Before we can start the process of chargeback, we need visibility on the application chains, the resources and services that are used in cloud and the respective costs that are associated with these resources and services. This process is referred...

Summary

In this chapter we learned to build a cost model that allows us to track costs in cloud and how these costs can be allocated to specific budgets. Key is the understanding that we must cover for all resources and services that an organization uses in cloud, including all shared resources.

We also saw that to get the right costing level, we must consider that we’re dealing with various types of rates. The rates that are shown in the pricing calculators of cloud providers, are often not applicable: discount programs might be applied, influencing the true costs of cloud environments. We learned about blended and unblended rates, managed and unmanaged services, direct and shared costs, consumption based and fixed costs. All of this must be reflected in the cost model to get to an accurate showback and eventually chargeback.

This was the final chapter about FinOps. The next part of this book will be about security.

Questions

1. What is the main benefit of reserved instances for companies?
2. On invoices various rates for the same type of resources might appear. How do we call this type of rates?
3. Microsoft offers a program that allows for optimal use of licenses for Windows Server, SQL Server and various Linux distributions in Azure. How is this program called?