Live data from Hacker News

Ask HN: Startup Devs -What's your biggest pain while managing cloud deployments?

news.ycombinator.com

51–60 of 96 posts

Re: Ask HN: Startup Devs -What's your biggest pain while managing cloud deployments?

#51
Full disclosure I work at a company [1] attempting to address this very problem.

Without dedicated devops the challenge is allocating developer time to do the integration work required to get the various ops tools playing nicely together. In my experience that work is non-trivial and eventually leads to some form of dedicated ops.

That is also part of a dynamic -- lots of tools available for solving these problems exist because of dedicated ops. It's not easy for a team trying to build software to also take on these extra operational responsibilities.

What we're trying to do is create a highly curated set of what we think of as application primitives. These primitives include CI/CD, Logs, Services, Resources etc. Because they're already integrated it doesn't require developers to figure out API keys, access control, data synchronization, etc.

1. https://noop.dev

Re: Ask HN: Startup Devs -What's your biggest pain while managing cloud deployments?

#52
- Keep it simple. Cloud providers offer hundreds of services - just because you can use them doesn't mean you should. A simple Docker container or a small VM might already be enough for you, and it's a lot less moving parts.

- Document everything. Hacking together some cloud infra is easy, maintaining it is a completely different story. You want to have clear and up-to-date documentation on what exactly you have running and why. If you don't have good docs, it'll be impossible to scale, refactor, or solve outages.

- Make sure people are trained. Cloud infra management gets complicated real fast. You want people to actually know what they are doing (no "hey, why is the bucket public" oopsies), and you want to avoid running into Bus Factor issues. Not everyone needs to be an expert, but you should always have one go-to person for questions who's actually capable, and one backup in case something happens to them.

- Watch your bills. Every individual part isn't too expensive, but it all adds up quickly. Make sure you do a sanity check every once in a while (no, $5k / month for a DB storing megabytes is not normal). Don't use scaling as a "magic fix-everything button" - sometimes your code just sucks.

Re: Ask HN: Startup Devs -What's your biggest pain while managing cloud deployments?

#53
post #11

Killer one that has shafted us is tying everything into popular deployment and CI tooling. Your product should be buildable, deployable and tested on a standalone workstation at any time. We have lost literally days fucking around with broken products which get their tentacles into that shit. I'd use AWS + ECR + ECS personally. Stay away from kubernetes until you have a fairly large deployment as it requires huge adm…

> Also stay the hell away from anything which is not portable between cloud vendors. Doesn't ECS violate this? This is something I've preferred in theory about kubernetes. At least in theory, it's supported everywhere. But I have also wondered whether it would be just as "easy" in practice to move from ECS to another cloud, as it is with EKS. (That is, neither would actually be easy.)

The metadata and configuration does violate this but the containers are portable if you care enough to make sure that they don't depend on anything AWS specific.

Re: Ask HN: Startup Devs -What's your biggest pain while managing cloud deployments?

#54
post #11

Killer one that has shafted us is tying everything into popular deployment and CI tooling. Your product should be buildable, deployable and tested on a standalone workstation at any time. We have lost literally days fucking around with broken products which get their tentacles into that shit. I'd use AWS + ECR + ECS personally. Stay away from kubernetes until you have a fairly large deployment as it requires huge adm…

> Killer one that has shafted us is tying everything into popular deployment and CI tooling. Your product should be buildable, deployable and tested on a standalone workstation at any time

I've currently a VP Eng at a "growth stage" startup, and the state of things when I joined was that about 75% of a dev's time was spent fighting with the external services and data. Someone would spend an entire sprint on a feature, but most of the time was actually fighting with our IdP.

A huge effort and focus (that I had to beat into everyone's head) was that being able to a) run everything locally and/or b) have reasonable fakes for external dependencies means that we can spend far more time building actual product stuff and far less time debugging infra issues.

Re: Ask HN: Startup Devs -What's your biggest pain while managing cloud deployments?

#55

There's a lot of noise when trying to learn the advanced features of each cloud provider's "way of doing XYZ." I think it helps to focus on the things worth protecting: secrets, credentials, code. Who has access? How do we audit / rotate? How do we secure? You can use this approach for each step along the way, how to secure secrets in your cloud? code? IaC? container deployments? CI/CD? If we assume infra / app is co…

> There are examples like https://github.com/terraform-google-modules/terraform-exampl... of more advanced IaC architectures, but you can start as small or as complex as you want and evolve if done properly.

Is there something like this for AWS?

Re: Ask HN: Startup Devs -What's your biggest pain while managing cloud deployments?

#56
post #14

A year ago I left my job at a 500-employee SaaS business working on the team that maintains the devops infrastructure, to found a startup. For me the biggest pain point is going from nothing to a sufficiently flexible devops setup. There are a lot of great tools out there, but making them play well together is an exercise for the reader. There are also a lot of preference-based choices you need to make in how you wan…

> but there's some amount of extra stuff deployed (ingress controller, for example) that is documented in a text file

Out of curiosity, why just the "readmeware" for those components? I can't think of a single thing that requires clickops in a modern k8s setup, so much so that in the beginning we used to bring up the full stack from nothing based on a single CFN template - roles, load balancer, auto-scaling group, control plane, csi driver (this was back when EKS was a raging tire fire), and then lay the actual business apps on it. The whole process took about 8 minutes from go

If nothing else, one will want to be cautious about readmeware components in disaster recovery situations. If no one has run those steps in 6 months, and then there's some kind of "all hands on deck," the stress will likely make that institutional knowledge leak out of their ears

Re: Ask HN: Startup Devs -What's your biggest pain while managing cloud deployments?

#57
post #21

Earlier quoted context omitted.

We have been using https://www.red-gate.com/products/flyway/ with Postgres (via CloudSQL) for at least 8 years and are happy with it. Now that I looked at the website to share the link, I would probably be scared away because it looks very enterprise and corporate but it works well and it's just a Docker container built in CI and I don't have to interact with it.

I've used Flyway and it works great, can also recommend Alembic from the Python world - https://alembic.sqlalchemy.org/en/latest/

Flyway and Alembic are imperative, not declarative.

Imperative tools express schema changes as a filesystem of incremental "migrations", whereas declarative tools use a filesystem of CREATE statements and can generate DDL diffs to transition between states.

The declarative flow has a lot of benefits [1]. It is much closer to how source code is typically managed/reviewed/deployed, which is especially important for stored procedures [2].

However, using a purely declarative flow (as opposed to using a declarative tool just to auto-generate incremental migrations, which are then run from another tool) isn't necessarily advisable in Postgres, since Postgres supports DDL in transactions. So there's potentially multiple paths/orderings to reach any given desired state, as well as the ability to mix schema changes with data changes in one transaction. This means in Postgres there's often manual editing of the auto-generated incremental change, whereas in other DBs with fewer features this isn't necessary.

Disclosure: I'm the author of Skeema, mentioned in the GP comment.

[1] https://www.skeema.io/blog/2019/01/18/declarative/

[2] https://www.skeema.io/blog/2023/10/24/stored-proc-deployment...

Re: Ask HN: Startup Devs -What's your biggest pain while managing cloud deployments?

#58
post #7

That these days there are only two serious choices: deploy on a single-node Docker/podman machine, or Kubernetes. I can do both, but for a bootstrapped solo business, Kubernetes is overkill and overengineered. What I would really love is a multi-node podman infrastructure, where I can scale out without having to deal with k8s and its infernal circus of YAML, Helm, etcd, kustomize, certificate rotation, etc. Recently…

> Recently I had to set up a zero-downtime system for my app, I spent a week seriously considering a move to k3s, but the entire kubernetes ecosystem of churn frustrated me so much I simply wrote a custom script based on Caddy, regular container health checks and container cloning. Easier to understand, 20 lines of code and I don't have to sell my soul to the k8s devil just yet.

I'd say it depends where you're coming from. For me, setting up a Kubernetes cluster (no matter which flavor) with external-dns and cert-manager will most likely take 30m-1h and that is the basic stuff that you need for running an app with the topics you mentioned. To navigate through k8s just use k9s and you're golden.

I never get where all the "k8s is the devil" comments come from. There is nothing really complex about it. It's a well defined API with some controllers, that's it. As soon as I need to have more than one server running my workloads I would always default to k8s.

Re: Ask HN: Startup Devs -What's your biggest pain while managing cloud deployments?

#59

Full disclosure I work at a company [1] attempting to address this very problem. Without dedicated devops the challenge is allocating developer time to do the integration work required to get the various ops tools playing nicely together. In my experience that work is non-trivial and eventually leads to some form of dedicated ops. That is also part of a dynamic -- lots of tools available for solving these problems ex…

for others similarly curious, here's an example of the thing: https://github.com/noop-inc/template-java-spring-boot/blob/m...

they seem to be using the excellent lima https://github.com/lima-vm/lima#readme> for booting on macOS; I run colima for its containerd and k8s support but strongly recommend both projects $(brew install lima colima)

Re: Ask HN: Startup Devs -What's your biggest pain while managing cloud deployments?

#60
post #46

I work at a 60 dev shop so not a startup per se. Our biggest problem is feature environments, or actual integration tests where multiple services have to change. Because infra is in its own repo in terraform and the apps have their own repo we don’t have a good way of creating infra-identical environments for testing code changes that affect multiple services. We always end up with some hack and manual tweaks in stag…

> Our biggest problem is feature environments, or actual integration tests where multiple services have to change

OT1H, :fu: terraform, so I could readily imagine it could actually be the whole problem you're experiencing, but OTOH it is just doing what it is told, so that's why I wanted to hear more about what, specifically, the problem is? too many hard coded strings? permission woes? race conditions (that is my life-long battle with provisioning stuff)?

this whole Ask HN is nerd sniping me, but I'm also hoping that we genuinely can try and find some "this has worked for me" that can lift all boats

Post reply on HN