"Hello World"Ā š
Here we are, at the start of what I hope will be the first of many articles talking about my journey, not only as a DevOps engineer, but also as Developer.
Like many others in this field, I never dreamed of becoming a DevOps Engineer (and a Technical Lead, on top of it, but I don't want to brag about that š), but the path here was inevitable, almost like solving a puzzle I didn't know I had been assembling all along. š§©
Nobody Dreamed of Becoming a DevOpsĀ Engineer
Let's be honestā-ānobody dreamed of becoming a DevOps engineer when they were a child š.
When I first began my journey in tech, DevOps wasn't even on my radar. My love for tech started when I learned my first "programming" language: HTML (pun intended) š
. At the time, it felt like programming, and the thrill of building my first web page was unmatched. As a kid, I was amazed about what can be rendered from a simple HTML and a bit of CSS š®.
But as I moved from static web pages to dynamic applications, things started to shift.
I began learning backend development, starting with PHP, then expanding into more structured programming languages like Pascal, C++, C# (Pascal? I already feel like a fossil by just saying that word š).
This opened doors to full-stack development, allowing me to work on both the frontend and backend of applications. But as my applications grew, so did the need to deploy them efficiently. That's when I stumbled into the world of pipelines, CI/CD, and cloud infrastructure management.
Suddenly, managing deployments manually wasn't enough. I needed to automate processes, manage infrastructure effectively, and deliver code seamlessly. This realization pushed me toward DevOpsā-āand once I discovered the power of automations, I was hooked to it. āļøš»āļø
PS: C# is still my #1 programming language. š
Whenever I have some spare time I still play, experiment or implement something new with it. Why not!?? š
Why DevOps? The Power of Automation
For me, DevOps was all about automation. āļøāļø I've never been a fan of ClickOpsā-āthe process of manually managing infrastructure through web portals. Clicking through the Azure portal to configure resources felt repetitive and draining, not to mention prone to human error. Every task I repeated manually seemed like a waste of time and energy. That's when the allure of DevOps clicked.
Automating infrastructure and deployments allowed me to focus on what really matteredā-ādelivering value quickly and efficiently. DevOps gave me the tools to streamline repetitive tasks, reduce errors, and scale infrastructure effortlessly. Automation was, and still is, my main driver in this space. š
Avoid the trap of trying to automate every tiny detail, as it can lead to losing sight of what's truly important. Attempting to automate the last 20% of processes may consume 80% of your time and energy, potentially derailing your overall progress.
PS: I'll tell you in another article about how lazy I am and how that thing drove to build an entire ecosystem of applications and services to automate tasks, saving me 1 MILION clicks and likely an equal amount of Ctrl + C / Ctrl + V actions. š„“šµ
Some of you might have already guest what this could be about, but Stay Tuned!
The DevOps Toolbelt: CLI, Scripting and Pipelines
One of the most exciting aspects of being a DevOps engineer is the variety of tools at your disposal. Whether you're automating infrastructure, managing deployments, or integrating security into your pipelines, you need a robust toolbelt to get the job done.
CLI Tools
As a DevOps engineer, you'll become best friends with command-line interfaces. From managing infrastructure with Terraform to interacting with cloud services through Azure CLI or AWS CLI and why not GitHub CLI, everything revolves around the command line. Automating these interactions is where the magic happens.
Sometimes, to be honest, CLIs can feel like an uphill battleā-āthey can be daunting foes, especially when you're learning their quirks. But hey! There's always room for improvement everywhere.
Scripting
Knowing how to script is the bedrock of DevOps. Whether it's PowerShell, Bash or Python (did I really said that!? Pythonā¦ šØ), scripting gives you the freedom to customize and automate just about anything. Think about those repetitive tasks that slow down your day-to-day operationsā-āscripting can automate them away. For example, using PowerShell to configure environments or Bash to manage server tasks saves you hours of manual work. It's not just a time-saver; scripting offers flexibility to solve unique problems that a simple GUI can't address. You'll soon realize that scripts aren't just for local tasksā-āthey're a vital part of CI/CD pipelines as well.
However, this doesn't mean you're limited just to scripting languages. For an instance, I'd like to see all my automations written in C# one day. Whether it's implementing functionalities in Terraform or CI/CD pipelines, you can use too C# for various tasks. There's a whole horizon.
CI/CD
Don't be afraid to use scripts in your CI/CD pipelines; and I'm telling you this because I was... I really was "afraid" to use scripting for a reason I cannot remember.
In fact, many aspects of continuous integration and delivery rely on scripting, from custom build steps to deployment automation. Tools like Jenkins, GitHub Actions, and Azure Pipelines allow you to embed your scripts directly into the pipeline or run them from separate files, giving you full control over the process. I suggest storing scripts in separate files to enhance testability, even within local development environments. If you're managing infrastructure, for instance, Terraform scripts can automatically provision resources as part of your deployment flow. With scripting, you can ensure consistency, automate rollbacks, and even integrate testing into every step of the pipeline. Once you get the hang of it, scripting in CI/CD becomes second nature, and the benefits in terms of reliability and speed are undeniable.
Automate Everything: NoOps
"NoOps"ā-ā(not) just another buzzword.
While still in its infancy, NoOps envisions a future where infrastructure management is fully automatedā-āso much so that developers no longer need to worry about operations.
I envision building our internal tools and core components in a way that developers would genuinely "love" to use: Pipeline Templates, Configurations as Code, Infrastructure as Codeāyou name it. I see this concept as similar to an SDK.
While we aren't quite at NoOps yet, the concept illustrates just how far automation can go.
And remember! GitOps goes hand in hand with NoOps.
(Uuugh! Do I need to explain GitOps as well!?? š©š)
Ok! I'll be quick: GitOpsā-āMake sure you keep everything in repository(es). š
Different Faces of DevOps Engineers
Throughout my career, I've encountered many different types of DevOps engineers. Each comes from a unique background, and each has their own strengths and challenges. Let me introduce you to a few:
The Ops-Heavy Engineer: Lacking the "Dev" inĀ DevOps
These engineers typically come from traditional IT operations. They are experts at managing servers, networks, and cloud resources but often rely on manual processes through GUIs and dashboards. They may be proficient at ClickOps but lack the coding skills needed to automate these processes. Their DevOps journey starts with learning scripting languages like PowerShell, Bash, or Python and mastering tools like Terraform or Ansible to automate their work.
The Dev-Heavy Engineer: Experiencing Ops for the FirstĀ Time
On the other end of the spectrum, you'll find developers who are diving into the world of operations for the first time. They're skilled at writing clean code and building applications, but managing infrastructure, deploying applications, and troubleshooting cloud environments is new to them. Their challenge is learning how to integrate deployment pipelines and monitor infrastructure while maintaining the quality of their code.
The Balanced DevOpsĀ Engineer
The ideal DevOps engineer balances both development and operations
(š¤ Yep! That's me š). These engineers can write scripts, manage infrastructure, automate processes, and troubleshoot issues in production. This type of engineer represents the essence of DevOps: combining the development skills to build software with the operational know-how to deploy and maintain it seamlessly.
No matter where you start, each path is a valid entry point into the world of DevOps. Whether you're an ops-heavy engineer learning to code or a developer stepping into the world of infrastructure, there's room for everyone in this journey.
Getting Started in DevOps
- Learn Coding: Pick up Python, Bash, or PowerShell to automate tasks.
- Know the Cloud: Familiarize yourself with AWS, Azure, and/or GCP basics.
- Master Git: Understand version controlābranching, merging, and pull requests.
- CI/CD Pipelines: Automate testing, building, and deploying code.
- Infrastructure as Code: Use tools like Terraform to manage infrastructure via code.
- Collaboration: Work closely with different teams for smooth delivery.
What to Expect fromĀ DevOps
- Automation Focus: Replace manual tasks with scripts.
- Always Learning: New tools and tech appear fast.
- Problem Solving: Troubleshoot and scale infrastructure.
- Teamwork: Work with developers, testers, and IT.
- Process Ownership: Oversee software delivery.
- Security: Integrate security into workflows.
Conclusion: Starting Your DevOpsĀ Journey
Whether you're an ops expert learning to code or a developer stepping into operations for the first time, the world of DevOps is vast and full of opportunities. The key is to embrace automation, continuously learn, and always be looking for ways to improve efficiency and scalability.
Whether you're targeting Azure, AWS, Google Cloud, Alibaba Cloud or other cloud provider, the concepts are the same.
This is just the beginning of my journey in writing articles, and there's much more to come. In future articles, I'll talk about different experiences I had along the way, dive deeper into specific tools, automations, and probably some other tips and tricks that can be used in the DevOps world. š
So, stay tunedā-āthere's a lot more to explore! š
Credits
Thanks to @koladev for the nice article that kickstarted in me the whole idea of writing articles.
š How to Build Your Online Presence as a Developer
Thanks to @birghi for the persistence he showed by asking once in a while Hey! Did you publish your article? š
(Now it's my turn š)
Thanks to @dumebii for the nice article that pushed me to stop overthinking the writing of this article and just publish it š.
š š How to become a Technical Writer
Your first article is probably the hardest article you'd write
If you enjoyed this article and want to stay updated with my journey and future posts, consider giving me a follow! I'd love to connect and keep exploring DevOps, automation, and more together. šš
Top comments (16)
well, you are a very good story-teller. I was immersed in the text from start to finish. What a joyful journey it was! Keep writing as I'm eager to learn more from you.
I'm new to operations (I'm a so-called dev-heavy one)
š„¹ Ooow! Wonderful words. Thanks!
I'm already preparing my new article š
I'm not in DevOps at all, though I've worked with quite a few in my current position. I'm in production support, so I do quite a bit of troubleshooting and change management on behalf of internal and external users. Plus plenty of scripting and API integrations for myself and my team.
Automation is my personal mantra. I've been using the CLI and scripting since I was 12 years old (dragged kicking and screaming into the GUI world, and never felt quite at home in it). I now have a pretty bespoke Linux UI I built myself, and use desktop automation like a fiend on both Linux and macOS (can you tell I'm a UNIX guy at heart?).
I think DevOps would be a great fit for my skill set, I use git and can program in Bash, zsh, and Python (among familiarity with quite a few other languages). I also have some solid training and experience with AWS and GCP.
Your description of ClickOps sounds very foreign to me, it seems GUIs for managing this stuff can be quite limited especially if you want to do things in ways the GUI developer didn't envision.
I just don't have experience with a lot of the CI/CD technologies, Infrastructure as Code, and collaborating with more than one other developer on any moderately sized code project. I'm interested in learning more on how to get into this space, seeing as I don't feel I fit in the spectrum you gave.
Well, the terminology changed throughout years; and DevOps became a buzzword lately, which for some is easier to understand.
However it simply translates into
Development (Dev) and Operations (Ops)
Are you already developing some automations, setting them up and troubleshooting production systems?
Well, bravo! š In the sense already explained above, you might already be a "DevOps", but you just don't know it (yet) š
Personally, I still prefer to use GUI on desktop, for mundane tasks. š¤ However, when we're discussing about automations, then CLI is the way š¤
On the other hand, when I was talking about ClickOps, I was referring more to the manual tasks/operations that can be done within a browser for setting up or configuring some cloud resources (a few examples: repositories, permissions; container registries, key vaults, etc)
You are IT for developers šš hahah...
š¤š¤ I was always saying that "developers are our customers" š
Thank you so much for the shoutout!
This was a beautiful read.
I'm glad you enjoyed it š
I can relate to this so hard just minus the Technical Lead part :)
I suppose that last part came as a results of me doing experiments with different stacks and technologies, understand how those puzzle pieces fit together throughout the years.
I haven't put much thought into it, but genuinely that was my foundation for it.
Devops is the number 1 reason for male pattern baldness
Makes sense why I lost my viking braid š¤£
Wow amazing man, do you have youtube channel?
Thank man! Sorry, no(t yet) š
Hey i am still unsure of using python, i used bash until now but i would like to know how it feels to use python for scripting. I means the oops part in scripting , libraries and type shit "You do understand where i am going right !".
Basically almost any scripting language can be used. šŖ
I saw another team using Python scripts in CI/CD. If it works for them, that's their main programming language and they are comfortable with it, then why not. š
The upside is that you can setup something really quick, without creating a fully fledged separate project or solution (to be read as NET project, for example).
However the downsides you just mentioned shows up when the scripting language does not support strong types or the script is written without using strong types; and you find yourself in the situation where a typo exists in one of the variable and you won't even notice it for days (even while debugging it š ).
And yes, some of scripts also requires an additional step for installing their modules/libraries/dependencies.
And that's why, me, personally, I'd like to set something up that uses strong types. Like C# š
JSYK, Microsoft made it easier to setup C# Scripts:
learn.microsoft.com/en-us/archive/...