Skip to main content Skip to Footer

BLOG


August 15, 2019
DevOops
By: Mario Lamas

Pop quiz! Which of the following do you have in your company/project/team?

  • A log aggregator (ELK maybe?) with log lines defined by development which are unknown to operations
  • A development team, infrastructure team and an operations team that do not know each other (or what they even do)
  • A Jenkins server with pipelines that only specific people can access and edit
  • A pipeline with defined quality gates that are set as passthrough

If you said yes to any of the above, unfortunately, you are not doing DevOps. Most likely, you are just trying to convince yourself (and your leadership) that you are. But let’s be honest, who is entirely doing DevOps?



Lately I’ve been realizing that DevOps teams and efforts are highly, shiny-object-driven. These sparkly objects are usually tools such as Jenkins, Docker, cloud or Selenium, powered by Agile to create a Frankenstein’s monster kind of system that the IT department will call “DevOps” when presenting the approach to the leadership. This Agile creature becomes a chimera that will deliver features and functionalities rapidly to the customer! Bug fixing? Clearly! No more than 1 hour into production operations? Sure! Kubernetes controls high availability and restores itself and so many other sets of utopic scenarios that we all want to achieve.

Think about whether you’ve been in this situation before. IT usually ends up with this spaghetti plate of tools that the company wants you to use because they’re all claimed to be best of the best in their field. The tools are aligned and enabled via Jenkins pipelines, and there you go! DevOps for your organization! Or more like Dev …Oops …

As I mentioned before, projects and organizations tend to focus on having the latest top-notch tools and call it DevOps. But that is not what it is about. Yes, having tools that allow an organization to reach its goals is good, but tools become useless if they’re not aligned to a strategy that will support the product and the business needs.

Put another way, imagine this amazing pipeline that has all the features that you’d expect: code quality inspections, functional testing, security scans, automatic deployments, etc. But there is no distribution list for the development team to receive an alert when code quality is not achieving the expected level, security scans are set as passthrough generating a report that no one is paying attention to, or once your code is in production, a sev1 comes up and service support is trying to debug, but they have no idea what the logs mean. Picture Bruce from support who was woken up at 2:35 AM, reading a log line that says “KRN – 0598: Error found, transaction can’t complete.” I’m sure Bruce will be grumpy the next day.

With the previous example, I hope it is clear that DevOps is not exactly a person, a role or a specific team. It is more of a cross-functional practice that makes its best attempt to fill in the gaps across areas. Recently DevOps has evolved to DevSecOps and if we want to be explicit it would be more like DevTestSecOps. But then you are missing on non-functional aspects, so it might as well be DevQaSecOps, and all this needs to be aligned with the business needs, so how do you feel about BizDevQaSecOps? I know, it sounds awful and it is hard to read but this is what we should be striving for.



There are misconceptions that the industry is having about what DevOps is. Some people think it is a role (with some calling it SRE), some others see it as a skill. Some think it is a set of tools, while others believe it to be IT support. I personally think it is more of a practice, a way of working that involves cross-functional teams and good team communication, leading to the ability to have technical representatives during product definition phases.

Is DevOps an extension of Agile? A tool for Agile? Perhaps, Agile 2.0? I will cover this in a future post.


DOWNLOAD VIDEO TRANSCRIPT [PDF]

Popular Tags

    More blogs on this topic

      Archive