Hacker Newsnew | past | comments | ask | show | jobs | submit | x3n0ph3n3's commentslogin


Not only will you need a team of DBAs caring for it, but you'll never be able to hire them.

No organization I have seen prioritizes a DBA's requirements, concerns, or approach. They certainly don't pay them enough to deal with that bullshit, so I was out.

This. k8s is primarily resume driven development in most software shops. Hardly any product or service really needs its complexity.

To replace Kubernetes, you inevitably have to reinvent Kubernetes. By the time you build in canaries, blue/green deployments, and rolling updates with precise availability controls, you've just built a bespoke version of k8s. I'll take the industry standard over a homegrown orchestration tool any day.

We've used ECS back when we were on AWS, and now GCE.

We didn't have to invent any homegrown orchestration tool. Our infra is hundreds of VMs across 4 regions.

Can you give an example of what you needed to do?


Really? What deploys your code now? I'm SRE, walk me through high level. How do I roll back?

It used be Google Deployment Manager but that's dead soon so terraform.

To roll back you tell GCE to use the previous image. It does all the rolling over for you.

Our deployment process looks like this:

- Jenkins: build the code to debian packages hosted on JFrog

- Jenkins: build a machine image with ansible and packer

- Jenkins: deploy the new image either to test or prod.

Test deployments create a new Instance Group that isn't automatically attached to any load balancer. You do that manually once you've confirmed everything has started ok.


ECS deployments. Automatically rolls back on failure. Not sexy but it works reliably.

The amount of tools and systems here that work because of k8s is signficiant. K8s is a control plane and an integration plane.

I wish luck to the imo fools chasing the "you may not need it" logic. The vacuum that attitude creates in its wake demands many many many complex & gnarly home-cooked solutions.

Can you? Sure, absolutely! But you are doing that on your own, glueing it all together every step of the way. There's no other glue layer anywhere remotely as integrative, that can universally bind to so much. The value is astronomical, imho.


Yeah, but ansible is one of the nine circles of hell and its support for various AWS services beyond EC2 and S3 is near nonexistant.

I have mixed feelings about it. On my first startup, I used ansible to automate all of the manual workflows and server setup that we had done. Everything was just completely manual and in people's heads before, and translating it to ansible was a pain in the ass to say the least. I don't think it would have been any easier to translate it to something else though. It ended up working fine and we had a solid system that I could reset up our environment from scratch on a set of VPS provided by some terraform scripts. We were originally on digitalocean, and had to migrate to Azure because of acquisition BS.

For my current startup I ended up not going a direction where I needed ansible. I've now got everything in helm charts and deployable to K8S clusters, and packaged with Dockerfiles. Not really missing ansible, but not exactly in love with K8S either. It works well enough I guess.


> on a set of VPS provided by some terraform scripts

You ended up needing Terraform too for the infrastructure though. At that point why not just use Terraform?


Terraform was just for interacting with the cloud provider and spinning up the servers. Ansible was responsible for deploying all dependencies and getting the servers actually ready for use. Remember, none of this architecture was dockerized.

I had originally used Ansible to interact with the cloud provider and do the provisioning too, but someone on the corporate infrastructure team wanted to use terraform for that instead, so they did the migration.


I also have experience with using Terraform and Ansible like this. Once I realized that most of the work actually performing the setup beyond blank VM creation was in Ansible, I was much more interested in just using Ansible for everything.

My opinion is there are not enough good software developers doing DevOps, and HCL is simple enough and can have pretty good guardrails on it. My biggest concern is people shooting themselves in the foot because the static analysis tools available for HCL don't work with Pulumi.

It’s an unfortunate truth that good software developers aren’t crazy enough to want to do it.

This was very insightful. I've only just begun playing with some agent workflows and building out documentation to help it navigate my code base. Asking it to give me the top 10 unanswered questions from analyzing the docs and code was very useful.

YAGNI is the best tool in your toolbox for AI agents. Dont build out what you think will be useful, layer things into your AI toolbox as they prove they are needed. Especially for claude, running `/init` ends up with a lot of really unnecessary/hallucinated info. Keep it all simple and layer on top.

That happened the first time I clicked, but it is back.


Advise from low-quality bootcamp-like training programs that encourage open-source contribution, providing low-quality examples of such contribution, in order to improve one's resume and career chances.


Must be a strong headwind!


Multiple neighborhoods have no data, including Lakeside and Stonestown.


Good flag. I've just added add fallback to the nearest location with a sensor to the repo.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: