241–250 of 338 posts
Earlier quoted context omitted.
The nominal price of $0 absolutely is absurd, since every individual service has a separate pricing chart down to the ELB.
I can't find a pricing chart for IAM, which is the cited example.
Earlier quoted context omitted.
Then you remember that for years, Stack Overflow ran out of a couple of well administered servers. YAGNI. KISS. People forget the basics because "infrastructure astronautics" is fun, and it probably helps make a beautiful resume, too.
While infrastructure astronauts are typically money wasters and padding their resumes, I don't think SO is the best counter example. SO's read to write ratio is enormous. While they talk about a handful of different bare metal servers a vast majority of their hits are handled by their caching layer which is not one of their bare metal machines. Their write loads are not explicitly time sensitive either, if there's a…
StackOverflow is useful because it reminds people that machines are fast, and you probably don't need that many of them to scale to large sizes. StackOverflow is used by the entire global population of developers more or less and it runs off of one large MS SQL Server + some web servers. No auto scaling (not enough hw expense to be worth it), no need for fancy cloud LBs etc.
Sure maybe your service is gonna scale to more than the world's population of developers. Great. But ... a lot of services won't even go that far. For them it's hard to conclude it's really needed.
To pull off a StackOverflow you do need skilled sysadmins though. As the article points out, a surprisingly large number of people who call themselves devops don't really know UNIX sysadmin anymore.
Earlier quoted context omitted.
It was panic shopping when people were hoarding flour and yeast though, for instance
No, people were bored, stuck at home and started trying home baking. It was doing the rounds on social media. So there was suddenly a massive demand for flour and yeast. No panic, just a simple fad that they couldn't supply enough to meet demand. I read that in the UK at least the actual problem was they had enough flour, but it was all in industrial bags and they did not have enough packaging to rebag it. Actually a…
Earlier quoted context omitted.
It is the World top 50 site by Alexa. Comparatively speaking even compare them to the same CRUD app and DB, most are using 5 to 10x more servers with 1/2 to 1/5 of the traffic.
It is a large site by traffic measure but I would guess the traffic is heavily read only. Managing workloads with more data mutation introduces different complexities which mean you can't just cache everything and accept the TTL for writes based on cache invalidation. edit: To be clear, not saying SO isn't an achievement, but its one type of use case that yields a really simple tech stack.
https://stackexchange.com/performance
Their DB handles peak of 11,000 qps and peaks at only 15% CPU usage. That's after caching. There are also some ElasticSearch servers. Sure, their traffic is heavily read only, but it's also a site that exists purely for user-generated content. They could probably handle far higher write loads than they do, and they handle a lot of traffic as-is.
What specific complexities would be introduced by an even higher write load that AWS specifically would help them address?
Earlier quoted context omitted.
> AWS gives you all the things you'd need to scale, without heavy up-front costs A startup doesn't need AWS right off the bat. Planning for scale right from the beginning is a way to quickly bleed $. Of course, if you have VC money, why not spend that cash right? Where I work we've started non-AWS and have continued non-AWS. We don't have a team of devops engineers, but rather a team where there are a engineers who _…
You don't necessarily need to plan from scale from the start. Often you just need a few servers, a load balancer, a database, some file storage, internal networking, user permissions, and some level of security/firewall. That is very easy to set up on AWS in a day or two, and you don't need all your engineers to simultaneously be devops experts. The scale can happen once you've validated your startup, and when that h…
Look at it like this; GitHub mostly ran in their own datacenter using AWS only for spillover capacity. They scaled just fine. Virtually no apps have the problem of runaway growth that they can't handle without instantly provisioned resources.
Earlier quoted context omitted.
AWS gives you all the things you'd need to scale, without heavy up-front costs. There's a natural path from small instances -> bigger instances -> load balancers/ELB -> reserved instances (or spot if it fits your workload). For a smaller company, any savings you'd get from owned servers would be offset by much higher dev ops costs. Plus, as mentioned, you get a vast menu of services to choose from, all of which are m…
Then you remember that for years, Stack Overflow ran out of a couple of well administered servers. YAGNI. KISS. People forget the basics because "infrastructure astronautics" is fun, and it probably helps make a beautiful resume, too.
Just look at the modern SPA. They are slower than ones 10 years ago, and the JavaScript VM is much faster plus all the hardware gains. Why does it make Twitter and Gmail a few seconds to load?
Earlier quoted context omitted.
If it saves you a FTE or two from managing your own infrastructure, there is a lot of headroom before it's a losing proposition. Which is what I think the OP misses discussing in as much detail as they could with AWS -- are there ways AWS is saving some customers developer/ops staff time over the cheaper alternatives? Cause that is often more expensive than the resources themselves. Could just be "because that's what…
My experience - from doing devops consulting and moving clients off AWS every chance I get - is that it's bad business for devops consultants to move clients off AWS in terms of short term billable hours, because clients spent more money on me when they're on AWS. If I was after maximising billable hours in the short term, then I'd recommend AWS all the time... As such a lot of devops consultants certainly have all t…
I'm having trouble following your theory of why having clients stay on AWS ends up leading to more consultant billable hours, I think because I don't understand what alternatives you are comparing it to. I am pretty sure it is not heroku, as in the earlier part of the thread?
Or are you talking about compared to simpler "vps" hosts like, say, linode? Doesn't that require a lot more ops skillset and time to set up and run compared to aws, or you don't think it does?
Earlier quoted context omitted.
I've done operations stuff for ~25 years now. I've used AWS since it launched. I've done devops consulting for years. I've yet to see an AWS deployment be competitive on cost with onprem or managed hosting. In fact, I used to make good money helping people cut costs by moving off AWS. That includes paying more for devops , because AWS is incredibly complicated, and most people struggle to get it set up well. There ar…
Cool, this is the stuff that interests me. Comparing the nominal cost of hardware with the nominal AWS costs is boring.
Earlier quoted context omitted.
I can't find a pricing chart for IAM, which is the cited example.
IAM isn't a service. It's how you govern access control. Its nonsensical to charge for this, as an "IAM service instance" makes no sense.
> a server running on a computer device, listening for requests at a particular port over a network, serving web documents (HTML, JSON, XML, images), which serve in solving specific domain problems over the Web (WWW, Internet, HTTP)
Clearly IAM is a service.
Further, the service needn't operate on resources called "instances" in order to provide value--few AWS services offer "instance" resources and yet they deliver value to customers and are consequently priced. IAM isn't priced directly, but rather the operating cost for the service is built into other AWS services, presumably to encourage people towards security best-practices (charging for IAM might dissuade users from building securely).
Earlier quoted context omitted.
AWS gives you all the things you'd need to scale, without heavy up-front costs. There's a natural path from small instances -> bigger instances -> load balancers/ELB -> reserved instances (or spot if it fits your workload). For a smaller company, any savings you'd get from owned servers would be offset by much higher dev ops costs. Plus, as mentioned, you get a vast menu of services to choose from, all of which are m…
> If your team is filled with devops engineers, then, sure, go with the non-AWS route. This seems backwards to me - running a simple VPS on something like OVH/DigitalOcean/Linode is a matter of creating the instance, setting the size, and setting up your server software. Super simple, and likely about the same complexity as setting up a dev environment. Setting the same thing up on AWS requires slogging through the d…
Until that server goes down.