Michael
Michael DevOps, Cloud, Performance skills, High math skills

DevOps to NoOps

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 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 aspects of software delivery and production taking care about our team culture and mental awareness. Let’s try to have a glance into the production process, historical aspects and reasons of 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 develop to move or discover new business opportunities from real world into the digital world. What does it mean for making software in general.

There are three key factors in Digital Transformation:

digital transformation
  • Processes - automated software development and maintaining 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 like we quoted is human approach, culture and experienced

NoOps

Everything has 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 scale was very small in comparison to 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 new profession called DevOps dedicated for managing process automation for our modern architecture.

Automation

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

automation


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, security verification should always be a part of automated pipeline process.

  • SaaS. Of course there are many successful on-premise deployment, but in most cases using Software as a Service and cloud environments can diametrically increase 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 manual way.

Everything as code

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

There are several areas to review:

  • Automation. 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.

gitlab pages
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 tests implementations. Especially for large enterprise legacy systems, their teams try to test everything with E2E in nightly build process, forgetting about the basic E2E rule:

tests pyramid

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 tests defects they are not automated, this simply leads to manual activities, analysing and maintaining this process.

  • Make some compromise. If your software contains some legacy or unstable components which periodically fails 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 the route and next step for 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 aware development team. Let’s start your NoOps journey and please sin no more!

good luck