Skip to content

DevOps

DevOps is a set of practices that combines software development (Dev) and information-technology operations (Ops) which aims to shorten the systems development life cycle and provide continuous delivery with high software quality.

One of the most important goals of the DevOps initiative is to break the silos between the developers and the sysadmins, that lead to ill feelings and unproductivity.

It's a relatively new concept, the main ideas emerged in the 1990s and the first conference was in 2009. That means that as of 2021 there is still a lot of debate of what people understand as DevOps.

DevOps pitfalls⚑

I've found that the DevOps word leads to some pitfalls that we should try to avoid.

Getting lost in the label⚑

Labels are a language tool used to speed up communication by describing someone or something in a word or short phrase.

However, there are times when labels achieve the complete oposite, as it's the case with DevOps, where there are different views on what the label represents and usually one of the communication parties strongly feels they belong to the label while the other doesn't agree. These discussions can fall into an unproductive, agitated semantic debate where each part tries to convince each other.

So instead of starting a twitter thread telling people why they aren't a DevOps team, we could invest those energies in creating resources that close the gap between both parties. Similarly, instead of starting an internal discussion of what do we understand as DevOps?, we could discuss how to improve our existent processes so that the team members feel more comfortable contributing to the application or infrastructure code.

You need to do it all to be awarded the DevOps pin⚑

I find specially harmful the idea that to be qualified as DevOps you need to develop and maintain the application at the same time as the infrastructure that holds it.

To be able to do that in a typical company product you'll need to know (between another thousand more things):

  • How to operate the cloud infrastructure where the project lives, which can be AWS, Google Cloud, Azure or/and baremetal servers.
  • Deploy new resources in that infrastructure, which probably would mean knowing Terraform, Ansible, Docker or/and Kubernetes.
  • How to integrate the new resources with the operations processes, for example:
    • The monitoring system, so you'll need to know how to use Prometheus, Nagios, Zabbix or the existent solution.
    • The continuous integration or delivery system, that you'll need to know how to maintain, so you have to know how it works and how is it built.
    • The backup system.
    • The log centralizer system.
  • Infrastructure architecture to know what you need to deploy, how and where.
  • To code efficiently in the language that the application is developed in, for example Java, Python, Rust, Go, PHP or Javascript, in a way that meets the quality requirements (code style, linters, coverage and documentation).
  • Knowing how to test your code in that language.
  • Software architecture to structure complex code projects in a maintainable way.
  • The product you're developing to be able to suggest features and fixtures when the product owner or the stakeholders show their needs.
  • How to make the application user friendly so anyone wants to use it.
  • And don't forget that you also need to do that in a secure way, so you should also have to know about pentesting, static and dynamic security tools, common security vulnerabilities...

And I could keep on going forever. Even if you could get there (and you won't), it wouldn't matter, because when you did, the technologies will have changed so much that you will already be outdated and would need to start over.

It's the sickness of the fullstack developer. If you make job openings with this mindset you're going to end up with a team of cis white males in their thirties or forties that are used to earn 3 or 4 times the minimum salary. No other kind of people can reach that point and hold it in time.

But bare with me a little longer, even if you make there. What happens when the project changes so that you need to:

  • Change the programming language of your application.
  • Change the cloud provider.
  • Change the deployment system.
  • Change the program architecture.
  • Change the language framework.

Or any other thousand of possible changes? You would need to be able to keep up with them. Noooo way.

Luckily you are not alone. You are a cog in a team, that as a whole is able to overcome these changes. That is why we have developers, sysadmins, security, user experience, quality, scrum master and product owners. So each profile can design, create, investigate and learn it's best in their area of expertise. In the merge of all that personal knowledge is where the team thrives.

DevOps then, as I understand it, is the philosophy where the developers and sysadmins try their best to break the barriers that separate them. That idea can be brought to earth by for example:

  • Open discussions on how to:
    • Improve the development workflow.
    • Make developers or sysadmins life easier.
    • Make it easier to use the sysadmin tools.
    • Make it easier to understand the developers code.
  • Formations on the technologies or architecture used by either side.
  • A clear documentation that allows either side to catch up with new changes.
  • Periodic meetings to update each other with the changes.
  • Periodic meetings to release the tension that have appeared between them.
  • Joined design sessions to decide how to solve problems.

Learn path⚑

DevOps has become a juicy work, if you want to become one, I think you first need to get the basic knowledge of each of them (developing and operating) before being able to unlock the benefits of the combination of both. You can try to learn both at the same time, but I think it can be a daunting task.

To get the basic knowledge of the Ops side I would:

  • Learn basic Linux administration, otherwise you'll be lost.

  • Learn how to be comfortable searching for anything you don't know, most of your questions are already answered, and even the most senior people spent a great amount of time searching for solutions in the project's documentation, Github issues or Stackoverflow.

    When you start, navigating this knowledge sources is hard and consumes a lot of your life, but it will get easier with the time.

  • Learn how to use Git. If you can, host your own Gitea, if not, use an existing service such as Gitlab or Github.

  • Learn how to install and maintain services, (that is why I suggested hosting your own Gitea). If you don't know what to install, take a look at the awesome self-hosted list.

  • Learn how to use Ansible, from now on try to deploy every machine with it.

  • Build a small project inside AWS so you can get used to the most common services (VPC, EC2, S3, Route53, RDS), most of them have free-tier resources so you don't need to pay anything. You can try also with Google Cloud or Azure, but I recommend against it.

  • Once you are comfortable with AWS, learn how to use Terraform. You could for example deploy the previous project. From now on only use Terraform to provision AWS resources.

  • Get into the CI/CD world hosting your own Drone, if not, use Gitlab runners or Github Actions.

To get the basic knowledge of the Dev side I would:

  • Learn the basics of a programming language, for example Python. There are thousand sources there on how to do it, books, articles, videos, forums or courses, choose the one that suits you best.

  • As with the Ops path, get comfortable with git and searching for things you don't know.

  • As soon as you can, start doing small programming projects that make your life easier. Coding your stuff is what's going to make you internalize the learned concepts, by finding solutions to the blocks you encounter.

  • Publish those projects into a public git server, don't be afraid if you code is good enough, it works for you, you did your best and you should be happy about it. That's all that matters. By doing so, you'll start collaborating to the open source world and it will probably force yourself to make your code better.

  • Step into the TDD world, learn why, how and when to test your code.

  • For those projects that you want to maintain, create CI/CD pipelines that enhance the quality of your code, by for example running your tests or some linters.

  • Once you're comfortable, try to collaborate with existent projects (right now you may not now where to look for projects to collaborate, but when you reach this point, I promise you will).