DevOps Journeys: Aymen El Amri

17/05/2017   DevOps Journeys  

As part of our DevOps Journeys series, we spoke to Aymen El Amri, DevOps community leader and independent Cloud/Software Architect, about his experiences with DevOps.

You can read the full DevOps Journeys e-Book here

If you'd like to contribute to the next DevOps Journeys e-Book or would like to provide an interview on your DevOps Journeys, please get in touch with us, we'd love to hear it!

What does DevOps mean to you?

DevOps is a culture that requires some practices and a new vision with a common goal of unifying people and departments around unique goals by establishing the right communication process and a cross-functional collaboration.

One of this culture characteristics is being customer-oriented: Being focused on customers is the best way to align teams towards the same valuable goals without creating an inter-department war.

Adopting DevOps needs the right process done by the right people using the right tools.

Like in the lean methodology, DevOps has an iterative approach towards success, that's why continuous amelioration, followed by measurements then feedback is a healthy mechanism that stimulates productivity and helps people focus on the real problems.

There are many DevOps topologies and each organization may adapt differently DevOps to its specific need and context but the Dev and Ops collaboration is the most common practice and this collaboration needs some technical prerequisites like source control & revisions, infrastructure as code, routine automation, self-service configuration, automated builds, continuous integration and delivery, incremental testing & test-driven development.

Finally DevOps has a large scope that includes people, processes and technologies, there is no official manifesto that describes this culture but in my opinion, simplicity and iteration are the first steps to enter the DevOps gate.

What are the things that you see that people are still not getting right with DevOps?

People working on the DevOps transformation should be partners in the product design and engineering from the idea to the production but in many organizations, people consider DevOps as just a new word that describes the modern system administrator or the sysops engineer so DevOps engineers find themselves locked to work on a product that lacks operability, testability or scalability.

Not getting the approval of DevOps members in designing new features or products is simply heading in the wrong direction and falling back to a waterfall model, while DevOps is a reaction to the drawbacks of the waterfall model.

DevOps means more collaboration between development and operations teams and more agility but this doesn't mean that developers should manage production or have root access to production servers. System administrators know how to manage servers, developers know how to write code, DevOps should build the bridge between operations and development without impacting critical policies.

Let's take the example of a developer who wants to test a new feature against a production-like server, one can ask oneself how can he do it without having access to the same production server?

Self-service environments is a DevOps solution to this problem: The same production VM or container could be cloned by the developer.

In order to make this possible, both Dev and Ops teams should work on the configuration management.

A self-service environment is one of the DevOps bridge pillars and configuration management represents the collaboration aspect between cross-functional teams.

Finally, some people think that a DevOps transformation is the responsibility of ops/WebOps/DevOps teams only since many "DevOps-technologies" like Cloud Computing, Infrastructure As Service, Docker need some operational skills: This is another misconception.

Through my last example I wanted to highlight that in order to build the DevOps bridge, developers, managers and executives should collaborate and consider adapting the product to the configuration/change management.

What was the biggest mistake you made when starting out with DevOps?

DevOps is an exciting field with a lot of challenges like zero downtime deployment, self-healing and auto-scalability. Working on a DevOps transformation is being in connection with several teams within the same organisation and mastering several technologies.

Given this fast growing environment, the great number of tools, architectures and methodologies, I found solutions to many problems but I realised that I was doing some over-engineering and tried to solve simple problems with complicated solutions that some people in the same organisation couldn't really master or understand.

I think that many DevOps beginners are doing the same thing but I realised with time that simplicity is the key to DevOps transformations.

In order to stop doing over-engineering and even under-engineering, I simply compare the cost of improving a solution to its benefits.

My advice to DevOps beginners: DevOps should be neither over-engineered nor under-engineered. Don't settle for the simplest solution and don't find the perfect one but consider “right-engineering your transformation” and iterating improvements over your solutions.

Set up only what is needed, only when it is needed and only where it is needed.

DevOps has gone mainstream - is that a good thing?

Some years ago, when I worked on early DevOps projects I had to cope with difficult problems, (fantastic but) immature technologies and some misconceptions. But I was not alone, a growing community was working on similar problems, these people built the foundations and made possible the introduction of DevOps to all types of companies from startups to corporations.

DevOps was destined to move deeper into the mainstream since it is a natural and an expected reaction to older models that have worked out for a specific period but need a "refresh".

From a business point of view, DevOps decreases the time-to-market while creating stable and performant products: The marriage of product innovation and stability within the same organisation is possible with DevOps.

From a technical point of view, delivering high-quality software is a reward to everybody from Ops to QA to Dev teams.

However, going mainstream can ruin the thing we care about, this is what happened to proven frameworks like ITIL: technologists tends to forget about it since it became "too mainstream". But in reality, ITIL could co-exist within DevOps work environments and in my opinion, they should co-exist. In most cases, ITIL practitioners are more likely to build better and efficient DevOps bridges.

We should not forget that DevOps takes many of its principles from lean and agile methodologies that became mainstream but this doesn't mean that they are obsolete nowadays.

How should we measure the success of DevOps?

One of the things that I like about DevOps is continuous measurement.

Like in a lean process, DevOps operates in a similar model: Build -> Measure -> Learn.

Measuring DevOps success is a must, I think that everybody is ok with this assertion, but the way we measure it could be different from one team to another one and there is no unique way to do it.

DevOps - in my opinion - should have a flexible framework and should be adapted to people first then technologies, processes, management and customers, so every organisation has different metrics to measure.

However, a good flow could be described in simple 4 steps:

  1. Set a short development cycle after which software should be delivered in a stable release (this period could start with 2 weeks to reach daily and continuous delivery).
  2. During each cycle, pick out the metrics you can measure
  3. Measure these metrics at the end of each cycle and share your feedback with all of the stakeholders
  4. Iterate over this, fix your next cycle metrics but do not forget the old ones because regressions could happen.

To ensure you are measuring DevOps success correctly, follow these recommendations:

  • Make sure people working on DevOps are partners of the product engineering and design. DevOps teams should understand the "why" (not only the "how" of the developed product) in order to be able to choose the right metrics.
  • Shorten your development cycles. The shorter is the development cycle, the better the measurements are meaningful and efficient to better anticipate the success or the failure of the currently developed features, but beware of surpassing your current capabilities: shortening development cycles is a result of continuous improvements, not an instant gratification.
  • Be transparent.

What are your predictions for the future of DevOps?

Containers and container orchestration adoption are growing within the DevOps community, not only because it was a buzz word during the last years but because these technologies have now been proven to help to deliver better software. This will impact current DevOps topologies and gives more support and value to container-driven collaboration as well as distributed systems architectures.

This change will be accompanied by other changes in the way we create software like Microservices, networking models like SDN (software-defined networking) and more use of serverless technologies and FaaS (Function as a Service).

Microservices (or breaking down a monolithic application into small containerized services that are easier to develop, manage, and scale independently) will be more adopted during 2017 so new practices will raise whether it's for team management, development, architecture, delivery, integration or networking.

As to serverless computing, it is not yet a mainstream technology but I imagine that it will be one of the most important changes in the DevOps community by the end of 2017, technologies like AWS Lambda, containers like Docker, orchestration tool like Kubernetes and a bunch of serverless development frameworks will make this change reasonable.

2017 will be a big year for machine learning and artificial intelligence application to solve real-world problems.  I think that DevOps is what can make this kind of "scientific projects" open to the public.

I recently met a founder of a voice-based AI startup and discovered how much they need someone that could build and automate their software factory in order to deliver a usable and testable product of their prototype to the real world.

Improving the development of software that supports scientific projects is a must for AI startups to be competitive and reach more satisfied customers - that's why "ResearchOps" will be more in demand during 2017.

Finally, the fact that DevOps has gone mainstream will increase the focus of CEOs on DevOps metrics and success. Organisations will give more value to these metrics and more serious efforts will be done in this way while DevOps will continue to cover more other classic fields in the organisation that have been already adopted within the DevOps community like ChatOps, DevSecOps, DevQAOps and also IoT.

With a broad technical background from development to operations, Aymen has diversified work experiences, a proven understanding of software development, cloud engineering and combining strategic and technical thinking.

He helps companies and startups develop modern & scalable applications, build multi-tenant cloud infrastructures, stable production environments, distributed systems and service oriented architectures.

Aymen has written several books, including SaltStack For DevOps & Painless Docker, and is the creator of, a global community of thousands of IT experts and DevOps enthusiasts.