ghomem

True story ^^^^^

Add to this, that you can have outages due to operational complexity, which tends to happen in complex cloud native setups.

People want simple answers. "It depends" annoys everyone :-\

>I wonder if there is some major propaganda push on HN to discourage actual >software engineers from ever running their servers

How to scare a computer engineer in 2024? Invite him to configure a server.

Agreed, in general.

But don't forget about the definition of micro :-) This is an optimization problem rather than a conceptual one.

Thanks for sharing the story. Despite the whole TCO being higher, I wonder how the 8K to 6K reduction happened.

On AWS, fargate containers way are more expensive than VMs and non fargate containers are kind of pointless as you have to pay for the VMs where they run anyway. Also auto scaling the containers - without making a mess - is not trivial. Thus, I'm curious. Perhaps it's Lambda? That's a different can of worms.

I'm honestly curious.

> There's also an even bigger problem that can arise, the distribution can just end, such as the termination of CentOS

If you are doing something serious you probably want to chose suppliers in such a way that you can demonstrate you have security and business continuity under control. That means you probably want to use RHEL, Suse or Ubuntu, distributions for which commercial support exists.

(Ubuntu is particularly interesting because you can start with an LTS release for free and activate commercial support if business goes well, without changing your processes.)

You can think about this beforehand or wait until customers require some kind of certification and the auditors ask you for your suppliers list + the business continuity plan, among other things. You will face this if you deliver to a regulated market or if your customers are large enough to self regulate this kind of thing.

LTS not good enough? Well, cloud native does not have LTS comittement and Pipy does not provide security fixes separated from logical changes.

Try to keep your Terraform code stable for two years in AWS, or try to understand the lifecycle of AWS Glue versions from the docs. Or trust that Google will not discontinue their offers :-)

I mean, maintaining software is never easy or effortless but I respect the effort done by LTS Linux providers - they sell stability and security for a fraction of what you pay for cloud native.

>reproducibility isn't just on your deployments, it's for development too

Absolutely. Adhoc configurations should be forbidden! It is easy to ensure dev env reproducibility when you run Linux. If you have config management your devs can have VMs that subscribe to the same exact configuration that the staging prod and dev environments have. They can literally have a deplpyment server in their machine, as a VM. Since the configuration is stored on a server and applied continuously, it is hard to screw it.

You can achieve this with Docker as well, if the arrangement is not too complex.

The problem, at least in my experience, comes when you start depending on several cloud native components where local emulations are always different from the real cloud env in tiny details that are going to screw the deploys over and over.

My thoughts and prayers :-\ Wish you a quick recovery!

Thank you as well, for sharing these notes about your setup. Indeed concentrating everything in the same monitoring system is very helpful as it reduces the cognitive load. You can likely do the same with Icinga.

Feel free to reach out on Linkedin if you need some more details. More than happy to share.

> Honestly I just think you should be more generous

I am generous in the context for generosity. Turns out that engineering is not about being generous but rather about choosing the most efficient solution for problems that in the end need to be business driven. This requires evaluating requirements, context and tradeoffs. That takes a cold, rational mind more than generosity.

> K8s really does address real problems around deployment and it's very well thought out

It's great where it makes sense. It's less than great elsewhere.

Not everything is SaaS, not everything needs scaling, not everything needs 99.99% of uptime, not everything needs a CDN, not every company is VC backed operating at high risk / high reward, etc, etc. Context is better than ideology. If you read the article I posted you will see that stated clearly.

> Good luck finding someone to understand what that 'custom Naemon' plugin is doing.

You Kubernetes people get triggered very easily. I was already lucky to have found several juniors that worked in this kind of thing with minimal training. The 'custom Naemon plugin' is 30 lines of bash and you can adapt it to any monitoring system.

Of course this is scary and complicated. I might consider switching to 'Kubernetes operators', which sounds simpler :-)