🎉 Welcome to Simple Engineer Notes!

Hi there!

This channel is about sharing my simple thoughts and notes about complex topics from an engineer's point of view.

Who am I?
- In real life: cyclist, camper, engineer & coffee person.
- At work: As an infrastructure simplifying engineer, I’ve seen infrastructure from completely different points of view: as a system administrator, software-defined storage developer, and DevOps engineer. Fortunately, there’s an unchanged part. I believe that infrastructure is code and therefore we must use the same philosophy for infrastructure as for software development.

What to expect here:
- Simple explanations of tricky engineering ideas.
- Personal notes and real-life lessons about IT, IaC, DevOps, automation, engineering

Thanks for joining me on this journey to make complicated things simple.

The most interesting posts:
⚡️ Blackout in Spain & Portugal 2025-04-28
🛠 VmWare & Hardware version debug
📂 Photo archive

P.S. it might be interesting to read the articles
- IDLC = SDLC + Ansible: IaC Development Life Cycle: Ansible based story
- How to test Ansible and don’t go nuts
- Lessons learned from testing Over 200,000 lines of Infrastructure Code
- System call interception in linux-kernel module
- A list of awesome IaC testing articles, speeches & links. Especially about Ansible.

🤖 GPT 4 IaC Usecases

I’ve made some practical experiments with GPT in the IaC context and want to share the gist from the article:

🔥 Documentations & presentations
✅ Create Ansible lookup plugin
✅ Generate documentation
✅ Explain Jinja2 expressions
❓ Fix errors in Ansible roles
⛔️ Debug Ansible OTC dynamic inventory plugin
⛔️ Explain dependencies across the project
💡 PR reviewer
💡 Increase IaC test coverage

#article

✈️ Terraform for VMware: Key Takeaways and Lessons from Managing Hundreds of VMs

Managing a large number of virtual machines can be challenging. As our infrastructure grew, we needed a better way to handle the complexity. That’s when we turned to Terraform to help us manage our VMware environment more efficiently. the gist from the article:

Lessons learned
1. Use remote state
2. It's tricky to catch more than 10 changes at one time
3. With great power comes great responsibility
4. Bulk changes can lead to performance degradation
5. Avoid configuration drift between VMware & terraform
6. Instead of recreating VM you can simply move it
7. Use prevent_destroy to avoid VMs deletion
8. Use simple & obvious structure to make entrance level lower
9. Use to ansible dynamic inventory based on tags
10. It's possible to add the missing functionality

Benefits

1. It's really easy to perform bulk updates
2. Re-create infra from nothing
3. Trackable changes
4. Single source of the truth

Want to try
1. Terraform pull request automation via Atlantis
2. Build green button in jenkins
3. Windows automation
4. Cloud-init for setting hostname like here (sry it's in RU)
5. Tests for terraform like for ansible

#article

👩‍🦯 yoke - make IaC more complicated

I've just found the https://yokecd.github.io/docs/ . Authors tries to solve portability problem & make reproducible solution for IaC. In general it's a good idea in the right direction. But it introduces one more abstraction level. They propose pack the configuration into webassembly and execute it later. I assume, that it will be quite tricky troubleshoot in the feature in complex environment.

links:
- https://xeiaso.net/blog/2025/yoke-k8s/
- https://yokecd.github.io/docs/

#iac

Sometimes simplicity is a road to the hell

#fun

🎯 10 Lessons from Werner von Siemens

I’ve just read Personal Recollections of Werner von Siemens and noted:

1️⃣ Solve Real Problems – Siemens didn’t invent for fun. He built things like better telegraphs and generators because people needed them.
2️⃣ Start Small, Think Big - the initial idea was simple: create remote detonator, but ended as cross Atlantic land line.
3️⃣ Make Things More Efficient - each iteration of landlines, dinamos were better than the previous one. It like ci/cd.
4️⃣ Turn Ideas into Products - He didn’t just study science; he turned discoveries into useful inventions.
5️⃣ Take Smart Risks - Siemens took steps in new technology and business, but always calculated the risks.
6️⃣ Keep It Simple - He believed good engineering should be practical and useful.
7️⃣ Be Ethical and Long-Term Oriented - He treated employees well and built trust with customers.

Summary: engineering isn’t about making over complicated things - it’s about making life easier for people. It was 150 years ago and it’s still relevant.

#book

⌨️ Elementary computer

I have quite a weird idea for the next project:
1. Build a computer from scratch
2. Run a modern OS like https://collapseos.org/

What for? There is too much complexity and specialization so sometimes people don’t have a clue what’s happening 2 levels above. I’ve been working in IT almost 20 years and I’ve saw my hardware only couple of times.
So, the idea behind is to learn missing hardware part in my knowledge and have the big picture from a frontend to the hardware.

Right now I’m collecting the ideas, so if you have something interesting in that field..

Links:
- https://www.coursera.org/learn/build-a-computer
- https://collapseos.org/
- https://www.instagram.com/albin.jd

#diy

🔨 Simple, but not too simple

There is nice speech https://www.youtube.com/watch?v=ZSRHeXYDLko Preventing the Collapse of Civilization / Jonathan Blow (Thekla, Inc). My key takeaways:
- We are losing knowledge, instead of gaining it
- Software development is also affected. It's becoming too complex
- Many developers rely on frameworks and libraries without understanding how they work
- Ancient civilizations collapsed partly because they lost the ability to maintain critical knowledge. We may be repeating the same mistakes.
- Open-source and documentation aren't enough. Without real understanding and hands-on experience, it becomes useless over time.
- Short-term thinking leads to long-term problems & creating tech debt.
- We need to relearn simplicity. Instead of making systems more complex, we should focus on simplifying them so they can be understood by future generations.

As a sollution for the state problem there the answer https://aws.amazon.com/builders-library/reliability-and-constant-work/ :
- Simple systems fail less: The more complex a system, the more things can break.
- Avoid over-engineering: Adding unnecessary features or dependencies increases risk. Build only what’s needed.
- Automation should simplify, not overcomplicate: Automate repetitive tasks, but don’t create overly complex automation that’s harder to maintain than the problem it solves.
- Fewer Moving Parts = Fewer Failures
- Chaos Testing: If random failures cause unpredictable issues, the system is likely too complicated and it's time to review it.
- Learning from failures: After an outage, analyzing what went wrong and improving processes helps avoid similar failures in the future.

#refl

😮 freebsd alive

I used to use freebsd ages ago before 2010. I thought thar project is almost dead. But today i found that somebody uses it because of simplicity https://aumont.fr/posts/FreeBSD-Home-Server/

Prons:
- simplicity
- minimal ram/cpu footprint
- back compatibility

Cons:
- not possible to run desktop

Fun fact that I used freebsd as a desktop at my laptop. I spent almost 2 months compiling wine, x, etc to play fallout 2. So I can’t count it ad a downside. However, I can’t imagine IRL scenarios for freebsd in 2025

#freebsd