DevOps to NoOps

"DevOps to NoOps – Digital Transformation is not just about technology, 80% is culture – a CTO Perspective"

That’s right, if we are aware of the whole IT stuff, this is clear - technology is not everything. Of course, it is very important but to build modern solutions for demanding customers we should be aware of every aspect of software delivery and production taking care of our team culture and mental awareness. Let’s try to have a glance into the production process, historical aspects, and reasons for digital transformation.

Digital transformation

"Digital transformation can refer to anything from IT modernization (for example, cloud computing), to digital optimization, to the invention of new digital business models. The term is widely used in public-sector organizations to refer to modest initiatives such as putting services online or legacy modernization. Thus, the term is more like “digitization” than “digital business transformation." This is a Gartner definition, so in other words, digital transformation is nothing more than IT development to move or discover new business opportunities from the real world into the digital world. What does it mean for creating software in general?

There are three key factors in Digital Transformation:

• Processes - automated software development and maintenance by Continuous Integration with Continuous Delivery patterns

• Tools - modern software components and techniques like Pipelines, Terraform, and other DevOps tools

• People - the most important factor we quoted is human approach, culture, and experience

NoOps

Everything has its own cycles like seasons, moon eclipse, etc. A few years ago we didn’t have DevOps engineers - why? Because we simply didn’t need them, our software was simpler, we didn’t use microservices or micro frontends methodologies. Our development process was very simple because of the monolithic architecture. Of course, we had some issues also with monolithic applications, but the scale was very small in comparison to the current situation where our software architecture is much more sophisticated and advanced with hundreds of technologies, patterns, and components inside. That’s why we were forced by technology to create a new profession called DevOps dedicated to managing process automation for our modern architecture.

Automation

For some teams and companies, automation is like a holy grail, they try to automate processes without eliminating even the smallest human activity that can foul up all efforts. Definitely, to be NoOps we would like to be like our hero from the image below.

To achieve this goal we should focus on at least three very important software techniques:

• CI/CD. Event one manual activity inside our development process is a bad practice because our team can easily wait on this manual action to just run it manually. All activities especially integration tests, E2E tests, and security verification should always be a part of the automated pipeline process.

• SaaS. Of course, there are many successful on-premise deployments, but in most cases using Software as a Service and cloud environments can diametrically increase the time-to-market, quality, and security of our software solution.

• Infrastructure as code. To not waste our and customers’ time preparing and recreating our system architecture in a manual way.

Everything as code

Everything as code is a modern approach to building every component around the system from source code. keep and build it directly from the source code. To not leave any space for manual activities and use great mechanisms like version control systems.

There are several areas to review:

• Automation. The process can be easily stored and versioned in source code.

• Infrastructure. To avoid manual activities in our infrastructure we can describe everything with Terraform and Ansible.

• Tests. Using modern E2E frameworks like Cypress or Test containers we can put all processes into the CI/CD flow, versioning, changing, and adjusting our test cases.

• Documentation. Everything is better than Word documentation, but today we have many great tools like Markdown Asciidoc and mechanisms like GitLab Pages to create, store, publish and maintain documentation for our projects.

Figure 1. GitLab Pages Flow

Testing

Testing methodology is rather clear, especially for unit tests and integration tests. But sometimes we can observe overloaded E2E test implementations. Especially for large enterprise legacy systems, their teams try to test everything with E2E in the nightly build process, forgetting about the basic E2E rule:

So, E2E tests cannot be overloaded, but how to do this?

• Stop using nightly build. We should keep everything as fast as it is possible. Don’t wait for long E2E nightly processes because this is extremely hard to investigate who broke the build. It’s a huge waste of time doing this.

• Ensure 100% stability. If E2E tests are not stable, because of some component instability or test defects they are not automated, this simply leads to manual activities, analyzing and maintaining this process.

• Make some compromise. If your software contains some legacy or unstable components which periodically fail your test cases, it is better to exclude, mock and test them separately than blame all modern and agile components for their state.

Summary

NoOps is some kind of back-to route and the next step for the automation approach. NoOps is an ideal situation where all development processes are maintenance-free, but to achieve this goal we really need experienced DevOps and an aware development team. Let’s start your NoOps journey and please sin no more!