Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

news.ycombinator.com

Post reply on HN
Print view View original

91–96 of 96 posts

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

#91

Post by efxhoy »

mdaniel wrote: post #60
efxhoy wrote: 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 li…

The main problem is state, it’s too big and scattered. If it was just one db that knew everything that would be easy enough to snapshot, but there’s multiple dbs and s3 buckets and messages on queues and its all spread out. We could, with a bunch of work to make stuff actually portable, spin up a complete new environment, but a lot of the work that happens is related to synchronizing state and since all the state is scattered we can’t make an atomic clone of it.

Then of course there’s always the issue of people taking shortcuts, “i will test this once then we know it works then i’ll just hardcode this thing”. Making stuff truly impotent and portable is extra work for a “nice to have” of a feature env. YAGNI, until you do. For most devs they’re happy to have something that works and they can move on and ship the next thing.

Personally i’m a big fan of monoliths because they supposedly make this stuff easier. Then again i’ve never worked on a huge one and my colleagues much prefer spinning up an “isolated independent loosely coupled” service to adding it in the main app.

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

#92

Post by efxhoy »

oldandboring wrote: post #89
efxhoy wrote: 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 I'm always baffled to see how many shops claim to either not have this problem, or sidestep it. Every project I've ever worked on has had multiple enhancements/fixes in flight at the same time, they need to be tested and deployed independently of each other, on their own timelines. For this we need story branches and a fast way of deploying different story branches to dif…

I think it could be done with a monolithic app with a single db and truly stateless external services in a single repo. I only have experience from a single shop though and that’s not how the stuff we build ends up.

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

#93

Post by sanderjd »

cjk2 wrote: post #53
sanderjd wrote: post #34

Earlier quoted context omitted.

> 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.

Gotcha!

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

#94

Post by woleium »

denvrede wrote: post #61
bjackman wrote: post #45

Earlier quoted context omitted.

> You are unlikely to change cloud providers, so choose one and stick to it. Use their managed features. I am curious about this because I see opposing views expressed by different people. I have never personally been in a position where the decision has been relevant. I work at a cloud provider an I'm told that a big slice of our revenue comes from customers who are already load-balancing across multiple clouds, so…

> I work at a cloud provider an I'm told that a big slice of our revenue comes from customers who are already load-balancing across multiple clouds, so if we degrade perf/dollar they just turn a dial to shift load to our competitors. It's only anecdata but I'd highly question that. All companies I worked in (startup, midsize, megacorps) went with one cloud provider and stick to it. That is also not only my experience…

i think it’s likely to be a certain class of customer, rendering or high power batch processing. These are relatively simple, pull a task off a stack and crunch for 90 mins, then dump the results in a bucket workloads. Large volume customers that will represent a disproportionate bottom line value to a cloud provider. Probably not the customers you are talking about above

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

#95

Post by WuxiFingerHold »

dig1 wrote: post #42

My main challenge is people, especially "experts," who come, preach whatever popular cloud stuff is today, and then leave. This leaves me with a lot of shi* to deal with. We should keep things simple, KISS. My few key points for the future myself: 1. Be cloud agnostic. Everyone operates on margins and a slight increase in a cloud provider's fees could be a death sentence for your business. Remember, cloud providers a…

Really like this advice. Especially 4.

I only think monorepos for a Javascript / Typescript stack are heaven sent (pnpm, turborepo), because reusing NPM packages otherwise is a huge pain.

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

#96

Post by ancieque »

niteshade wrote: post #80
Hortinstein wrote: post #30

Earlier quoted context omitted.

I don't think there has been a ton of iteration on it, but did you run into any specific problems or bugs or is this lack of recommendation based off caution against adopting something that is not being iterated on? Just asking because while I haven't used it in years, it's been my go-to for small projects in the past, it seemed to do what it advertised very well. I hope that someone picks up the swarm torch, I reall…

Not GP, but I recently attempted to migrate a single-node Docker Compose setup to Docker Swarm and ran into the following issues: - No ability to use secrets as environment variables, and no plans to change this - Cannot use `network_mode` to specify a service to use for network connections a la Docker Compose There were a few other minor issues which resulted in ditching Docker Swarm completely and moving to a Nomad…

While the way secrets work in Swarm seems weird when compared to Kubernetes, this is usually pretty easily solved by a quick overriding entrypoint in the docker stack file that does essentially this:

    export SOME_VAR=$(cat /run/secrets/some_secret)
    exec /original/entrypoint.sh
Can you explain the second one? I don't get the usecase.
Post reply on HN