DevOps is a working methodology, widely used today, combining good development (Dev) and operations (Ops) practices to continuously deliver value to customers. The adoption of this methodology generally requires a multi-level restructuring (human, process and technological).

To promote its adoption and therefore its implementation, it is important to take into consideration some important points in the DevOps transformation of your company.

Be Aligned With The Business Goals

DevOps, DecSecOps, MLOps, FinOps, etc are famous trends today. All these acronyms are beautiful on paper and make us want to apply them when we see their results in contexts outside our own. However, it is important to keep in mind that a DevOps transformation requires an investment of time, resources and money from the company. It is therefore normal for any company to first understand the benefits of this transformation. Tracking trends is not required to achieve revenue, so it is important to correlate the DevOps transformation goals with the business goals to ensure project adoption.

Encourage Team Collaboration

The success of a DevOps transformation is largely based on the collaboration of the different development, operations, security, etc teams in order to identify at the enterprise, team and process level (automation, deployment, communication, etc.) improvement points and jointly define a coherent roadmap in order to respond quickly to the identified needs of each. A culture of collaboration and good communication between team members leaves less chance of mistakes and failures. Break the walls between the teams to spread the information, to make better decisions, to encourage a sense of belonging to an open-minded, efficient team in which sharing ideas is allowed and even encouraged.

Alone, you will go fast, together, you will go far.

Understand The Existing

This is important as it is not recommended to start a transformation without understanding how the business, teams and processes work. It is important to understand the existing in order to identify areas for improvement and the efforts needed to make them a reality.

Also, remember to collect metrics from the current architecture:

• Number of deployments per day, week, month
• Application deployment time
• Time required to onboard a new employee
• Level of infrastructure automation
• Ability of resources to manage new demand

Get as much data as possible to measure the level of progress of the transformation and the benefits of it regarding vis-à-vis the announced objectives.

There are many ways to achieve transformation which requires investments that must be measured and prioritized based on the knowledge of the current infrastructure.

Accept That Failures Are Inevitable

There is more than one way to successfully transform your organization to DevOps. Failure is the key to success, even in your career, because it allows you and your teammates to learn and grow.

As mentioned in the previous section, a collaborative culture allows for the emergence and sharing of many ideas that need to be evaluated and sometimes tested. The company must accept the risk of investing in certain ideas and hope to see the benefit of it. It is utopian to think that everything can be realized or imagined perfectly at first sight.

The DevOps culture requires thinking further and keeping an open mind to change by constantly asking if there may be another way of looking at things. Failure is a transitory passage that prepares you for your next success.

Define Small Objectives

A DevOps transformation takes a lot of time and resources. It is therefore necessary to define overall objectives which can be achieved in a time appropriate to the context of the enterprise. It is important to complete these objectives in order to measure the level of progress of the transformation and its benefits before moving on to the next ones.

It is recommended to define small targets first, in order to promote the start-up and adoption of the project to quickly meet the most important goals. Setting up this type of project management will allow you to develop a productive and flexible corporate culture in order to address more important issues.

Choose The Right Tools To Encourage Automation

In a DevOps ecosystem, automation is everyone’s business. At different levels, each team develops and uses automated systems to speed up and facilitate their work. Choosing the right tools is therefore an important task to increase the productivity, resilience and security of the architecture, teams and processes.

The DevOps culture must bring some flexibility in the choice of tools but it is still advisable to define a stable base on which all or a large part of the company’s processes can be based.

This transformation therefore requires the integration of several automation tools in order to meet a number of prerequisites such as:

• Manage infrastructure (on-premise as on the Cloud)
• Automate security, performance, code quality tests
• Deploy and configure any application
• Lint the code
• Enforce policies

Observe Everything

Observability is obviously an important part of a DevOps transformation. Even before the start of the project, it is advisable to collect metrics to measure the progress of change.

Observability must be at several levels:

• The Operation team must monitor all deployed environments and resources, even external third-party components, to be proactive in the event of a problem.
• The Development team needs to profile their applications and ensure a good level of logging and tracing to quickly identify issues.
• The Finance team needs to monitor infrastructure cost (especially in the cloud) in real time to control expenses and advise engineering on potential improvements.
• The Client Success team needs to gather information and report on customer feedback to determine process improvements.
• The Project Management team must measure the progress of the transformation and its benefits on the various projects of the company.

Don’t think that observability is just a matter of operations engineer, in a DevOps transformation everyone has a role to play.

Define Performance Standards

This section follows the idea from the previous point. Once the observability is in place, it will be time to think like a site reliability engineer, a database reliability engineer, a person from the security team, and even a developer to identify and implement standards that will measure and understand the performance of the entire infrastructure.

Reaching these standards over a given period of time defines the progress of your DevOps transformation. These standards generally define the company’s overall objectives with regard to this transformation and must therefore be divided into several small projects in order to facilitate their adoption.

Accelerate The Time To Market

The emergence of new ways of working such as DevOps, agility and cloud infrastructures has accelerated the competitiveness of companies in the market. It is even more necessary today to align the engineering teams to the sales teams in order to prioritize the deployment of new features in production to differentiate themselves from these competitors and thus attract new customers.

To do this, it is important to accelerate the “Time To Market” by deploying to production as quickly as possible while guaranteeing the reliability of the system and building trust in the automation of the processes. Achieving this obviously requires automated processes adopted by the development teams but also a review of the application architecture to limit dependencies between applications (like micro services). Setting a deployment date in order to put several interdependent applications of their version into production is not the purpose of DevOps and does not contribute to the competitiveness of the company.

Improve The Reliability Of Your Applications

A DevOps migration must bring some visibility to your applications. This visibility is driven by the observability of applications throughout their life cycle but also by the addition of risk control processes in automated pipelines.

This requires an update of the governance of the IT through the introduction of tools and processes that will allow an improvement in the quality management of the code developed by the teams. These control steps are very important for certain certifications (SOC, GDPR, HIPAA, etc) required by companies. It is therefore important to introduce the DevSecOps principles early in the DevOps migration.

Adopt A Cloud Native Approach Before Moving To The Cloud

The Cloud is an important component in the DevOps world because it brings the flexibility that many companies are looking for in order to be competitive in the market. For many, it is difficult to cost and plan a migration of their infrastructure to a cloud platform. This requires a good understanding of the current architecture, its constraints, its raison d'être in order to define the appropriate cloud provider and the target architecture. All of this requires time, advanced knowledge of cloud services and rigorous project management to ensure a timely migration.

Depending on the complexity of this migration, adopting an approach to a cloud native environment is highly recommended. In fact, there are now several platforms that make it possible to bring this same management flexibility to static environments such as on-premise architecture. Adopting these platforms (such as Kubernetes) allows us to work upstream in order to better visualize and plan a migration to any provider.

Control Your Expenses With A FinOps Team

As mentioned in this article, DevOps transformation has a cost in human resources, in time, and thus, in money. Introducing FinOps principles is a good practice to measure a DevOps transformation. It can even be seen as a level of maturity as it asks for multiple teams (operations, development, finance, security, etc) to work together to control the cost throughout the project.

This team collaboration makes it possible to optimize the costs of a transformation as soon as possible, thus reinforcing the confidence of the executive in the ability of the teams to manage their finances.

Think Of Other Areas Like MLOps

DevOps has changed a lot in the way we work. This methodology has added many advantages to our way of managing our architects, our applications, and our integration. It is therefore normal to see in recent years a move towards other areas such as machine learning platform management.

Considered an extension of the DevOps world, the MLOps is today the daily life of many engineers whose goal is to optimize the platform management once considered complex.

These platforms, which are now the heart of many companies, require different management processes than traditional web applications, while having similarities. These workflows must also be automated, tested, deployed and monitored like any application managed by the DevOps methodology.

Move To Serverless

Serverless is not necessarily a component of DevOps culture. Nevertheless, its use brings many benefits and fits perfectly into this movement even if the management of such architecture requires processes sometimes different from other applications.

This type of architecture actually requires a greater involvement of developers in the life cycle management of the serverless application while reducing (without removing) the responsibility of operations to ensure its proper functioning.

This type of application therefore requires a good cohesion of teams in order to deploy and maintain the service in production. The simplicity of the architecture management of this type of infrastructure also makes it possible to accelerate the DevOps transformation of a process, workflow or application.

Continuously Learn

DevOps is a game changer every day, new tools, new processes, new ways of working, etc. So it’s important to keep your knowledge up to date or at least challenge what you’ve learned with the latest trends. This often allows you to find points of comparison and optimization in your daily work.

As explained at the beginning of this article, sharing is the key to success, so it is important to have a communication channel with all teams in order to share and exchange ideas or resources.

Keep In Mind That DevOps Is Not Just a Role

Over time, the interpretation and use of the word DevOps has evolved. Today, it has been democratized to define a role, a team (which can be paradoxical in itself), or even a part of the infrastructure. But we must remember that this is, above all, a way to review the working methodology of a company in order to promote communication between teams, the automation of recurring processes, the supervision of the entire infrastructure, the development of a flexibility culture in order to provide customers with an optimal user experience and thus stand out in an increasingly competitive market.

The DevOps methodology is therefore a current, a trend, a transition towards a new way of working more adapted to a new generation of work tools and, like any transition, it must have an end, not become a project with no end date.

Next?

As explained in this article, a transformation to DevOps methodology is not an end in itself, but the beginning of a long journey. The evolution of working methods brings us constantly new tools and processes to facilitate our daily tasks and foster our team collaboration.

DevOps has changed a lot of companies, teams, and people but is now challenged by a new practice called NoOps that introduces another way of thinking of collaboration and automation. But this will be for a future article, stay tuned!

About The Authors

Hicham Bouissoumer— Site Reliability Engineer (SRE) — DevOps

Nicolas Giron — Site Reliability Engineer (SRE) — DevOps