Thanks for your feedback on the title of my article. English is not my first language, and in my native tongue, the distinction between “learnings” and “lessons” isn’t as pronounced in this type of context. I appreciate the nuanced perspective and will probably update my title . My main goal is to share the experiences we’ve gathered over the years, and I hope that the essence of our journey with Kubernetes shines through, regardless of the terminology.
Sorry for being unclear on this. In our case, we needed a couple of engineers who, in addition to their regular duties, would devote their time to Kubernetes as the go-to experts whenever necessary. Some weeks there was nothing to do; other weeks, particularly during cluster updates, they needed to focus exclusively on that work.
Thanks for clarification. On one hand I’m happy about you sharing this experience. On the other hand, I still feel we can’t assess the true value as it would require disclosing important information that you’d likely not be allowed to share.
Let me know what you're interested in learning more about, and I'll see what I can share. If you're looking to dive deeper into specific details, we could discuss them further in a video call or similar.
I appreciate the offer to me personally but I was thinking about another public blogpost that goes into great specifics such as requests per second, cpu load, user base, but it's so app-specific that even then it's difficult to assess.
What I do notice - and I'm not saying this is true for you (I don't know) - is that people get excited about technology like kubernetes or something equivalent, but it creates an additional burden that is totally not proportional to the benefits of said technology.
Stupid load-balancing proxy servers with a bunch of hosts behind them is extremely uninteresting and boring. But it's dead simple, so reliable and easy to scale horizontal or vertical as well.
And most of all: how much do you save by dynamically upscaling and downscaling as opposed to just keeping a static environment.
If you want to share that kind of perspective, I'd rather see a public post about it that others may benefit from.
25% of the first 4GB of memory,
20% of the next 4GB of memory (up to 8GB),
10% of the next 8GB of memory (up to 16GB),
6% of the next 112GB of memory (up to 128GB),
2% of any memory above 128GB
"AKS reserves an additional 2GB for system process in Windows nodes that are not part of the calculated memory."
