Vasilios Syrakis - architecture

Vasilios Syrakis - architecture A simple blog made with Zola and Duckquill Zola 2026-06-30T00:00:00+00:00 https://cetanu.github.io/tags/architecture/atom.xml For 12 years, I ignored Kubernetes 2026-06-30T00:00:00+00:00 2026-06-30T00:00:00+00:00 Vasilios Syrakis https://cetanu.github.io/blog/i-ignored-kubernetes-for-12-years/ <h1 id="my-introduction-to-kubernetes"><a class="zola-anchor" href="#my-introduction-to-kubernetes" aria-label="Anchor link for: my-introduction-to-kubernetes"><i class="icon"></i></a> My introduction to Kubernetes</h1> <p>Like many people I heard about kubernetes because it was software from Google that people were hyped about. I understood a little bit about it - it’s a container orchestrator, right?</p> <p>I also heard about painful experiences that people had with it and I got this impression that it was way too complicated for what it provided in most cases.</p> <p>We’ve all heard the meme “I deployed my blog on kubernetes” as a classic example of overengineering, and resume driven development when a team sets up kubernetes for a single application.</p> <p>While working in the industry, I was happy to let other people deal with this perceived complexity. I was willing to let them work out all the problems and figure out how to offer kubernetes to me as an end-user.</p> <h1 id="post-layoff"><a class="zola-anchor" href="#post-layoff" aria-label="Anchor link for: post-layoff"><i class="icon"></i></a> Post-layoff</h1> <p>However, as time went on, it seemed that the entire industry made a decision to adopt kubernetes, even if the overheads and complexity were of some cost, because the cost was outweighed by standardisation.</p> <p>Suddenly, every SRE / platform engineer role seemed to require knowledge of kubernetes. It was never too clear how much knowledge or skill was required, and there have been several interviews in which I’ve expressed that I don’t have any experience operating kubernetes (probably a bad thing to say in an interview) and yet interviewers did not seem to be able to give me a picture of how they use kubernetes and what I would need to know in order to sufficiently operate their clusters/infrastructure.</p> <h1 id="start-of-the-learning-journey"><a class="zola-anchor" href="#start-of-the-learning-journey" aria-label="Anchor link for: start-of-the-learning-journey"><i class="icon"></i></a> Start of the learning journey</h1> <p>So after being laid off in March 2026, it became apparent that learning kubernetes would be a good idea. Later in May, when my video went viral and an audience appeared with the desire to learn new things, particularly by being taught by myself, it made even more sense to learn kubernetes because it would give me the opportunity to both learn and teach at the same time.</p> <p>So I embarked on a journey to learn kubernetes with the least amount of patience possible, pressuring myself to learn it in a week. Over 7 live-streams, approximately 2-3 hours each, I gathered a decent picture of the kubernetes landscape, a bit of history, and what tools people use to deploy and manage kubernetes in modern times.</p> <h2 id=""><a class="zola-anchor" href="#" aria-label="Anchor link for: "><i class="icon"></i></a> </h2> <p>The very first thing I did was started streaming on Twitch, with the stream title “Added Kubernetes to my CV, now I have to learn it” and opened a browser, went to the kubernetes website and started reading docs linearly. After going through various concepts and basically trying to memorize them and failing, a few chatters informed me of Kelsey Hightower’s guide “Learning Kubernetes The Hard Way”.</p> <p>I started going through this tutorial, and found that it required at least 3 machines with 2GB of memory each, and I didn’t have that hardware laying around, and I didn’t want to run them on my stream PC. So I signed up to AWS and started to create EC2 instances manually, and SSHing onto them to set up hostnames and run OpenSSL commands to do PKI.</p> <p>At some point the tutorial was telling me to execute blobs of shell scripts and I became enraged at the suggestion because it’s been two decades since the advent of configuration management, and at least a decade since kubernetes has been released. So I thought that all this friction had already been smoothed out.</p> <p>In hindsight, the entire purpose of Kelsey’s guide is to expose someone to these low-level concerns. However, I am personally more in favor of getting something practical up and running quickly, and dealing with problems as they arise.</p> <p>So I started an argument with Gemini about Kelsey’s guide, and it graciously agreed that no sane engineer would set up kubernetes by following that guide in a profession scenario. It led me to discover <code>kubeadm</code> which gave me a way to bootstrap the cluster nodes in one command.</p> <p>I used this newly found tool to then set all the infrastructure up with Cloudformation, running the tool during the init of the EC2 instances via UserData. I successfully got a cluster running and then tried to use Helm to install “charts” to get a valheim server pod running.</p> <p>Using helm got a bit messy, and a bunch of pods were crashing, and to be honest I had no idea why. My hypothesis at the time was that the process of pushing YAML to kube via helm and kubectl was fragile and that it was running into issues with state becoming corrupted or partially deployed.</p> <p>Finding myself frustrated, I took a break to think about what my next approach would be.</p> <p>I had a friend tell me about his setup where he doesn’t run any helm commands against the cluster, but instead uses it to produce kubeconfigs as build artifacts which are then ingested via GitOps.</p> <p>I also started to remember a recommendation to use Talos Linux from another peer so I decided to see what that was about. It sold this idea of an immutable kubernetes cluster which supposedly would prevent the kind of state corruption that I thought I was running into.</p> <p>At this stage I decided to completely pivot, use Talos Linux, and switch to Pulumi instead of Cloudformation for the infrastructure even though it would cost me some time in the learning process.</p> <p>I quite enjoyed Pulumi; it feels like a type-checked infrastructure, which is cool. I used the golang SDK.</p> <p>After a bunch of troubleshooting and looking at logs of pods, and feeding those logs into Gemini, I discovered that there was a bootstrap dependency issue where other pods like Argo required that AWS CCM was setup before it would work properly.</p> <p>After this, it was pretty smooth sailing. I could add CRDs and charts to my gitrepo and argo would pick them up and provision pods quickly. I started to thinkabout how to platformatize everything that I’d built but I realised that thiscan become quite subjective, and so for this article I won’t go into that atall, but the options that I was aware of were tools like KubeVela, Crossplane,and Backstage.</p> <blockquote class="warning"> <p class="alert-title"> <i class="icon"></i>Warning</p> <p>Still writing this up</p> </blockquote> <iframe class="youtube-embed" src="https://www.youtube-nocookie.com/embed/V8iT_2YHtns" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen> </iframe>  A Philosophy of Software Design 2026-03-25T00:00:00+00:00 2026-03-25T00:00:00+00:00 Vasilios Syrakis https://cetanu.github.io/blog/a-philosophy-of-software-design/ <p>Today I finished reading the book, “A Philosophy of Software Design”, by John Outsterhout, a professor at Stanford University.</p> <p>I wanted to write a little about what I learnt from the book, plus how I see it mapping to my experience in my work where I’ve dealt with software and choices around design.</p> <h3 id="complexity-is-incremental"><a class="zola-anchor" href="#complexity-is-incremental" aria-label="Anchor link for: complexity-is-incremental"><i class="icon"></i></a> Complexity is incremental</h3> <p>This is probably obvious to anyone who has worked on software in any serious capacity, but (unless you’re vibe-coding) complexity doesn’t just show up in a single pull-request.</p> <p>It’s the “Boiling Frog” problem, except you’re not the frog, you’re the chef…<br /> If we increase the temperature by just one degree, surely it’s not that bad, right?<br /> This is how we justify adding complexity to ourselves when we say “it works for now, I’ll clean it up later” on a pull-request.</p> <p>The incremental quality of complexity is what makes it so insidious, because it’s so easy to trade a small bit of complexity to get something delivered. You can even continue to make that trade-off, again and again, for years. Who cares if an abstraction leaks a little bit, as long as I can fix up this edge case right now?</p> <p>It’s hard to pinpoint the exact moment when things become sluggish, hard to change, prone to errors, and difficult for new engineers to understand. That’s because there’s no exact moment.<br /> Just like how a frog doesn’t suddenly start boiling when the water goes from 99°C to 100°C.</p> <h4 id="it-s-shared-discipline-not-a-technical-challenge"><a class="zola-anchor" href="#it-s-shared-discipline-not-a-technical-challenge" aria-label="Anchor link for: it-s-shared-discipline-not-a-technical-challenge"><i class="icon"></i></a> It’s shared discipline, not a technical challenge</h4> <p>I might be totally wrong on this, but I get a general sense that when people think about complexity, the focus is on technical decisions that get made over time. It almost implies that you can solve complexity all by yourself if you just work hard enough.</p> <p>We work with other people. I believe it’s more pragmatic to shift this perception so that the focus is on person-to-person interactions - which I assert is where the problem arises.</p> <p>When a reviewer fails to stand their ground, complexity is welcomed in. This can be tricky, because often you’re standing against a peer who you trust, who means well, but who might be too busy to spend the extra time to come up with a design that doesn’t attach one more tiny anchor to the codebase.</p> <p>I comfort myself by thinking that nobody intentionally adds complexity. They can’t see a better way, or maybe they didn’t ask themselves if there could be a better design. Thinking takes energy and I don’t blame anyone for taking the path of least resistance to get their work done. Perhaps what we need is better ways to measure complexity, so that we can reward its reduction.</p> <p>For people working solo, you are both the author and reviewer. If you aren’t trying to see your own work from a different perspective, then your “reviewer” persona is effectively rubber-stamping the work, shrugging, and walking away.</p> <h3 id="abstractions-are-about-hiding-unnecessary-details"><a class="zola-anchor" href="#abstractions-are-about-hiding-unnecessary-details" aria-label="Anchor link for: abstractions-are-about-hiding-unnecessary-details"><i class="icon"></i></a> Abstractions are about hiding unnecessary details</h3> <p>This one probably sounds like common sense. Duh! That’s what an abstraction is.</p> <p>However, for me, I think it’s valuable to consider that you and I sometimes make abstractions that accidentally hide <em>necessary</em> details.</p> <p>This is one of those things where, if you zoom out a little bit, makes software engineering seem like such a challenging field. The subjectivity of this - where to draw the boundaries of an abstraction - highlights a constant cognitive requirement towards making a balanced decision.</p> <p>You can’t open a book and have it tell you how to make the right abstraction. You just have to fail, walk into a mess, learn from the mess, and make the next project better, only to fall into another mess. A mess that grows as it feeds on entropy and junior developers.</p> <h3 id="deep-modules-are-simpler-than-shallow-modules"><a class="zola-anchor" href="#deep-modules-are-simpler-than-shallow-modules" aria-label="Anchor link for: deep-modules-are-simpler-than-shallow-modules"><i class="icon"></i></a> Deep modules are simpler than shallow modules</h3> <p>First, what does this even mean? What is a deep module?<br /> A module is deep when its implementation is large compared to its interface.</p> <p>That means that you could have a module that is long (in terms of lines of code), but if every function in that module is exported, the interface is large.</p> <p>Instead, a deep module would be something with perhaps a few key functions or classes exported, which encapsulate the implementation behind a concise interface.</p> <p>This was something that surprised me at first but makes total sense. If make a library, I don’t want the caller to have to know about 20 different functions or methods that they need to call, especially if most of the time all of the arguments passed in are very similar.</p> <h3 id="general-purpose-code-is-simpler-than-special-cased-code"><a class="zola-anchor" href="#general-purpose-code-is-simpler-than-special-cased-code" aria-label="Anchor link for: general-purpose-code-is-simpler-than-special-cased-code"><i class="icon"></i></a> General-purpose code is simpler than special-cased code</h3> <p>What exactly is the difference between the two?<br /> General purpose code solve a class of problems. Special case code solves one problem.</p> <p>Example:</p> <ul> <li>Special case: A function that adds the <code>Authorization</code> request header with a particular value</li> <li>General purpose: A function that adds a request header, with a given key and value.</li> </ul> <p>Special cases pop up in codebases after their initial design has been implemented, a bunch of users have been onboarded, it’s operating fine, but one particular (and important) user needs it to do something that wasn’t in the original design. This is expected in software, and rigidity isn’t a good response.</p> <p>If you immediately know how to change the system so that their particular need is solved as a general case it’s a clear win, but this doesn’t seem to be how things go in most cases. Instead, it takes painful thinking to determine what needs to be rearranged, migrated, and mutated, in order for the special case to be handled in such a way that it doesn’t require someone to carve out time from their day to maintain it.</p> <h2 id="philosophy-not-science"><a class="zola-anchor" href="#philosophy-not-science" aria-label="Anchor link for: philosophy-not-science"><i class="icon"></i></a> Philosophy, not Science</h2> <p>There is a particular theme that seems to be common across the above concepts.</p> <ul> <li>What makes a good abstraction?</li> <li>How deep should a module be?</li> <li>How general should my code be?</li> </ul> <p>There’s no formula. A book can’t teach it to you. A committee can’t develop a standard for it.</p> <p>The fundamental question being wrestled with is “Where do I draw the boundary?” and the answer is different from wherever you are standing.</p> <p>It’s the human factors that help answer this question. How much cognitive load can the user or reader bear? How often will I have to change the codebase? A compiler or linter can’t answer these questions. It requires a person to draw a subjective line in the sand and then defend it.</p> <h3 id="the-element-of-taste"><a class="zola-anchor" href="#the-element-of-taste" aria-label="Anchor link for: the-element-of-taste"><i class="icon"></i></a> The element of “Taste”</h3> <p>I hear about how the future of software will be influenced by having good “taste” now that LLMs are writing all the code (I don’t actually believe this).<br /> If that’s true then I sincerely hope that all the people that intend to map their taste into software learn good software design first.</p> <p>Ironically, the way to learn good software design is through experience. You have to ship something and collect the feedback. Sometimes that feedback is customers telling you what causes friction. Other times it shows up in the volume of questions directed at a particular feature… at 3AM after your site blows up.</p> <p>While reading the book you get a sense that it’s never going to answer this question, “What’s a good abstraction?” because it can’t. The professor encourages people to find the right balance for themselves, and it introduces distinctions that might enable them to do so.</p> <p>You might be creating a good design if the abstraction aligns with a business domain, or when you provide a neat general-purpose interface across an entire system. You might be creating a bad design when you add logic that purely addresses an immediate need and nothing else.</p> <h2 id="my-closing-thought"><a class="zola-anchor" href="#my-closing-thought" aria-label="Anchor link for: my-closing-thought"><i class="icon"></i></a> My closing thought</h2> <p>Writing this page made me realise that these problems that I found unapproachable - how to decide where to draw the line - are simply the way things are. It’s the essence of design.</p> <p>Just like other art forms, you can practice, fail, learn, and improve, but there will always be some people that either love or hate the art that you created.</p> <p>Often that person is your own self. The inner-critic looks at the past and is ashamed of mistakes. I choose to forgive myself for the imperfections and focus on the parts that I’m proud of.</p>