Live data from Hacker News

Docker operations slowing down on AWS

jeremyeder.com

121–130 of 176 posts

Re: Docker operations slowing down on AWS

#121

Earlier quoted context omitted.

I've been running a web application for the past 6 months and it just crossed 150,000 page views/month mark. Sure, for others it's not that great, but for me, this is the project that is showing the biggest potential. Anyway, the funny thing is, I'm running it on $2.50/month Vultr VPS. I got so worried when it crossed 30,000 that my site will crash. But it didn't. Then when its views got higher, I optimized further.…

150,000 views a month is like a hit every two seconds. That's nothing. Talk to me when you're managing 150000 hits a second. Edit: sorry didn't mean to imply that your site isn't successful, only that in terms of traffic, it doesn't make aws worth it.

What are these "hits"?

Why not have a CDN serve static pages? Or better yet, an app on a mobile phone?

Then the hits are just APIs.

Re: Docker operations slowing down on AWS

#122

Earlier quoted context omitted.

If you know good ops people, you have additional options. Hiring ops people and hoping they can out-value a cloud provider is a risk. Good ops people can cost as much as good developers. If you're a larger business, you can probably absorb that risk if it goes wrong. If you're a startup, it could be catastrophic. However, I also know larger businesses that just simply do not have good ops teams and a cloud provider w…

Almost every argument that you are making here could be exactly applied to developers and contractors. Hope that they can out-value a contractor. They're expensive. Some larger businesses have terrible dev teams and a team of contractors could out-perform them all. > Good ops people can cost as much as good developers. And this is a surprise? They bring a ton of domain specific expertise, good automation experience,…

If you can afford to put good people in every position, by all means go for it, but that's not been how startups and small businesses hire, or else they wouldn't have to use the phrase "we wear a bunch of different hats here at St4rtUp". The apparent trend has been to overload the developer with additional responsibility instead of, e.g., making ops people build product features.

Re: Docker operations slowing down on AWS

#123
post #10

And then people consider me a dinosaur when I say, no cloud, just rent a server or two (not colo! just dedicated servers). Your average web service does not need to scale near infinitely; for the same amount of money you pay to Amazon you can overprovision 3-5-10 times and that'll handle your spikes. No surprises. Same amount of work: EC2 and bare metal both gives you a root prompt, go from there. These days you can…

It's not just about scaling up, but also down. In my experience most of the startups initially greatly over-estimate what they need, and end up with only small part of the resources really used. With cloud you can provision what you think you'll need for a few weeks and then, once you get actual usage data, you can scale and fine-tune the setup to fully utilize it (and optimize the costs). And it's done with a few clicks in just a minute or two, without having to manually update anything, anywhere. No need to change DNS zones, no need to copy the data, all the tedious work that's usually involved with moving to a new unmanaged dedicated machine. With EC2 I can do this as often as I wish, while your hosting company would probably go crazy if you'd ask them to provision you a new hardware every week, or change it twice a day because you've changed your mind.

Re: Docker operations slowing down on AWS

#124
post #10

And then people consider me a dinosaur when I say, no cloud, just rent a server or two (not colo! just dedicated servers). Your average web service does not need to scale near infinitely; for the same amount of money you pay to Amazon you can overprovision 3-5-10 times and that'll handle your spikes. No surprises. Same amount of work: EC2 and bare metal both gives you a root prompt, go from there. These days you can…

It's not just about scaling up, but also down. In my experience most of the startups initially greatly over-estimate what they need, and end up with only small part of the resources really used. With cloud you can provision what you think you'll need for a few weeks and then, once you get actual usage data, you can scale and fine-tune the setup to fully utilize it (and optimize the costs). And it's done with a few cl…

> With cloud you can provision what you think you'll need for a few weeks and then, once you get actual usage data, you can scale and fine-tune the setup to fully utilize it (and optimize the costs).

Or in a more realistic scenario you forget to dial back an are paying $200/month extra for unused provisioned IO for years before anyone notices it. Happened, even though I was looking for improvements after every bill.

Re: Docker operations slowing down on AWS

#125
post #50

Earlier quoted context omitted.

Yes. Look at https://www.packet.net/bare-metal/ for bare metal boxes provisioned in less time than an ec2 instance. Or if you want to go old school, cheaper, and less sexy/api driven: https://www.delimiter.com/ If you shop, for around 30-40 a month you can get 16 cores, 32gb ram, and a 120GB ssd or 1-2TB spinny disk.

also scaleway.com (they have API, but no user-data). IMO, docker and container orchestration spells a bright future for bare-metal boxes like these, as you won't need cloudformation, etc.. But I still see few alternatives to S3, many vendors offers block devices, but only the big clouds offer blob storage. Backup and restore from blob storage makes recovery from crash pretty easy.

I rent a dedi arm box from scaleway. It's been up for 700 days, and serves about 30k req/month. I couldn't be happier for the price.

Re: Docker operations slowing down on AWS

#126

Earlier quoted context omitted.

He's making a judgement on the value of aws using a use case that makes no sense to use aws, anyway. He could be doing something similar with lightsail on aws at similar cost if he really wanted to, though.

> He's making a judgement on the value of aws using a use case that makes no sense to use aws, I think the problem here is that a lot of people use AWS when there's no value in using AWS. It's commonly reached for as a first choice when it's often not a good option if you're looking to run lean. AWS is extremely popular, but probably only efficient for a small percent of companies who have wildly variable traffic pat…

Your idea of "running lean" optimizes for the operational expenses of servers, which are across-the-board cheap, rather than cost of developer time.

I bill between $200 and $250 an hour. (If I had a full-time job I'd be salaried around $90-$100/hour.) Being able to pay me less because AWS's tooling makes life a hell of a lot easier once set up makes a lot of sense even for fairly small companies.

Re: Docker operations slowing down on AWS

#127

Earlier quoted context omitted.

I managed a metal to AWS transition, and 5x definitely doesn't match the costs I experienced (in this specific case, it was around the lines of 1.2x). I don't mean this case to be universal, in particular, I think cloud services force applications to have a particularly good/modular design (which is a cost in itself) - where, with metal, as you wrote, you can relatively cheaply overprovision. I think the analysis you…

I used to work at aol, and I think 5x was on the low end of what we experienced, if you just forklifted an app over. You can bring that cost down eventually by rearchitecting and laying off/reassigning some ops guys, but that takes time.

If you're just lifting apps up and plopping them on AWS, it can totally be really expensive.

(That doesn't happen when you're building from the jump for AWS or another cloud, though, unless you're messing up on a deeper level.)

Re: Docker operations slowing down on AWS

#128

Earlier quoted context omitted.

> He's making a judgement on the value of aws using a use case that makes no sense to use aws, I think the problem here is that a lot of people use AWS when there's no value in using AWS. It's commonly reached for as a first choice when it's often not a good option if you're looking to run lean. AWS is extremely popular, but probably only efficient for a small percent of companies who have wildly variable traffic pat…

Your idea of "running lean" optimizes for the operational expenses of servers, which are across-the-board cheap, rather than cost of developer time. I bill between $200 and $250 an hour. (If I had a full-time job I'd be salaried around $90-$100/hour.) Being able to pay me less because AWS's tooling makes life a hell of a lot easier once set up makes a lot of sense even for fairly small companies.

AWS tooling doesn't save developer time in my experience. In fact, I'd argue that optimizing for it more often than not wastes it.

I've watched someone spend days learning to configure a performant DB server on AWS due to their poor disk IO performance and spend an enormous amount to get a high ram instance when a simple SSD based server where more IOPS were trivially available would have had it working out of the box.

Everything has a learning cost though, so perhaps that's a somewhat unfair example as having a deep knowledge of data centers and backbone providers doesn't come free, but I can crank an ansible and docker script out and have pretty much all the advantages of AWS but deployed on my own hardware at a fraction of the cost. So I'm not sure it's fair to say that AWS tooling offers anything particularly unique to merits its market position.

Re: Docker operations slowing down on AWS

#129

Earlier quoted context omitted.

I managed a metal to AWS transition, and 5x definitely doesn't match the costs I experienced (in this specific case, it was around the lines of 1.2x). I don't mean this case to be universal, in particular, I think cloud services force applications to have a particularly good/modular design (which is a cost in itself) - where, with metal, as you wrote, you can relatively cheaply overprovision. I think the analysis you…

I used to work at aol, and I think 5x was on the low end of what we experienced, if you just forklifted an app over. You can bring that cost down eventually by rearchitecting and laying off/reassigning some ops guys, but that takes time.

I really struggle with this color of money nonsense that western finance has invented. Tell me again why hiring a developer is cheaper than buying one $8k server that will save us 35 man hours a week? Drives me batty.

Rearchitecting may be necessary anyway, but doing this kind of work involves hiring and training better senior devs and retaining them for a couple of years at least. That's not cheap. It's A lot more expensive than those OPS guys you laid off.

I think what both of these scenarios share is that they're not about saving money. They're about empire building for the Dev manager.

Re: Docker operations slowing down on AWS

#130

Earlier quoted context omitted.

Your idea of "running lean" optimizes for the operational expenses of servers, which are across-the-board cheap, rather than cost of developer time. I bill between $200 and $250 an hour. (If I had a full-time job I'd be salaried around $90-$100/hour.) Being able to pay me less because AWS's tooling makes life a hell of a lot easier once set up makes a lot of sense even for fairly small companies.

AWS tooling doesn't save developer time in my experience. In fact, I'd argue that optimizing for it more often than not wastes it. I've watched someone spend days learning to configure a performant DB server on AWS due to their poor disk IO performance and spend an enormous amount to get a high ram instance when a simple SSD based server where more IOPS were trivially available would have had it working out of the bo…

So I'm not trying to big-time you, but I have experience across a wide range of environments and shop sizes (both in clouds and, unfortunately, people who bought the "VPSes are fine too" idea in like 2015) and, after being in these trenches for a while, "it doesn't improve developer productivity" reads more to me as "we don't know how to leverage AWS for developer productivity." Elasticity is nice; pervasive automation and deep introspective monitoring (which you don't have to create and manage and scale) is not merely nice but required, especially for small teams, because your small team cannot afford to be disrupted by systems that can't take care of themselves without kneecapping your velocity. I believe you're arguing in good faith but you're telling me that's this pebbly wall when it's actually the whole elephant.

And AWS reduces business risk, too, which needs to be understood and respected, too. Your VPS universe is not actually repeatable. It takes one line to roll out a full environment for more than one of my clients. Dev environment? Here ya go, self-serve bootstrapping and management. Prod environment? Infra-as-code guaranteed to be what you pushed to test at the infrastructural level as well as at the deployable level.

This is why we are replacing system administrators with developers and why we are replacing hands-on system creation with cloud stacks: because it's a difference of kind and the fears of higher operational expenses are trivialized by being able to use that endless inventory to replace the expensive part of your operation--the people.

Post reply on HN