Is there life in the pipelines?

Under the streets of London there's a place most people could never even dream of. A city of monsters and saints, murderers and angels, knights in shiny armor and pale girls in black velvet. This is the city of the people who have fallen between the cracks.[1]

This is the short description of the book "Neverwhere" by Neil Gaiman. I've read it long time ago and I really liked it. I don't remember the book well, but I remember this short description and it had an impact on me, both at the time when I was starting to read the book, and now, when I think of it. Neil Gaiman is one of my favorite writers and I think his imagination is really something, out of this world perhaps. This quote from above will not be a preface to the review of his book, nope. It will be a sum up story and a description of how I see the world of DevOps. I will use this quote to give DevOps another, a bit fantasy, note.

DevOps is the thing we can't actually see - "Under the streets... a place most people could never even dream of..." It is there, or at least it should be there, and it cannot be seen with the naked eye. Those things, although somewhat and sometimes invisible are present and exist, and those things are - people, processes and tools.

And this is where we kind of part our ways from the quote at the beginning. I just wanted to emphasize the fact that DevOps is often not seen, not one thing, or just a role in the team, it is much more, a city full of various, interesting and sometimes breathtaking things, things that we're not aware of, at least most of the time.

So what is exactly DevOps? In essence, and forgive me if I repeat the same things as many resources online - it is a combination of development (Dev) and operations (Ops) - DevOps is the union of people, process, and technology to continually provide value to customers. And yes, the goal of this somewhat unseen world is to provide value to people that have some interest in the product we are creating, end-users. [2]

How do we provide those values? First, by implementing processes which will make sure that the flow is continuous, from defining the things to be built (requirements), building of those things (development), and making those things available to the end users (operations). Next is by creating feedback loops from end users or the application itself (right) to the team (left) about changes that need to be done, improvements, bugs, etc. And last, but not the least - by adopting the culture that empowers continual learning, experimentation and learning from failure.[3]

I admit, the above line is a mouthful. But let's see it in practice - let's see how the day in life of a DevOps engineer (yes, I said it) looks like.

TL;DR - many things to take care of and to think about.

The longer version - I usually start my day with a cup (or a bottle) of tea, then quickly go through... Just kidding, I'm not going to write here about my daily routine, at least not yet...

If you didn't guess it by now - I am working as a DevOps engineer, and here is an outline of some sorts - my main tasks on projects are to make developed applications available to the end user. How I do that? By setting up the processes and pipelines for building, testing, and deploying the application(s) to the adequate environment - this is the processes part. Those processes are automated with the appropriate tools, depending on the process, we use different tools - and you guessed it, this is the tools part. Do I do this alone? No - the whole team is involved in creating and automating certain part(s) of the process(es), experimenting with different ones, learning from failed ones, and keeping those chosen up to date - and this is the part of the DevOps that is related to people and continuous experimentation and learning.

Some, I specifically say some, of the processes and practices include Continuous Integration, Continuous Delivery or Continuous Deployment. Usually, we (the DevOps engineers) in collaboration with developers setup the CI pipelines, and (later) CD pipelines, make sure that the infrastructure for different application stages (development, test, production) is available, is similar if not the same to one another, and easily ready and re-deployed if something goes south. And what if something goes south? One thing to remember is that this will definitely happen at some point, but that shouldn't be the problem, because that is how we learn.

Now the tools part. This is the thing that is the most confusing and often thought of as the only part of DevOps. Well, it is a part, not the only one for sure. We have a plethora of different tools for each part of the process, and yes - there is not one tool to rule them all - meaning - it is not often seen that people are using only one tool to accomplish all of the things (yes, I'm looking at you bash). The thing is to use all of these tools in combination which will have most sense and be the simplest one for you. Usually, the simplest solution is the best one.

There is also somewhat new(er) concept of DevOps platforms... What is the deal with them? They are there to make our life easier (or at least that is their selling point), by providing us one location where we can easily configure all of our project needs. Don't get me wrong, I don't have anything against them, they are quite useful, if you know what you are doing and what are your needs. I'm quite fond of some of them to be honest. The thing to remember here is - there are no best platforms or combination of tools, there are only those that are the most suitable for you and your project.

To wrap this up, there isn't only one way of doing almost anything in the world, not even DevOps. You just need to think of it as a combination of people, processes and tools and treat it in that sense, not only tools, or processes. The whole combination of all of these three things needs to be present. I like the whole DevOps culture, state of mind, for what it represents - tearing down the barriers between different roles. I like living in these pipelines, not seen by the naked eye. To go a bit further, you can even think of yourself as some kind of a ninja turtle...

Footnotes


  1. https://www.goodreads.com/book/show/14497.Neverwhere ↩︎

  2. https://azure.microsoft.com/en-us/overview/what-is-devops/#devops-overview ↩︎

  3. https://itrevolution.com/the-three-ways-principles-underpinning-devops/ ↩︎