DEV Community: kuberdenis

gctx: git auth manager

kuberdenis — Tue, 27 Jan 2026 13:42:39 +0000

I created a kubectx-inspired git auth manager

kubeden/gctx:

sets a global git identity
rewrites origin to an ssh alias
allows deterministic auth for multiple accounts

Try it at: github.com/kubeden/gctx

How to build a good container platform

kuberdenis — Mon, 24 Nov 2025 21:01:34 +0000

How to build a good container platform

Description

Platform Engineering is the act of designing, provisioning, and maintaining a platform.

You provision resources.
You configure resources.
And you use your platform.

It sounds easy but it's not.
Most engineering teams fail.

Blocks

In order to build a good platform, you need to build logically.

Base (Cloud / On-Prem / Hybrid Cloud / Multi-Cloud)
Application Engine [(k8s / vms / serverless) in our case k8s]
Platform Components (monitoring, application, recovery, automation)
Application Components (ci/cd, configuration repo)
Subtleties (secrets management & rotation, states, processes)

Organizations hire teams, often to do one thing. Which is wrong.
How one team does something, is often not how the others will.

Expertise is often different, which leads to "know-how drifts" and technical debt.

Standartization

This is maybe the most important foundation block for a platform to thrive.

Standartization is almost always ignored:

name suffixes & directory structures
utility separation
unified deployment methods
documentation & knowledge transfers

These are the "atoms" in a good platform.

Name Suffixes & Variability

Name suffixes are your map points.
Directory structures are your streets.

Every organization should have strictly defined name suffixes and directory structures that should be applied across:

iac repositories
application management repositories
cloud resources
secret namings
service accounts
and so on.. and so on..

A good name suffix system includes 3 to 7 matching variables.

Example:

customer
region
environment
iteration
type

Continuing the example, this would translate to:

e.g. directory structure: ${customer}/${region}/${environment}/${type}-[${iteration}?]
e.g. terraform resource: ${customer}-${region}-${environment}-${iteration}-${type}

Imagine this at scale.
It is easy to navigate it now.
It is easy to understand.

It is.. nice to work with! :)

Utility Separation

Many organizations don't separate.

They create a repository called devops and they put everything inside:

terraform
bash scripts
yaml
helm
kustomize
ansible
and god know what else

Instead, you should be grouping logically:

infrastructure provisioning: manage the lifecycle of your resources
infrastructure configuration: manage the configuration on your "live" resources
application deployment: application configuration
application code: well... your application code

Here is an example of well-separated & logically-grouped repositories:

infrastructure: terraform, bash (as few as possible)
k8s-cluster-configuration: yaml, kustomize, helm, jsonnet
[application]-k8s-configuration: standartized releases / deployments / libs

This way, you achieve the following:

a single place to provision / depracate infra
a single place to provision / depracate platform components
a single place to provision / depracate applications

Platform Resources: Provisioning

Regardless of the technology you choose, you should handle provisioning of resources as a standalone practice.

Here is an exapmle of a good Terraform set-up:

Repository: infrastructure
Directory structure:

modules/
base/
.ci(or .github, or whatever the standard is)

Where in /modules, you treat it as "libs", a place where you manage the versioning of your modules (community or personal).
Example continuation of modules can looks like this:

modules/
- azure/
- azurerm/
  - key-vault/
  - community/
  - personal/
  - acr/
  - ...
- /azuread
  - ...
- /aws
- /control-tower
  - community/
  - personal/
- /rds
  - ...
- /s3
  - ...

And in base, you call these modules:

base/
- [customer]/
- [ region ]/
  - [ environment]/
  - common/
    - locals.tf
    - provider.tf
    - key-vault.tf
    - acr.tf
    - ...

You never click in the cloud provider.
But you also don't configure here.
You do not "hack" yamls.
You do not apply hard-to-figure-out scripts.

You only spawn and delete. :)

Platform Components: Configuration

In order to have a good platform, you need to be flexible, clear, and rock-solid in terms of its capabilities.

One of the most hardened platforms I've ever built (and I built it 3 separate times) is as follows:

Management:

ArgoCD: Management, IAM, GitOps.

Routing:

ingress-nginx: routing, one lb, reserve ips in your subnet, manage routing programmatically
cert-manager: automated ssl
external-dns: automated dns

Secrets Management:

external-secrets: vaults, stores, you name it
sealed-secrets: plain-text secrets in your repo (for stuff like the initial argocd secret)

Monitoring:

grafana-operator: well.. grafana :) graphs and stats
prometheus: metrics
blackbox-exporter: alerts
thanos (if multi-cluster): consolidation of metrics
eck: elk :)

Backups:

velero: backups

Scaling & State:

reloader: re-apply configs
keda: scale applications
karpenter (if on AWS, Azure have it by default): scale nodes

All of this should be managed through a single ArgoCD application called "cluster-apps" or similar.

Tools like Jsonnet and Kustomize are your best friends here.

(read about the app-of-apps pattern too)
((no i do not like applicationsets))

Application Configuration

Your application configuration repositories should be standartized.

A well-thought-of application configuration repository is no different than the infrastructure, or the platform repositories.

You should again think in the following direction:

releases: packages
libs: building blocks for /releases
deployments: calling your packages

You see, the same concept applies over and over again -- manageability, readibility, and standartization.

I usually go for Jsonnet, but I wanted something simpler, so I went for Kustomize, only to find myself in a very thight situation, and ultimately decided upon with Helm.

Jsonnet is awesome, but it often requires a lot of special expertise and in case your main engineer leaves, it is possible you're going to have problems finding adequate peresonel.

CI/CD

Since we are mostly relying on GitOps for our platform, the CI/CDs worth mentioning are:

infrastructure:
- terraform plan/apply: one pipeline per resource type (e.g. ${customer}/${region}/${environment}/${logical-group}/${resource-type}-${iteration}/pipeline.yml
- pipeline-of-pipelines: a global pipeline to manage the update / management of the child pipelines
application:
- build & test: well, build and test
- deploy: since we're relying on GitOps, our deploy is a single git line change :)
k8s-cluster-configuration:
- a pipeline to bootstrap the master argocd (optional, since you are allowed to do this through Terraform the first time :))

Notable mentions include:

kubent: kube no trouble
opa policy-bound pipelines: hard, but very rewarding if done correctly

Preview Environments

Preview environments are environments that are automatically spun up.

In our case, we do this through Pull Requests.

On every pull request against a branch, a label kicks in, and ArgoCD (through ApplicationSets... angry) creates a new application and automatically syncs it. After that, through the use of ASO (Azure Service Operator) we provision a database.

Upon a pull request close, the application is automatically deleted, and with it, the resource managed through ASO, too.

Two other possible ways to achieve this are:

cnpg operator: it connects to a live database, dumps the database, and provisions it. Authentication happens through external secrets.
PVC + Snapshot

With preview (or dynamic as I like to call them) environments, developers have instant access to a staging environment, automatically provisioned for them, with their pull request. Very powerful.

Subtleties

Here are important subtleties many engineering teams, even though good, often fail to deliver on:

ArgoCD configuration: should happen programmatically, this is a common chicken-egg problem, which I personally solve by having the entire ArgoCD helm locally, pointing to it from inside the ArgoCD, which I provision through CI/CD manually the first time. This applies to the master CI/CD. In a child-instances configuration, all child ArgoCDs are managed through the master. Through GIT. Then the rest, like projects, groups, roles, policies... all should happen in your k8s repository.
Cluster Apps: I use the app-of-apps pattern, which I achieve with either Kustomize or Jsonnet. Kustomize is often easier to maintain. I do not use ApplicationSets because it is harder to apply my name suffix & variability philosophies there.
State: Always remote
IAM: Always in either Terraform or the k8s (for ArgoCD) repos. Always add to groups. Do not apply one-time assignments.
Secrets: I always strive to use OIDC. Expired secrets suck and OIDC is an incredible technology that solves this.

Another important thing is expertise. I personally have been shooting educational videos of how our entire platform works, every couple of months. I have also made the following docs:

required-tools.md: kubectx/kubens, az cli, tf cli, etc. etc.
onboarding.md: here I explain the concept of variability, the variables for our organization, and link to a short video where I demo the concept by finding a resource in both Azure and in the Terraform repository, and make a small application configuration through the k8s repo, and an application repo.

Those have proven to be very valuable as we onboarded 10+ people through them.

So.. the conclusion is, "find someone who is willing to teach".

Closing

Thank you for reading and I hope you learned something, got inspired, or fired up. Either way, I enjoyed writing this.

Denis

out 🫡

Diffium found 4 great Golang contributors during Hacktoberfest!

kuberdenis — Sun, 05 Oct 2025 08:55:43 +0000

Hey guys! Denis here.

I am quickly passing by to thank you to the 4 maintainers that decided to put in the work and contribute to Diffium!

Here is the list of those absolute chads:

/ p.s. thank you for 36 stars :) /

Anyway, so, if any of you reading this have considered jumping in the Golang arena, feel free to explore Diffium's issues board and start working on any of the open ones.

Happy Hacking!

Diffium: The git diff manager for ai-assisted programming

kuberdenis — Mon, 22 Sep 2025 10:36:31 +0000

Hey all! How's everyone doing?

Listen.. I decided I want to maintain a repository for the first time in my life for this year's #hacktoberfest, so I decided to scaffold an idea I had and make it accessible.

So, if any of you friendly people feel like you wanna do some Go programming, feel free to check out diffium -- https://github.com/interpretive-systems/diffium

Also, who knows - maybe you'll get to start using the tool too haha.. I mean, honestly, I think it's quite nice and it's actually the first tool I build for myself that I actually use every day lol

onDocker[v0.1]: Personal Reflections

kuberdenis — Mon, 10 Feb 2025 14:46:55 +0000

As with any big company / technology, there are mixed opinions about Docker on the internet. It is only natural for a product to be good in something and bad in something else. And it is natural for a product to have competitors doing something better.

In this short post I would like to go over my views about Docker as both a technology and a company. I will try to return my personal tape back to a point where I first got introduced to containers and give my best to put my thoughts into words.

I think Docker is a good company and I think Docker can be a very good product.

From an engineering perspective, I think when one gains enough relevant engineering experience, there are better solutions out there - for both container runtime and local development.

And for the juniors out there, I consider Docker to be the best introduction to the world of containers.

Series Preword

Ok, so I got accepted as a Docker captain and it's been quite some time since I was supposed to make my first contribution so here we are.

I want to turn this onDocker thing into series and push out one article per month.

I don't have any plans yet as to what exactly I am going to create content on but one thing I am certain of - I need to deliver. So if you (reader) ever think of something docker-related, please let me know and I'll probably include it in an episode of onDocker

Computers, Virtual Machines, and Containers

When I was a teenager all my experience with virtualization was what you would typically expect from a teenager - VirtualBoxing Kali Linux, then VMWare-Workspacing Kali Linux, then USB-ing Kali Linux. Nothing Less, nothing more.

At the time I did not really care about any of this, I was just happy I did something techy.

Then I became a SysAdmin and stuff changed... they changed.

Junior to Mid: I am scared of containers

In my first job I was lucky enough to not be in a tech support role but directly jump in on actual system administration. The technologies I used varied a lot - different Linux distros, shady bash scripts, varnish, load balancing, redis sentinels, backup tools, and so on.

The company I worked at had their entire customer setup in VMWare vSphere and I was basically introduced to cloud computing the oldschool way now look at as "self-hosting customer applications".

Until one time I entered a server but there was no webserver installed on it. No Apache, no Nginx. There was no database either. Not even /var/www. "Wait, what?!", I thought. And then a colleague told me to run docker ps -a.

And this is when I got introduced to containers, one year into my tech career.

Docker Community & Developer Enablement

So naturally I used my free time to learn more about Docker at home. Yes, not about containers, but about Docker.

Since I already had some basic experience in web development, I first containerized a plain HTML website (lol).

I had a DigitalOcean droplet for remote development so no Docker Desktop yet.

Then I tried solving a more complex case, like trying to load-balance an OpenVPN connection inside Docker. My colleague decided to play a trick on me and gave me this task. Naively I jumped in and spent three days trying to figure it out but ultimately failed to create a real load balancing solution. I ended up with a half-baked emulation of availability consisting of one HAProxy container, and two OpenVPN-server containers. It looked like I was doing load balancing but there was no session persistence, no state, nothing.

And here I have my first two positives about Docker:

Strong Community: I was able to get so far at the time in most parts because of the great community I found online and countless tutorials present.
New Development Abilities: I was able to use my own machine as a VPC (virtual private cloud) - I did not need multiple VMs, I could craft whatever architecture I wanted on one single VM.

Diving Deeper

Docker then largely contributed to my success in getting my second job as a Jr. DevOps engineer only one year after starting my career. At the time (2019-2020), I believe containers as a technology was not so widely used, or at least not here in Bulgaria.

Anyway, so I got my second job and had to dive deeper.

I got to use different areas of Docker:

Docker Desktop
Docker CLI
Dockerfiles... a lot of Dockerfiles
Multi-Stage Dockerfiles

And now that I reflect back on this, I again give my props to the company Docker for doing what they did to flood the internet with knowledge about containers (doesn't mater if from a marketing perspective, or for the love of the community) and making the technology easy-to-use from a consumer / developer perspective.

I didn't even know but the Docker CLI was actually the first "abstraction" over the harder-to-grasp linux-containers' lxc. I never personally worked with lxc but doing a little investigation writing this article, it does not look like a pleasant experience.

And while some would argue abstractions are bad, I find them to be a good thing. They serve as auxiliary wheels, making what seem impossible, actually possible. Once one has to focus on the core, which would usually take years, then it is my opinion that it becomes important to context-switch, let the abstractions fade away, and do your own time in the trenches, crafting "your own abstractions". But this is a long topic. And it would require me to do a lot more deep thinking before reaching any definitive opinions.

Mid to Senior: I love containers

Right. So in my 2nd - 3rd year in tech, I became more and more capable, started attending Hackathons, and started working with Kubernetes.

Me and a very good friend of mine / hi, Bobby! / once attended a pretty huge prize-pool hackathon and actually managed to win 1st place by utilizing Docker Compose, Docker Volumes, and Docker Network. So again - doubling down on developer enablement. We crafted a Minecraft load-balancing solution on the Hackathon hosts' networking product.

I also started using Compose more for local development at work when I did not have access to my customers' environments. Something that I would otherwise not thing of - to recreate the whole architecture locally so I can work on a feature / fix.

I remember shortly before I would get hired as a senior, I read somewhere that Docker is "no longer free". What does that mean, I thought. I did not put much attention into this, but I remember this was one of the first times I thought, "Docker might not be as good as I thought". But now I completely justify their decision. I mean why would they not start taxing their enterprise customers? I would too. Hashicorp did too. As good as it sounds to live in a world where the only "currency" exchanged is the work we do together, our real world simply does not work that way. And when it comes to corporate-to-corporate, I would believe the only natural progression would be to start taxing your customers. After all, your customers are completely free to decide if they want to pick you over your competitors. And this applies to Docker too.

More on this later but I look at Docker as I do on Ubuntu - Ubuntu is far from a perfect distribution but it is the one with the most tutorials online, it has the easiest hop-on onboarding experience, and it simply works even if it isn't the best in terms of performance and being overloaded with packages.

What I am trying to say is developer experience & community is important. Especially for people not too keen on configuring something from scratch (as with colima for e.g.).

Oh, and one more Junior - Mid-Level positive:

Docker Hub: pretty cool and definitely goes right into my "developer enablement" section

Senior to Beyond: Doubt Taking Shape

So. Here I am writing this post, employed as a senior for 2 years already. What do I think about Docker now that I have spent so much time in tech? Well, that would depend on the quality or rather the activities I spent time on.

Even in my senior years, I still notice the developer enablement is still there for me. Crafting Azure DevOps pipelines, there is the Docker@2 task making it easy to build & push containers. For development and test environments that does not have public internet access, Docker is still my go-to choice.

The day I started doubting Docker came when I saw that my disk space severely degraded and I had a hard time understanding what is causing this case. It turned out that I had orphaned images, like.. ghost images and logs that took ~50GiB. I am not a Docker developer of course but I think a "system check" would not be too hard to implement.

Another "panic moment" I remember was when Kubernetes ended support for Docker as a runtime. We did not get affected by it, except for the fact we had to plan carefully how we update our clusters. Anyway, k8s' post then really opened up a lot of doors for me in terms of knowledge expansion. I got to dive deeper into how Docker worked, gained more knowledge about Kubernetes and I was finally able to make the difference between a runtime and a container engine lol.

Recently I once again received a slap in the face when my Docker engine stopped working on my Mac. I was essentially forced to install Podman (and later colima) which was not exactly expected or wanted. And I just got into Docker plugins!!

Another thing I now don't feel so happily about is Docker Hub. I think it is too pricey and I like my container registry where my cloud is - on DO, AWS, or Azure. I also don't think it would make sense for enterprise because, again, it's far more convenient keeping the CR near the infra.

Conclusion

Yeah, so after all I think Docker is superior when it comes to containers devex. And I think the team understands that, hence the plugins, articles, programs, etc.

For production, I don't think there is any discussion to be had unless it shifts into a discussion of containers vs [ something ] since containers, wether built with Docker, Podman, colima or whatever are treated the same way inside a container orchestrator. It would be a discussion of packaging software.

And one more thing. Writing this article made me realize companies actually posses enormous power over how the industry is being shaped. I think what Docker is doing is good and I think they play their part in the evolution of development quite well. Deep-knowers will go on and fix micro-areas of Docker that the company wouldn't prioritize to fix and this is a good thing. This is how progress is generated - through disagreement and agency. Through competitiveness.

So as everything - apply layers to your thinking, be able to context-switch, and don't draw your opinions from a single source of truth, for there is no such thing.

And that's it. That's the first article in the onDocker series. Again, since I don't have any strict plan on what I am going to write about, let me know if you have any preferences.

Thank you for reading, friend.

p.s. this article is a direct 1 : 1 of my thoughts : words. i did not apply any post-processing whatsoever so it might feel off. no idea. just oneshotted it. lmk how it felt. peace

I built a global chess board from scratch completely with Claude (NextJs & Firebase)

kuberdenis — Wed, 31 Jul 2024 17:46:25 +0000

First off, I am not a developer irl. I am a DevOps Engineer (senior btw). Regardless coding I have always been self taught and never had the attention span to complete a full course. I've always been building and never had the validation from a real developer if the things I do are bad or not.

With that being said, I have no idea if the code in the app is good or not. What matters to me is that it works.

This post is me sharing my fascination with the whole process and the result.

Also, if you'd like to look at the code to evaluate it, here is the github repo - https://github.com/kubeden/globchess-next-public

The app

The app in question is globchess.com - a global chess board anyone can make the next move on.

Here are the technologies used in the app:

Firebase: client + firebaseAdmin
NextJS: NextAuth.js, React
Stripe: stripe api...
Platform: ArgoCD, Kubernetes (ingress, deployment, service), Nginx Ingress Controller, Cert Manager, External DNS, Cloudflare, Github Actions

Here are the concepts I learned while building the app:

JS: Web Workers; Client Versioning
NextJS / React: useState, useReducer, useRef, unsubscribe logic, React Portal, NextAuth.js, JWT, session token decoding
Firebase: onSnapshot, collection, query, transaction

I was astounded with the level of intelligence Claude displayed. It was able to implement any feature I wanted it to, or fix any bug that appeared along the way.

Here is a list of all the features:

Routing
Authentication (+session token decoding)
Chess board render (with the Chessboard.js library)
Make a move logic (with the Chess.js library)
Board orientation swap logic
Squares highlighting
End game logic
Save finished games
Browse through past moves (both on live table and on past games)
Lock & Unlock board logic
Move Accuracy
Rating
Winning chance for both white & black
Stripe webhooks logic
Stripe to token after payment logic
Sidebar components for Profile + default sidebar
Live chat + system messages for game updates

I probably forget something. I most certainly am.

The process

The LLM code-in-english process is quite simple, very chaotic, and strangely... rewarding.

When I started the project, I entered the same prompt I always start with:

I want to create a [ thing ] with [ framework ]
Imagine I am a junior developer and you are an experienced senior developer. Help me with EACH STEP of the development process.
I want to start with the following:
[ basic feature ]
[ basic feature 2 ]

And then I would refine with:

[ x ] doesn't work, I want it to [ explain what I want it to look like ]
> paste of the entire component / page

And then... this same thing over and over again. This is really everything there is to it. I know this sounds underwhelming. It is.

prompt --> copy/paste --> prompt --> copy/paste

I would like to note down an important detail I found makes a huge difference coding with LLMs. I found it is very important to read through the responses, understand what the LLM is outputting, and if you don't understand a concept - either ask the LLM in a new tab or google it. Understanding what you are copy-pasting is crucial down the road. If you do not understand what you are pasting, at some point you would be unable to prompt anymore and your project will die.

Conclusion

Yes, this post was short. Yes, it was also underwhelming. Just as underwhelming as coding with LLMs is. But you know what? You thought - hey, now I can build an app like this. And you will probably give it a go. And you will succeed.

So in a sense this post provided just as much (little) value as an LLM would.

Just like an LLM would...

Juniors Are Doomed And This Is Good (LLMs Hype, Copilots, and The Turning Point)

kuberdenis — Tue, 25 Jun 2024 19:53:22 +0000

TL;DR
get good or quit tech

Junior Engineering Is Hard

A junior engineer is a person who is just starting in tech. Be it frontend, backend, or operations, it is a person just starting out. How can you distinguish a junior engineer from a mid-level or a senior? Quite easy, actually. Here are the top 5 signs to catch a junior:

Highly intensive desire to talk about tech
Iressistable need to express an opinion
Constant questions that can be googled
Aggressive display of superiority over non-tech acquaintances
Constant, loud, neverending, ear-numbing, complete and utter yapping

Ah, yes. The junior engineer, an alpha speciment indeed.

But what exactly are junior engineers doing in their daily worklife? Well, this has been a hot topic since I have been in tech. Let's explore more by looking deeper into three categories:

Frontend
Backend
Operations

Frontend

Requirements for a junior frontend engineer role:

HTML/CSS: Proficiency in HTML5 and CSS3, understanding of web standards, and responsive design principles.
JavaScript: Good knowledge of JavaScript (ES6+), including DOM manipulation and JavaScript frameworks/libraries such as React, Vue.js, or Angular.
Version Control: Familiarity with Git and GitHub or other version control systems.
Web Performance: Basic understanding of optimizing web applications for maximum speed and scalability.
Cross-Browser Compatibility: Understanding of how to ensure consistency across various browsers and devices.
Debugging: Basic skills in using browser developer tools to debug and profile applications.
API Integration: Experience with RESTful services and APIs.
Build Tools: Familiarity with build tools such as Webpack, npm, or Yarn.

You need to know HTML and CSS. You need to know JavaScript. You need to know your way around a library like React. GIT. SEO and PageSpeed Insights. Tailwind, Bootstrap, Flexbox, Grid. Be able to write unit tests. REST, CORS, data transformation. Builders.

Often you will also be required to understand UI/UX principles. You will need to participate in scrum and agile rituals. You will also find yourself bashing your head against technologies like Docker, be required to at least once troubleshoot a CI/CD pipeline in Github Actions, Azure DevOps, or Gitlab, and worst of all - experience the absolute horror of rebase and merge.

All of this while nobody takes you seriously because you are only doing frontend.

Takeaway: being a frontend sucks.

Backend

Requirements for a junior backend engineer role:

Programming Languages: Proficiency in one or more backend programming languages such as Python, Java, Ruby, Node.js, or PHP.
Database Management: Understanding of relational databases (e.g., MySQL, PostgreSQL) and non-relational databases (e.g., MongoDB, Redis).
API Development: Experience in designing and developing RESTful APIs and/or GraphQL APIs.
Version Control: Familiarity with Git and platforms like GitHub, GitLab, or Bitbucket.
Server Management: Basic knowledge of server, networking, and hosting environments (e.g., Linux, Apache/Nginx).
ORM Frameworks: Experience with Object-Relational Mapping frameworks like SQLAlchemy, Hibernate, or Django ORM.
Security: Basic understanding of security principles and practices, including data protection and authentication.
Testing: Familiarity with backend testing frameworks and tools, such as JUnit, pytest, or Mocha.
Containerization: Basic knowledge of containerization tools like Docker.

Again, you need to know a programming language. You need to be slightly (he-he) proficient in SQL, and NoSQL. You need to understand and be able to apply the concept of caching. You need to understand the difference between REST and GraphQL. GIT. ORMs (what even is this). S E C U R I T Y. Testing. Docker. Kubernetes. Packer. And so on.

Being a backend at least comes with bragging rights. You can also lie to your friends that you are a haxxer.

Takeaway: being a backend still sucks but has its perks

Operations

Opinion too long, too lazy to explain. read this as a start, more incoming

In short: operations guys are cool, aways have been, always will be.

We went over the roles, now the question - will there be junior engineers in the future?

No. Let me elaborate.

"Evolution, Dummy!"

Junior engineering hasn't always been like this. A few years ago, you would have done perfectly fine with just a programming language and a library.

What changed?

Evolution happened, dummy.

As with any other area of our lives, we evolved. A top performer will always inspire. Top performers through the years pushed harder and harder and left a mark with every push. We got inspired, and we tried to mirror their behavior, their achievements, and their success. Some of us could, others couldn't. But regardless of the outcome for each of us, we all collectively became better.

We entered a "new normal" of knowing more, raising expectations, and accelerating our field.

Sure, there has been a few cracks in the transmission like the mass layoffs after Covid but ultimately the machine is moving. And it's moving fast.

Should you be scared? It depends.

Ain't No Rest For The Junior

There will not be junior engineers as the ones we are used to observing and meeting around us today. The junior engineers of the future will be all-round experts. A guild of generalists, proficient in everything we are now struggling to get good at. Skill issues will not be in their dictionaries.

Claude (the hottest new guy on the block) and ChatGPT (even though in it's depressive phase lately) are the tools defining the reality of software engineering that is to come. The epitome of acceleration. LLMs make learning faster, more action-based, and the dopamine reward of succeeding in doing simple tasks is hooking millions of people to code. This allows for a more rapid development of candidates, and will also cut the unworthy.

If you can't do a task, you are not supposed to be in tech. If you are scared of LLMs "taking your job", you should find another job. The pressure will simply be too much for you to handle.

With this, I close my article and express my greatest respects to three individuals - John McAfee, Terry A. Davis, and Alex Mahan.

Peace.

The Art of Overcomplication: A Story of a Finished Failure

kuberdenis — Mon, 04 Mar 2024 15:11:47 +0000

It always starts with an idea. You test that idea. You see it is not impossible and you form a pact with yourself:

"I am not going to do anything more than just this one little thing. I will see how people react to it and based on the results, I will decide if it's worth the time. Just this one little thing. Just the MVP."

And you get to it. You start coding and you get through the POC phase, you prove to yourself that it works, and then you decide to focus on making your MVP.

While you focus on your MVP you find little flaws in your initial plan and start increasing the value (only in your head) of your MVP little by little by adding more features. You lie to yourself that those are just tiny upgrades and all of a sudden it hits you...

You lean back in your chair and take a look a good look at your screen.

It seems you now have an All-OS-Native, multi-cluster, microservice-themed, redundant and highly available, cloud native SaaS platform...

Your side project is now a monster. And you, dear reader, are Frankenstein.

Why Side Projects Fail You

I think coding products / apps / games / etc. alone doesn't allow you to invest too much. It is very important, in my opinion, to build one quick POC, polish your MVP, then ship as fast as possible. After your launch, it is best to take a look at the statistics and if your customers are positive, that might be an indication to continue spending time and resources on that project. Otherwise - onto the next one!

However, it is often very hard to stay biased when you are overtaken by the euphoria and hype that rushes through you when you successfully implement a few features and prove to yourself you can do it. This is exactly what happened with me.

In the next few chapters, I will briefly explain what happened with my side project (globchess.com) and hopefully shed light on common traps that you might face with your side projects.

Additional Resources

More in-depth version of this article in the form of a story - soon / not finished yet
Excalidraw diagram of my architecture and notes - link
Github repository with the code for the project - link

Bad Code & Its Consequences

I started to write the code for Globchess on a static index.html file with Live Server to simply check if I am able to create a chessboard. Since it was simply a farfetched idea which I didn't believe I was capable of executing, I heavily relied on ChatGPT and found chessboard.js and chess.js - the two libraries which made the project possible.

My First Mistake: No Modularity

I coded the skeleton for my web app inside my index.html and started coding in an index.js file. This was my first mistake. I quickly put 300 lines of code (most of which copied from ChatGPT) inside my single JavaScript file and did not think about breaking it down into modules or using a framework like React / Next that would make my life much easier in the future. Instead, I was blinded by the success of coding feature after feature and soon I had an unmanageable 300+ lines of code in a single file.

Notes:

Good for POC but I should have archived that and started all over with planning in mind

My Second Mistake: No Architecture

While I still had about 200-300 lines of code in my single JavaScript file, I could have stopped for a while, do a little research on what type of database I should use, weight my options for frameworks and quickly refactor my code so that it is readable, manageable, and clean. But I did not do that.

Instead, I asked ChatGPT to help me use Firebase Firestore and Firebase Authentication to code my auth and database logic. This turned my single index.js file into 500-600+ lines of code now. Horrific.

Not to mention "real-time database" would be a better solution for my needs. I could have also used socket.io.

Oh, and I think it is good that I mention now that I am quite proficient in Laravel and have done all my other projects with it. Why did I even decide to go with Node.JS this time?

Notes:

No architecture in mind
Blunt trial & errors are not good for your MVP phase (that's for the POC)
Do your research and choose wisely
If you are comfortable with a framework / library, why run from it?!

My Third Mistake: No Security, No Backend Validation

On top of doing it all in a single JS file, I did not think about backend for a single second. I was seeing the features I want to see work and I continued building on the frontend. No backend validation, no security considerations, nothing at all. Not even good routing. I was serving static html files.

I didn't even thought it was possible for me to miss things like that but again - success makes you blind. And my blindfold was me succeeding to code features I thought I couldn't.

Notes:

Think about security
Think about validation
Your feature "working" with frontend-only code doesn't mean that's enough

Consequences Of My Mistakes

At some point I leaned back in my chair and realised I had a completely unmanageable, unreadable, and performance-low code in front of me that was already doomed.

Implementing features started becoming way too hard because I couldn't easily read my code. I tried to break it down into modules and once I nearly succeeded in that, I realised I don't have any backend validation and my webapp is full of security flaws that the worst hacker could exploit. My average load speed was about 20 seconds which I don't even want to comment on.

And at this moment, I gave up. I fixed a few bugs to make my project somewhat presentable and decided to call it a day.

And that's the story of my finished failure.

Conclusion

Building products alone could be euphoric in the beginning but staying blind due to your hype sets you up for a path of failure. Be biased, plan the execution of your projects and know when to stop with adding new features. Stay true to your MVP and ship fast.

Keep to your metrics and continue doing what you like. I tried building an HR platform but I was not at all passionate about it so it took me 1 year to build it. Globchess took me about 10 days and it is way more heavy in terms of features.

If you read through the end, thank you for your time. I couldn't write about all the details along this project but I am working on a longer version of it. If you are interested, stay tuned.

My name is Dennis (kubeden) and I blog about DevOps, my side projects, and more.

If you feel like chatting, feel free to do so on x.com/kubeden.

C'ya!

Introduction to Helm: Comparison to its less-scary cousin APT

kuberdenis — Fri, 09 Feb 2024 10:01:44 +0000

In this short introductory blog post I share a short story of the time I started working with Helm and why it felt horrifying. After that, I jump in drawing the parallels between Helm and APT. I found this way to be quite easy for me to understand how Helm works so I hope it helps you too. Happy reading.

The horrors of Helm

When I first started working with Kubernetes I was overwhelmed by the "quietness" I felt working with the technology. Hare are the reasons why I felt this way:

No GUI, everything in the terminal
A lot of resource types
Long commands
Having to kubectl for every single little thing I want to check
Nodes, Load Balancers, Networking... AGAIN IN THE TERMINAL!

Generally I felt as if I was diving in the deepest of waters without the correct equipement and that was horrifying. Unfortunately to me, I had to dive even deeper before getting equiped with tools like ArgoCD, and k8slens. I had to start working with... HELM.

Imagine having to run HELM commands. 😂

Installing tens of resources in a namespace. And all those are... CUSTOM... RESOURCE... TYPES (I never heard of).

Anyway. Let's try to mitigate this potential situation from your life by going over the basics.

What is Helm?

Helm is a package manager for Kubernetes. This means you can install and uninstall software on your cluster with a few commands. Just like in Linux with apt get with HELM the equivalent is helm install

When to use Helm?

Well, you can either go with or without Helm. One thing is for certain though - once you start using it there is a high chance you will stick around.

I personally use Helm for two purposes:

Installing common software on new clusters. For example Nginx Ingress Controller and Certbot.
Templating Kubernetes packages on a base level for multi-cluster deployments.

Generally, I look at it as a good foundation material for my Kubernetes house. 😉

With this, let's jump right into the technicalities and see how to actually use Helm.

How to use Helm?

What I noticed with tool lately is that the learning curve is not that frightening. I usually find myself learning the basics and a few more advanced tricks and I feel comfortable working / playing around with the software. Same thing goes for Helm.

First you need to install it - intallation guide

After you install Helm, there are basics commands you need to know and for that I am going to draw parallels between those basic Helm commands and how they compare to APT.

helm repo add <software-name> <repository-url>: This command in Helm adds a new repository to your local Helm configuration. The equivalent APT command is sudo add-apt-repository 'deb [arch=architecture] <repository-url> distribution component. In APT, this command adds a new repository to the list of sources APT will use to fetch packages.
helm search repo <software-name>: This Helm command searches for charts in a repository. The APT equivalent is apt-cache search <package-name>. This command searches the package metadata in APT's repositories for a specific package.
helm repo update: This command updates the local Helm chart repository cache. The equivalent in APT is sudo apt-get update, which updates the list of packages available from the repositories defined in /etc/apt/sources.list and /etc/apt/sources.list.d/.
helm install <software-name>/<package-name>: This Helm command is used to install a chart. The APT equivalent is sudo apt-get install <package-name>. This installs a new package from the repositories.
helm list: This command lists all the Helm releases in the cluster. The APT equivalent could be dpkg --get-selections, which lists all the installed packages. However, it's important to note that APT doesn't manage deployments in the same way Helm does, so this is only a rough equivalent.
helm uninstall <package-name>: This removes a Helm release. The APT equivalent is sudo apt-get remove <package-name>. This command removes a package installed via APT.

Conclusion

Stepping into the world of Kubernetes and Helm can feel like a daunting journey, especially when compared to the more familiar territory of traditional Linux package management with APT. But as we've seen, the basic concepts between Helm and APT aren't worlds apart. Helm, like APT, simplifies the process of managing software, but it does so in the context of Kubernetes - a much more dynamic and distributed environment.

By understanding the parallels between these two tools, you can demystify the process of working with Kubernetes and begin to appreciate the power and flexibility that Helm offers. Whether you're managing a handful of microservices or orchestrating a large-scale, multi-cluster environment, Helm provides the tools you need to deploy, manage, and scale your applications with ease.

Happy Helming! 🚀🛠️

P.S.

Thanks for reading, friend! I write about DevOps, Programming, and share my thoughts about the tech industry. Oh, and sometimes I share stories of how tech helps me in some life situations (e.g. I hacked my neighbour's Wi-Fi because he was blasting loud music)

Follow me on X/Kubeden if you feel like chatting sometime.

Closing GIF time wink

Jsonnet Adventures: Deploying our application to ArgoCD!

kuberdenis — Wed, 31 Jan 2024 19:09:22 +0000

Hello fellow Kubernetes enthusiasts! In my previous blog posts we explored the basics of Jsonnet and how to use it to generate Kubernetes manifests. Now, I'm thrilled to finally get to the deployment of our production-ready, Jsonnet-templated application to ArgoCD.

Prerequisites

I am expecting you to have a basic understanding of ArgoCD and Kubernetes for this one. If you need a refresher, check out some resources online (before I create my own tutorials on these topics):

ArgoCD

Nginx Ingress Controller & Cert Manager

Before diving in, here's a quick overview of what you need to follow along:

Read through Jsonnet Introduction
Read through Jsonnet Adventures: Functions, Conditionals, and Advanced Templates
Jsonnet Templates Repository: All the Jsonnet templates in those tutorials are stored in kubeden/tutorials and you can use it as reference.
Application Repository: The source code for the Simple Node App is in kubeden/simple-nod-app. Yes, that is a typo lol
Docker Repository: The application's Docker image is available at kuberdenis/simple-node-app.

ArgoCD and Jsonnet

ArgoCD is a declarative, GitOps continuous delivery tool for Kubernetes. It allows us to deploy applications to Kubernetes using Git repositories as the source of truth. ArgoCD also supports Jsonnet, allowing us to deploy Jsonnet templates directly to Kubernetes.

I repeat - ArgoCD support Jsonnet out of the box! This is a huge advantage, as we can leverage Jsonnet's power to create dynamic Kubernetes manifests, and deploy them using ArgoCD.

The Deployment Process

Jsonnet Templates: Using Jsonnet, I generated Kubernetes manifests that are both dynamic and maintainable.
ArgoCD Application: I created an application in ArgoCD pointing to the simple-node-app repository with a path to my prd directory. With a simple sync of the application, ArgoCD deployed the application to my Kubernetes cluster.

The Result

The application, now live, dynamically greets users with the name provided in the YOUR_NAME environment variable.

Here is how the application looks like in ArgoCD:

And here is the application itself:

Now if we update the YOUR_NAME environment variable in the parameters.libsonnet file, and sync the application in ArgoCD, we can see the application dynamically update:

This small, yet powerful demonstration shows the flexibility and power of combining Jsonnet for templating Kubernetes for ArgoCD.

Conclusion

If you made it this far, thank you for reading! I hope you enjoyed this series and learned something new. I am planning to continue writing about Jsonnet and other Kubernetes-related topics, so stay tuned!

For the next Jsonnet post, I am thinking of diving deep into combining multiple templating languages and use Jsonnet + Helm to deploy Grafana and Prometheus.

Thank you for following along and if you feel like chatting, feel free to hit me up on x/twitter!

And drums ... closing gif!

Mastering the DevOps Interview: A Guide for Mid-Level Candidates

kuberdenis — Mon, 29 Jan 2024 14:46:36 +0000

In the first part of the series Mastering the DevOps Interview: A Guide for Junior Candidates I shared the observations I collected over 10 interviews of the DevOps interviews, focusing on the Junior role.

In this part, I am going to share what I noticed overlaps in Mid-Level DevOps interviews, and hopefully help you feel more comfortable in your job hunt!

I highly recommend to go over the first post in the series even if you are past Junior as there I have pointed out what the DevOps Interview Landscape looks like.

This article will be shorter than the Junior-level one as I am solely going to focus on what the interview might look like, technologies, and example tasks you might be given.

Interview Process

For Mid-Levels, I noticed the interview process most often goes as follows:

HR --> Technical Questions --> Technical Task --> Offer

The technical tasks are mostly of 'real-time' or 'homework' types.

Two other possible interview processes are:

HR --> Technical Questions --> Offer
HR --> Technical Knowledge Test --> Technical Questions --> Offer

Some companies rely on questions/answers while others rely on technical tasks. If you ask me, you should search for technical tasks interviews as in those you can actually shine and don't fall victim to the "automated selection".

Technical Questions

Strangely enough, the technical questions for mid-level roles do not differ too much from the junior ones. Although for mid-level roles how you answer matters more. While for a junior role you might say something along the lines of "Well, I am not quite sure but maybe ____," in mid-level interviews you are expected to be a way more confident and understand what the technical recruiter is talking about at all times. Sure, you might not be able to come up with a cloud architecture on the spot but you are expected to be able to swim freely in the DevOps world.

With this in mind, here are some of the most common topics you could face in your Mid-Level DevOps interviews:

Cloud - AWS (Services you should be able to converse about)

S3, EFS, EBS
ELB, NLB, ALB
RDS, Aurora, DynamoDB
ECS, EKS, Fargate, EC2
Cloudfront, Route53

Cloud - Azure (Services you should be able to converse about)

Keyvault, Storage Account
VNET, Subnets, NAT, Route Table, Load Balancer, DNS Zones
Virtual Machine, AKS
Managed Databases, Azure Databases
Application Gateway

Automation: Pipelines, IaC

Build Pipelines, Release Pipelines, Multi-stage pipelines
Dockerfiles, Multi-stage container builds
Terraform (init, plan, apply, workspaces, local vs remote state, aws state lock)
Ansible Playbooks

Containerisation

Kubernetes (Deployments, Services, Ingresses, Secrets, Nodes, PVCs, Storage Classes, ConfigMaps, Policies)
Nginx Ingress Controller, Cert-Manager, External Secrets, External-DNS, Grafana, Prometheus
ArgoCD (Projects, Policies, Roles, Repositories, Clusters, app-of-apps)
Microservice vs Monolith

Linux

While this list might look too extensive, you will notice if you spent some even one year working as a junior (at a good and enabling place), you would have probably covered near to or even more than 80% of it.

And with this out of the way, let's explore what technical tasks you might be given in your interview.

Technical Tasks

Similar to the technical questions, I noticed the technical tasks for Mid-Level DevOps do not differ that much than... wait for it... Senior level DevOps!

The difference comes in the extent of the tasks. How deep you go and how much material you cover.

Here is what you can expect as Mid-Level DevOps tasks in your interview:

Create a Dockerfile for an application (Python, Javascript, Dotnet)
Create a pipeline (Github / Gitlab / Azure DevOps) that builds the application and pushes it to a container registry
Create a pipeline that automatically updates an image version in a GIT repository
Deploy a simple application on Kubernetes (Deployment, Service)
Install and configure Nginx Ingress Controller (Ingresses) and Cert-Manager (Certificates, Secrets)
Create an Ansible Playbook that installs a LAMP stack on multiple hosts

Look! This is not that scary, right? I believe if you just do all of those tasks at home, and train so that you are able to replicate the results on any environment from scratch, you are a good mid-level DevOps engineer!

Conclusion

While Mid-Level DevOps interviews might look scarier and cover a wider area of expertise, you are not expected to be a team leader, or a cloud architect. That means you are expected to have had experience in the topics from the "Technical Questions" section but not necessarily be a complete professional in all.

Be realistic about your experience and think about where you came from. This will for sure help you stay grounded in your interviews and not panic too much. If you are applying for a Mid-Level DevOps role, you definitely did your time in front of the screen so be proud of that and go proof your next employer you are worth the time!

I wish you luck with your interviews and as always - here is the closing GIF 😊

Jsonnet Adventures: Functions, Conditionals, and Advanced Templates

kuberdenis — Thu, 25 Jan 2024 16:48:53 +0000

Welcome back to Jsonnet series! After covering the basics in my previous post, it is time to delve into Jsonnet's more advanced features: functions, conditionals, advanced templating, and leveraging external libraries.

I'll showcase these through an update to our Kubernetes deployment setup, gearing it towards a production-ready (well... almost) application.

Prerequisites

kubectl cli: link
jsonnet cli: link
clone the Github repo: link
understand the Jsonnet basics: first post

Updated Files Overview

Before diving into the specifics, let's take a look at the updated files in our project:

/libs/applications.libsonnet: A new addition that orchestrates different application setups.
/libs/deployment.libsonnet: Enhanced to include environment variables in our production deployment.
/libs/kube.libsonnet: An external library from Bitnami, facilitating Kubernetes deployments (we'll focus on the List() function).
/simple-node-app/prd/apps.jsonnet: Our main deployment file, now integrating the new kube.libsonnet and applications.libsonnet libraries.
/simple-node-app/prd/parameters.libsonnet: Updated parameters, including environmental variables for our production deployment.

The New applications.libsonnet

We have added applications.libsonnet to allow us to easily manage our code, and create different types of applications. Here's how it looks like:

local deployment = import './deployment.libsonnet';
local service = import './service.libsonnet';
local ingress = import './ingress.libsonnet';

{
    basicApplication(p):: {
        [p.appName + '-deployment']: deployment.basicDeployment(p),
        [p.appName + '-service']: service.LoadBalancer(p),
    },

    productionApplication(p):: {
        [p.appName + '-deployment']: deployment.productionDeployment(p),
        [p.appName + '-service']: service.ClusterIP(p),
        [p.appName + '-ingress']: ingress.basicIngress(p),
    }
}

We define the application type we want, and set up the resources we want to deploy. This is a great way to organize our code and make it more maintainable. We also moved the imports to the top of this file rather than having them in each application-specific apps.jsonnet file.

Enhanced productionDeployment in libs/deployment.libsonnet

Jsonnet contains powerful pre-defined functions and libraries that we can leverage to enhance our code. In our updated libs/deployment.libsonnet, the productionDeployment function utilizes the std.map() function to generate environment variables for our production deployment:

productionDeployment(p):: {
  // ... Other deployment details ...
  spec: {
    template: {
      spec: {
        containers: [
          {
            // ... Other container configurations ...
            env: if std.objectHas(p, 'env') then
              std.map(
                function(key) { name: key, value: std.toString(p.env[key]) },
                std.objectFields(p.env)
              ) 
              else [],
          }
        ],
      }
    }
  }
}

This addition dynamically generates the necessary environment variables for the container from the parameters file, and uses a conditional "if" to check if the parameters file contains an "env" object. If it does, it will generate the environment variables, otherwise it will generate an empty array.

std.objectHas and std.map are only two of the many functions available in Jsonnet. You can find the full list here.

The kube.libsonnet - List() Function

I've also brought in kube.libsonnet from the Bitnami kube-libsonnet library to further empower our Jsonnet scripts.

In this tutorial, we are only using its List() function, which helps us bundle the resources we want to deploy into our (future) ArgoCD cluster.

More about the kube.libsonnet library later in future posts.

Integrating Everything in /simple-node-app/prd/apps.jsonnet

In /simple-node-app/prd/apps.jsonnet, we now have a simplified deployment file:

local applications = import '../../libs/applications.libsonnet';
local params = import 'parameters.libsonnet';
local kube = import '../../libs/kube.libsonnet';

kube.List() {
  items_: applications.productionApplication(params)
}

Notice how we now import only the applications rather than all the individual libraries. This way the deployment process becomes more readable and manageable using the kube.List() function. This will generate an ArgoCD-ready application manifest which we can deploy to our cluster.

Updated parameters.libsonnet

Finally, the parameters.libsonnet has been updated to include environmental variables:

{
  appName: 'simple-node-app',
  environment: 'prd',
  replicas: 3,
  port: 8080,
  imageTag: 'latest',

  env: {
    NODE_ENV: 'production',
    PORT: 8080,
  },
}

It doesn't matter if we want one, two, or 15 environment variables. Because of the std.map() function, our productionDeployment function will generate the necessary environment variables for our container.

This is just how powerful Jsonnet really is.

Conclusion

In this post, we updated our codebase using Jsonnet's more advanced feature and hopefully started feeling more creative! We also added an external library, and are getting ready to soon start deploying our applications to our Kubernetes cluster.

In the next post, we will take a look at how ArgoCD handles Jsonnet, and how a simple ArgoCD application built with Jsonnet looks like.

I hope you learned something and if you feel like chatting, connect with me on X or hit me up with a comment below!

Closing GIF time!