DevOps in MSA

DevOps revolves around a set of operational guidelines in the software development and release cycles. The traditional development engineer is no longer living in their confined environment where all the focus is to convert functional specifications into code; rather, they should have an end-to-end awareness of the application.

A DevOps engineer would oversee, understand, and be involved in the entire pipeline from the moment the entire application is planned out, converting business functions into code, building the application, testing it, releasing it, monitoring its operations, and coming back with the feedback necessary for enhancements and updates.

That does not necessarily mean that a DevOps engineer would be responsible for all development and operational task details. Individual responsibilities within the application team may vary in a way to guarantee a smooth continuous integration and continuous deployment (CI/CD) pipeline of the application:

Figure 1.11: DevOps CI/CD pipeline

One of the main objectives of DevOps is to speed up the CI/CD pipeline; that’s why there is a lot of emphasis on automation in DevOps. Automation is essential to efficiently perform the pipeline.

Automation can help at every step of the way. In DevOps, many test cases that are part of your QA plan are automated, which significantly speeds up the QA process. The release management and monitoring of your application are also automated to provide high visibility, continuous learning, and quick fixes whenever needed. All of this will help organizations improve productivity, predictability, and scalability.

DevOps is a holistic view of how the application is developed and managed. It is not a function for only the development team or operational team to adopt; rather, the entire organization should adopt it. It is therefore imperative for the organizational structure and the organization’s vision and goal to all align with the set of procedural and functional changes necessary to shift from the traditional way of developing software.

Just to give you a gist of how traditional and DevOps models differ in terms of application development and release cycles, take a look at the following comparison table:

Table 1.2: Traditional operational style versus DevOps

In traditional development environments, you have a big piece of code to write, maintain, and change when needed. Because of the code size, it is only normal to have a long release cycle, and it can only be feasible to deploy patches or new releases when only major changes or high-severity fixes are needed, as illustrated in the following diagram:

Figure 1.12: Traditional development environment versus MSA DevOps

In MSA, teams are separated based on applications that do not function. That big chunk of code is split into a collection of much smaller code (microservices), and since teams are split to work independently for each team to focus on a specialized microservice, the development and release cycles are much shorter.

Similarly, in DevOps, the application is broken down into smaller pieces to enable the CI/CD pipeline, which makes DevOps the perfect model that fits MSA.

Why ML?

Using ML tools and algorithms in your MSA enterprise system can further enhance and accelerate your DevOps CI/CD pipeline. With ML, you can find patterns in your tests, monitor phases of your pipeline, automatically analyze where the faults may be, and suggest a resolution or automatically fix operational issues whenever possible.

ML can greatly shorten your MSA enterprise system’s TTM and make it more intelligent, self-healing, resilient, and supportable.

We will in this book discuss two aspects of ML: first, we’ll explain in detail how to add CI/CD pipeline intelligence to your MSA enterprise system, and second, we’ll look at how to build an ML enterprise system with MSA in mind:

Figure 1.13: Using ML in CI/CD pipeline