The 100-Day DevOps Logbook

🛠️ The 100-Day DevOps Logbook

Welcome to the 100-day DevOps Challenge LogBook. This is meant to be followed by beginner or experienced devops engineers, software developers (frontend, backend, fullstack) and anyone wanting to get into technology. Remember, DevOps as it’s defined is a company culture, not specifically a job position.

This is a day-by-day, raw, and unfiltered look at building—and sometimes breaking— modern infrastructure. We’ll be exploring tools and skills which are essential for Full Stack Developers AND DevOps engineers alike.

Full Disclosure: I have a specific vision in mind and want to prepare you for the real world in a unique hands on way. As much as I like structure and getting to an end goal this is an experiment and you will notice some unique patterns and different thinking. Remember, different and unique thinking is what got us to technology. Life is messy, and so is engineering. Some days will be about high-level architecture (Solution Architect style), while others will be about a single, beautiful unix or linux command that saved my afternoon.

The Rules of the Game:

1. The 5-Minute Rule: If a problem takes more than 5 minutes to solve, it deserves a note.
2. Pragmatism and Simplicity First: We favor tools that are fast, secure, simple and self-hosted. No bloat allowed. DevOps has become bloated due to enterprise “needs”. Solutions can be simple and elegant.
3. Mastery via Re-learning: We look at everything with “Beginner’s Eyes,” even the things I’ve done for 20 years.
4. Honest Progress: No AI-generated fluff. Just real human thoughts and experiences together with machine generated logs.
5. We’re going to go deep into unconventional DevOps technologies and decisions which are not covered in most courses due to the fact that everything I do is quite unconventional.
6. This 100 day devops challenge is meant for you to go through day by day and experiment with the tools, commands and programs on your local environment. Of course you can JUMP around t othings which interest you come back.
7. Very IMPORTANT Note, this is MY VISION of DevOps and Software Engineering, you’ll see my OPINIONS, while I am flexible, you are free to adopt any opinion you want, choose what works for you;) In software engineering you can solve any single problem in 100 ways. It’s important to have OPTIONS and choose the best one without going to extremes of “not having any option” or “analysis by paralysis”.
8. Follow VIDEO and read the text. Whenever I record a video, please note that what I will be discussing there could seem similar, yet will mostly be different from the text on the 100 days individual, so read the text AND follow the video.

To be honest, I spent so much time writing code to automate things or build complex applications that at multiple points I had to redecide to KISS keep it simple seriously.

Most software engineers, managers and even devops engineers have no idea how simple it is to build and run things. New engineers (devops, backend etc) are flooded with complex solutions for problems which create eve more problems. A FreeBSD jail will solve more problems than trying to fit kubernetes into the mix.

It’s the simplicity I’m after, only after we grasp and understand the basics can we consider scaling up vertically or horizontally properly. If there’s one thing you remember after finishing these 100 days is that you should look at everything with the eyes of a beginner but also with skepticism. DO you really need the complexity? This is what a Soluton Architect should do but you as a software engineer or devops also need to think about this.

Small Steps Daily

We are taking small steps daily as to 1 not overwhelm beginners or add unneeded complexity 2 show how easy it is to think of new solutions 3 understand the flux without complex tools frameworks 4. Understand when and where those tools are good Adding features as we go along. We want to work iteratively (true meaning of devops) and improve as we go along

Everything we do in engineering has drawbacks. 100 potential solutions Simple easy elegant means short time to production which is what matters .

Using Linux for everything. It’s expected you already understand the basics. I’ll provide links but you need to take time and experiment.

The Journey So Far:

Look at the left side panel for the next pages;)

💡 What to expect here?

You will see a mix of:

• Deep Dives: Building a “Private Hybrid Cloud” on my 90GB RAM Linux workstation in combination with some older notebooks and raspberryPI’s AND superscaling with AWS or other clouds providers including Cloudify, Linode and others.
• TIL (Today I Learned): Short, punchy snippets. A weird iptables quirk, a Go trick, or a Fossil SCM command.
• Reflections: Experiments. What went well, what went wrong
• Soft Skill References. We’re also talking about very important soft skills every now and then which are required to succeed in engineering.

Don’t just watch the grass grow. Grab your own workstation, break something, and document it.

What you’ll need for this

• Internet access (obvious)
• A Laptop or workbook with a minimum of 16GB, recommended 32GB of RAM. Heck, I used to virtualize whole operating systems on a 4GB RAM machine back in 2009;).

“The expert is a man who has made all the mistakes which can be made in a very narrow field.” – Niels Bohr