Live data from Hacker News

Docker operations slowing down on AWS

jeremyeder.com

161–170 of 176 posts

Re: Docker operations slowing down on AWS

#161

Earlier quoted context omitted.

How many hits/second does a project have to serve when they're on the front page of HN?

Shouldn't be anything incredibly high. I haven't seen any recent traffic info for HN, but a couple of years ago dang posted some numbers here: https://news.ycombinator.com/item?id=9219581 So at that point it was 2.6M views per day, which means HN itself was getting about 30 views per second. If you look at the 200k uniques instead (which might make more sense since any individual person will probably only click throu…

Hah, the fact that HN itself is a single server (behind Cloudflare, these days) should be enough proof that anything linked to by HN is unlikely to need more than a single server behind a caching CDN.

Re: Docker operations slowing down on AWS

#162
post #157
post #125

Earlier quoted context omitted.

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.

For 30k req/month heroku could a better choice. The cost here is maintenance and backup. Note: I'm still hopeful that things like k8n will make running stateful containers on random metal easy without huge investments in configuration for backup and reliability.

curious - but how would heroku be a win? I know nothing of heroku, so not insulting it.

I pay about $3.50/mo total to run these services.

Re: Docker operations slowing down on AWS

#163

Earlier quoted context omitted.

I was asking about once your bare metal capacity reaches its limit. At some point you need to provision more bare metal and expand the total resources kubernetes can consume with docker. Cloudformation, to me at least, is the power to expand resources for large traffic events. Most of the time you can get by with a small amount of instances but its nice when it scales up to hundreds of instances in minutes. The bare…

>Cloudformation, to me at least, is the power to expand resources for large traffic events. Most of the time you can get by with a small amount of instances but its nice when it scales up to hundreds of instances in minutes. This is not what CloudFormation does. CloudFormation allows a declarative way to express a group of AWS resources to be created and coupled together. There's nothing that's quite exactly the same…

Maybe we are talking about different things, but I use CloudFormation to autoscale ec2 instances based on avg CPU load over a period of time

http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuid...

Re: Docker operations slowing down on AWS

#164
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…

The problem with the rent-a-server approach over buying AWS is that, in many cases, your engineering team will need to implement a ton of APIs, tooling, monitoring, alerting, etc. to get the same quality of service that you get from a public cloud vendor "for free." Which is great for us engineers since it's interesting problems that need solving, but not so much for the PMs that need to justify that spend.

Also, when your web service scales to millions of requests per second from millions of requests a month or week or whatever, having elastic compute that can scale with that is a blessing. Because nobody wants to wait for page loads:

Re: Docker operations slowing down on AWS

#165

Earlier quoted context omitted.

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 e…

It's not so black and white. The changes mentioned may be a necessary evil when scaling; in this perspective, moving to the cloud makes a set of solutions (rearchitecting) happen sooner than later. Also, an 8k server is a big unit. Cloud services are much more granular. This is a problem of bare metal - it's easy to overprovision because the base unit is large, and one ends up being happy of having an "overprovisione…

> Also, an 8k server is a big unit

My point was that it's peanuts compared to the labor costs it saves. I've worked quite a few places where a single $2-3k server would have saved every employee around an hour a day. In some cases several machines would have saved an hour each.

Every person you don't need gets you more than one person worth of increased productivity due to scaling limits, (see also Fred Brooks, IT and HR - more employees, more support staff).

Re: Docker operations slowing down on AWS

#166

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.

A hit every two seconds is 30 * (86400 / 2) = 1296000 hits per month.

150000 hits per month is an average of a hit every 86400 * 30 / 150000 = 17.28 seconds.

Yes, that's nothing. With a hit every 17 seconds, there is no performance optimization to be done. Therefore I don't understand the concern about performance in the parent comment by 'sideproject'.

Sure, there could be peak times when there is a hit every 100 microseconds and that's what forced the parent commenter to focus on performance optimization but nothing about this was mentioned in the comment.

Details about traffic in such peak times would have made the parent comment by 'sideproject' interesting. But with the current details in the comment right now, it is going to leave readers confused why one needs to discuss performance optimization for a hit every 17 seconds on average.

Re: Docker operations slowing down on AWS

#167

Earlier quoted context omitted.

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 automati…

What's wrong with VPSes? Care to elaborate?

Re: Docker operations slowing down on AWS

#168
post #167

Earlier quoted context omitted.

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 automati…

What's wrong with VPSes? Care to elaborate?

- Automation/APIs are generally lousy. Some try (Digital Ocean is trying to shed its past and become a real boy--err, cloud), but stuff like Linode is infuriating to work with when you expect to be able to just do something like "declaratively describe your infrastructure and go". Or when you expect to have monitoring and alerting on hand without having to reinvent every wheel yourself.

- Networking is usually real bad. SDNs are your friend. Yeah, learn you an iptables and all, but this is the future, we can do better. (DigitalOcean is almost to the point AWS was at, like, eight years ago with EC2 Classic? Something like that.)

- Geographically-centralized but independent systems are hard to come by and so fault tolerance is a Big Problem. AWS loses an availability zone, my stuff keeps rolling. Can't say the same elsewhere.

- Value-add services. The sibling comment's complaining about RDS, but RDS configuration hits probably the 98% case and You Don't Have To Learn It. I'm a little more hesitant about lock-in services like SQS, SNS, etc., but moral equivalents exist elsewhere for the most part, you can use them pretty effectively.

Re: Docker operations slowing down on AWS

#169
post #107

Earlier quoted context omitted.

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.

How many projects actually get 150,000 hits a second? (And are they not better served by buying and operating their own datacenters?)

Well, I've worked on two now... once was self-hosted by a large services company, which has its' own data centers and redundant connections, it also handles a significant portion of DNS for the internet (for good or bad). It worked for them, but was painful.. Getting new servers up was months of work.

I'm working at another service company expecting to clear 5M requests/day with bursts close to what you're talking about several times a year. We've had so much pain managing colocated servers, we can't justify the cost of 3 full data centers for just our load, that doesn't make sense. We're currently moving to a cloud provider to be able to scale out better when peaks really spike.

We had a customer that wanted to do several million requests in a 15 minute window, and can't currently handle that... We're restructuring/refactoring so that we can.

It may not be sustained, but getting 330k requests/second in bursts is a different way to think about problems than anything less than 1k/second, which many servers can hit without a sweat, and why I'd be more inclined to push for mid-level VPS like DO or Linode in those cases. Depends on need and expected growth.

Re: Docker operations slowing down on AWS

#170
post #107

Earlier quoted context omitted.

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.

How many projects actually get 150,000 hits a second? (And are they not better served by buying and operating their own datacenters?)

[deleted]
Post reply on HN