500 days in Devops | Thoughts
Development operations, a term that is unheard of outside of the software industry. You present yourself as a sysadmin or a software engineer to your family and friends. Correspondingly you tell them that you manage big servers and deploy applications on top of it.
Likewise Devops people don't know what to call themselves. A reason for that is the absence of a manifesto or a concise definition. As a practice it is still emerging and universities are catching up.
If you think about it, the world's been moving so fast these past few years to the point that it made software so pluggable to cope with this ever evolving cycle.
People have been doing devops before there was even a term for that. It all started with automation, to stand out as a framework that shifts company's entire management and technical operations.
It's been a year and a half since i joined this world of wonders, i thought it would be nice to reflect on what i did and how much i evolved since the first time i issued this command:
docker run -it --rm busybox
Come to think of it, I've never accumulated such knowledge in a short period of time in my entire life. You constantly had to learn and stay on top of the game.
For instance, There was a time i went to the office at 6 o clock, we had no pressing matters, i just wanted to benefit from the silence around to learn few things. I'm at the office and 5 minutes later, a fellow teammate came and he was surprised to see me there, here comes another one, and by 6:30 the whole devops team was working already.
It's the discipline this field engraves in you. This is one of those jobs that not everyone can do. It requires a lot of baldness as you attempt to migrate that database in production, and a trial and error mindset.
When people call out your name, it's either a big problem or a big feature.
We had people that didn't last a week. They show you all the convictions and excitement to join your ranks. Conversely, they quit once confronted with the reality of things.
In fact, you have a small margin for error. Likewise, once you set sail you never go back, no starting again from scratch. I can't stop bitching about the added value to an individual while working in production. It's like having a baby, once it leaves the cradle, it is never going back. Consequently, responsibility weighs over your shoulders.
Nevertheless, the fruits of your hard labor show off quickly. You identify as the guy who grants access to assets, your absence is noticeable and once you get going you benefit from a lot of RAM & CPU.
I always loved that, you can experiment and deploy production grade applications in seconds.
I had a particular learning curve that made me tackle this discipline with joy and understanding, from electronics to software security and finishing my engineering degree with an internship in devsecops.
The term was non existent a year ago in my country. I insisted on getting that role even though my colleagues used to joke about how hard it was to pronounce let alone understand.
In this situation, HR kept referring to me as a software engineer. That didn't stop me from moving forward and insisting on keeping the DevSecOps title.
For me security has been a mindset, i didn't have to work as a security officer to implement it. It is a functional requirement in everything i do.
An unpleasant experience, working with companies that values speed over stability. The people around me didn't seem to care about it, wouldn't allocate time for it. Like any other feature in the products, for them it's a todo in their backlog like a crud or a dashboard implementation, which would never work.
Assuredly, GDPR hit the industry, and they found themselves obligated to rethink security , at a time where it was too late.
Mid year i received an invitation to teach devsecops at a university. The head of department who offered me this position was very enthusiastic. Unluckily, the university didn't share the same perspective so we abandoned the idea.
From there i diverged back to claiming the title of a devops consultant in a different company, i never spoke of security but i embodied it as a subset of Devops. I kept studying it, implementing it whenever i had the chance without highlighting it to my superiors. Enforcing it would be a meaningful term here.
I dived alone, with no stack-overflow to find answers, i had to read books and scientific articles. Scrap isolated blogs like mine to find material.
It all started with docker, we were doing micro-services, we didn't have Kubernetes at the time and we were deploying applications using swarm and compose.
Navigating my way through a pile of technologies, fixing bugs in an authentication service at three am on a Sunday to continue deploying the application and verifying it works as expected, gave me a holistic view of the software realm.
If they wanted to deploy a MongoDB instance, i had to configure it, deploy it, open a shell, learn how to connect to it, find out how to add users and operate a database from the terminal.
I have to do that with every technology in our stack. It may sound overwhelming, nevertheless, once you get on your feet, it becomes easier and the patterns collide.
Peel off the fancy marketing and personalized usage, everything that works on the internet shares the same principles and set of protocols. Once you get to that level, you go like ooh so that uses that and it works this way. You start imagining a maze and you're just finding your way out.
You get forced to understand how everything works, since you're the only person who knows how to navigate your way through a k8s cluster or between docker containers. Witch gives you a unique position as a Bridge between various teams. You can discuss ideas with developers, sysadmins, security officers and even management and HR.
You begin to automate workflows and on/off-boarding processes, making you fit in every department.
At the same time, the absence of a concise definition, makes everything your job, a bug in someone's code that returns an HTTP error, "devops, check our internet connectivity".
Everyone is over your shoulders when the servers goes down, when the cluster becomes unavailable. If they want to use git frameworks, you're the one they call.
Developers will only care about bringing the baby to life. Whereas you have to nourish it and stay up all night to make sure it has everything it needs.
Your typical job would be to review code, find out how it works and what it needs to be running, prepare a pipeline that represents the application's life cycle, from all sorts of tests, to building artifacts and deploying to staging and production environments.
You have to deploy and maintain every technology you use in the company, ranging from Gitlab, Jenkins, Ldap, nexus and all the various projects your team is working on.
You become a sysadmin, a database administrator, a networking engineer, a security officer, and a developer all in the same time.
Things become overwhelming and you start looking at tools to help you do your job more efficiently. How about prometheus and grafana to check the health of my cluster. Maybe weavescope to draw a topology of my complex gigantic computer. Istio to enforce seamless networking rules...
You become the orchestrator of an orchestration system.
After a while your teammates will reach out to you for advice on how to tackle a problem, design systems or what technologies to use.
In contrast, I still think that devops should be considered as a framework that every member of the organization can have a role in.
Generally speaking, everyone has to learn how to build containers, write Jenkinsfiles and deploy applications to production.
A typical developer in today's world doesn't know the types of artifacts he's generating nor what would happen when the database crashes.
That's the gap that many big names in the industry are trying to fill. witch resulted in the emergence of things such as gitops and cloud-native.
All things considered, i enjoy my work and the value it brings to the world. Other than sitting on a desk the whole day, i rarely felt boredom or routine.
Every new dawn is a mystery.
Likewise Devops people don't know what to call themselves. A reason for that is the absence of a manifesto or a concise definition. As a practice it is still emerging and universities are catching up.
If you think about it, the world's been moving so fast these past few years to the point that it made software so pluggable to cope with this ever evolving cycle.
People have been doing devops before there was even a term for that. It all started with automation, to stand out as a framework that shifts company's entire management and technical operations.
It's been a year and a half since i joined this world of wonders, i thought it would be nice to reflect on what i did and how much i evolved since the first time i issued this command:
docker run -it --rm busybox
Come to think of it, I've never accumulated such knowledge in a short period of time in my entire life. You constantly had to learn and stay on top of the game.
For instance, There was a time i went to the office at 6 o clock, we had no pressing matters, i just wanted to benefit from the silence around to learn few things. I'm at the office and 5 minutes later, a fellow teammate came and he was surprised to see me there, here comes another one, and by 6:30 the whole devops team was working already.
It's the discipline this field engraves in you. This is one of those jobs that not everyone can do. It requires a lot of baldness as you attempt to migrate that database in production, and a trial and error mindset.
When people call out your name, it's either a big problem or a big feature.
We had people that didn't last a week. They show you all the convictions and excitement to join your ranks. Conversely, they quit once confronted with the reality of things.
In fact, you have a small margin for error. Likewise, once you set sail you never go back, no starting again from scratch. I can't stop bitching about the added value to an individual while working in production. It's like having a baby, once it leaves the cradle, it is never going back. Consequently, responsibility weighs over your shoulders.
Nevertheless, the fruits of your hard labor show off quickly. You identify as the guy who grants access to assets, your absence is noticeable and once you get going you benefit from a lot of RAM & CPU.
I always loved that, you can experiment and deploy production grade applications in seconds.
I had a particular learning curve that made me tackle this discipline with joy and understanding, from electronics to software security and finishing my engineering degree with an internship in devsecops.
The term was non existent a year ago in my country. I insisted on getting that role even though my colleagues used to joke about how hard it was to pronounce let alone understand.
In this situation, HR kept referring to me as a software engineer. That didn't stop me from moving forward and insisting on keeping the DevSecOps title.
For me security has been a mindset, i didn't have to work as a security officer to implement it. It is a functional requirement in everything i do.
An unpleasant experience, working with companies that values speed over stability. The people around me didn't seem to care about it, wouldn't allocate time for it. Like any other feature in the products, for them it's a todo in their backlog like a crud or a dashboard implementation, which would never work.
Assuredly, GDPR hit the industry, and they found themselves obligated to rethink security , at a time where it was too late.
Mid year i received an invitation to teach devsecops at a university. The head of department who offered me this position was very enthusiastic. Unluckily, the university didn't share the same perspective so we abandoned the idea.
From there i diverged back to claiming the title of a devops consultant in a different company, i never spoke of security but i embodied it as a subset of Devops. I kept studying it, implementing it whenever i had the chance without highlighting it to my superiors. Enforcing it would be a meaningful term here.
I dived alone, with no stack-overflow to find answers, i had to read books and scientific articles. Scrap isolated blogs like mine to find material.
It all started with docker, we were doing micro-services, we didn't have Kubernetes at the time and we were deploying applications using swarm and compose.
Navigating my way through a pile of technologies, fixing bugs in an authentication service at three am on a Sunday to continue deploying the application and verifying it works as expected, gave me a holistic view of the software realm.
If they wanted to deploy a MongoDB instance, i had to configure it, deploy it, open a shell, learn how to connect to it, find out how to add users and operate a database from the terminal.
I have to do that with every technology in our stack. It may sound overwhelming, nevertheless, once you get on your feet, it becomes easier and the patterns collide.
Peel off the fancy marketing and personalized usage, everything that works on the internet shares the same principles and set of protocols. Once you get to that level, you go like ooh so that uses that and it works this way. You start imagining a maze and you're just finding your way out.
You get forced to understand how everything works, since you're the only person who knows how to navigate your way through a k8s cluster or between docker containers. Witch gives you a unique position as a Bridge between various teams. You can discuss ideas with developers, sysadmins, security officers and even management and HR.
You begin to automate workflows and on/off-boarding processes, making you fit in every department.
At the same time, the absence of a concise definition, makes everything your job, a bug in someone's code that returns an HTTP error, "devops, check our internet connectivity".
Everyone is over your shoulders when the servers goes down, when the cluster becomes unavailable. If they want to use git frameworks, you're the one they call.
Developers will only care about bringing the baby to life. Whereas you have to nourish it and stay up all night to make sure it has everything it needs.
Your typical job would be to review code, find out how it works and what it needs to be running, prepare a pipeline that represents the application's life cycle, from all sorts of tests, to building artifacts and deploying to staging and production environments.
You have to deploy and maintain every technology you use in the company, ranging from Gitlab, Jenkins, Ldap, nexus and all the various projects your team is working on.
You become a sysadmin, a database administrator, a networking engineer, a security officer, and a developer all in the same time.
Things become overwhelming and you start looking at tools to help you do your job more efficiently. How about prometheus and grafana to check the health of my cluster. Maybe weavescope to draw a topology of my complex gigantic computer. Istio to enforce seamless networking rules...
You become the orchestrator of an orchestration system.
After a while your teammates will reach out to you for advice on how to tackle a problem, design systems or what technologies to use.
In contrast, I still think that devops should be considered as a framework that every member of the organization can have a role in.
Generally speaking, everyone has to learn how to build containers, write Jenkinsfiles and deploy applications to production.
A typical developer in today's world doesn't know the types of artifacts he's generating nor what would happen when the database crashes.
That's the gap that many big names in the industry are trying to fill. witch resulted in the emergence of things such as gitops and cloud-native.
All things considered, i enjoy my work and the value it brings to the world. Other than sitting on a desk the whole day, i rarely felt boredom or routine.
Every new dawn is a mystery.
Comments
Post a Comment