As many of you may know, DevOpsLinks was one of the sponsors of DevOpsDays Cuba. It was a good opportunity to meet interesting people: organizers, speakers and attendees.

As a topic for my keynote speech, I wanted to talk about DevOps engineers and DevOps teams, the contradiction between “DevOps” position and the DevOps philosophy.

Nowadays, if you love working with technologies like containers, orchestrators and cloud computing, you will find yourself working as a DevOps engineer in most cases.

But even if you’re not okay with the position name, you still love what you do. You’ll actually feel a crisis of identity, when you realize that something is wrong.

I talked also about DevOps teams and the wall of confusion that this topology could create between DevOps teams and other teams .. but according to the survey made by Puppet Labs called the “State of DevOps”:

  • 16% of respondents identified themselves as working in DevOps teams in 2014
  • 19% in 2015
  • 22% in 2016
  • The percentage reached 27% in 2017

90% of these teams are working in medium and high-performing IT organizations !

Even with the paradoxes and the limitations of creating a dedicated DevOps team, the numbers show that it’s working in most cases and this fact is increasing and being adopted by more companies.

Implementing DevOps in all teams could come with costs and risks, especially for big companies — that’s why some companies made the choice of creating a DevOps team to bootstrap this culture — this team will act like a catalyst for change.

The IT industry adopted a different model from the vision of most of us. As an engineer and a DevOps practitioner, my role is solving problems and optimizing processes without impacting the stability of a business. This is what I tried to do through my presentation.

That’s why I talked about the different skills a DevOps engineer/team should have and among the solutions there is setting up standards within an organization.

This will help people see and touch practical goals and norms otherwise everyone will be stuck in his own point of view.

For this presentation, I tried to find a good approach to this standardization and I came out with 15 factors:

  • Embrace the DevOps Culture
  • Environment Isolations & Dev/Prod Parity
  • Anything as a Service
  • Use Cloud Computing
  • Use Containers
  • Automate Everything
  • Build Microservices
  • Create Business Capability Teams & Deploy Business Services
  • Build API-First Products
  • Explicitly Isolate & Define Software Dependency
  • Externalize Configurations
  • Create Immutable Infrastructures & Artifacts
  • Stream Logs
  • Build Light & Business-Oriented Services
  • Use Health Checks & Create Self-healing System

My presentation will be detailed in another blog post, but you can find the slides here.

In the DevOps Institute Continuous Chit Chat podcast “Continuous ChitChat Ep. 8 — DevOpsDays Cuba, What’s Next?”, Manny Varela and Mike Rosado stop by to tell Alan and Jayne about their DevOpsDays Cuba experience.

You can also find the list of speakers and each speaker slides in the official website.

Here is a list of some of the slides:

The event was not only rewarding from a technical point of view but also the human side, I’ve met interesting people and I’ll absolutely keep good souvenirs from this experience.

Other blog posts to read about DevOpsDays Cuba:

Connect Deeper

If you liked this article, join DevOpsLinks to get similar content in your inbox and if you are looking for new DevOps opportunities, you can join Jobs For DevOps and share your CV with the existing recruiting companies.

Leave a Reply

Your email address will not be published. Required fields are marked *