Serving a static site on S3 can make you hundreds of millions of dollars. Of course thats because you put a metamask plugin and cater to crypto people and don't even have to build a backend to do anything impressive there.
But its scalable enough!
[0] https://lichess.org/forum/lichess-feedback/hardware-of-liche...
Our latest MVP - https://www.code-scope.com lets one interactively analyze and document GBs of source such as linux kernel.
It runs on Digital Ocean's $5 instance, build just with Jquery - bootstrap4.
The app binary that runs code-scope.com website is < 10MB including all the frontend and backend code.
Good old tech such as jquery works very well for us.
Complex js front-end tooling is a choice, not a requirement for develop web app.
I still annoy people by talking about my time at the high frequency trading firm, because working there was a revelatory experience. They were operating at a scale and velocity far beyond any place I've worked at, with lower tolerance for downtime, and very little hardware, relatively speaking. The traders had fun, of course, but it was frankly kind of boring to work there as a techie, what with everything ticking along so smoothly all the time.
And the way they got there was through an absolutely fanatical devotion to the KISS principle.
I've come to think that scale out is a self-fulfilling prophecy. If you choose a solution that's designed to support scale out, then all the mechanisms and limitations (yes, limitations) it needs to adopt in order to make distributed processing work will impose a burden of overhead that you will need to offset by scaling out.
I haven't seen any certificates that replace sweat and hard work yet, except in organizations where they cannot keep track of individual developer performance and simply count certificates.
There was a lot of homegrown software where others would use a library. That was deliberate. If you need five features, but choose an off-the-shelf package with 5,000 features, pretty soon you'll find that the list of features you're using has grown to 50, then 500, and so on, even if you don't actually need any of it. If a toy's in the box, the kids will play with it.
Maybe one thing to try is to focus on imposing constraints, and making people live within them. RAM, # of CPU cores, whatever. Software is like a gas. It will naturally expand to fill all available space.
What I do is put my database on a droplet and my files on another and it can handles millions of requests. Put them on the same machine and I need to increase ram higher than the cost of multiple small droplets.
If you ever reach those limits consider setting up a load balancer.
All the web queries are responded in <<< 1 second - so far....
That was 4 years ago and beyond basic patching they've barely touched their infrastructure and it runs around $100/mo.
Ok but is that static site primarily generating the $5B in revenue ? That's more relevant to know. Having a static site for a business where the revenue is generated elsewhere is not that big of a deal in my opinion. Yes I get your point that the $5B company is hosting a static site on S3 which is cool but what will be cooler is if THAT static site is the primary revenue driver. I bet it isn't.
Actually probably the output would be worse, because there's a significant amount of domain knowledge in building an effective website in this space. The only companies that are effective at it do it in house or go to specialists in the space.
Car dealership advertising is actually extremely similar in this regard. There are just a few big players working with hundreds to thousands of dealers.
- Insurance
- Loans
- Mortgage
- Attorney
- Credit
- Lawyer
- Donate
- Degree
- Hosting
- Claim
Still can't see it. But just to be sure, you're saying that the $100/month website was directly generating most of that $5B?
And not, for example, being just a bridge between users and an army of attorneys?
Keep in mind that a large number of law firms in this space do not try cases and just generate and sell leads.
Yes, obviously there's a lot more that goes into it, but my point was that websites can be extremely simple in their infrastructure and still be extremely effective.
I've talked at length about it before in comments. Not really looking for the repeat discussions.
Not that I wouldn't do it, a lot of times it does make financial sense.
Tbh, I find most engineering orgs don't have the competency to pull it off.
Consider for a moment that other people might in fact not be idiots, and might have legitimate reasons for choosing particular technology stacks that your snarky attitude has missed.
I've considered it many times, but I continuously find evidence to the contrary.
AWS has an absolute tonne of great and not so great services but you can easily use the basic stuff to get quite simple and cost effective solutions. You can YOLO it on the console and not even worry about cloudformation if you want, and if you have no customers it will likely be free tier to boot.
Even then, your founders might have made a bad business decision – which isn't unusual, and companies can often make bad business decisions, such as prioritising investment in scalability when it's not a required feature.
They can equally make good business decisions – such as rolling out a relatively standard technology like Kubernetes to gain the workflow and availability features, even though scalability is not required.
I agree that it is important to remember that sometimes "old-fashioned" approaches can be totally suitable for some use-cases, and they can be too often written off. But equally let's try not to assume that everyone who rolls out a particular modern technology stack is a gullible fool.
To be more specific: (1) they were not able to calculate the overall costs upfront. Yes there are many calculators, but you know the actual cost only when you receive the bill. Moreover, there is no hard cap on costs - people have been asking for it since 2006, and AWS was first saying they understand it's important and will take care of it, but in the end decided to ignore it.[0] Yes, you can set up alarms but that's not what people want. (2) AWS is marketed as saving on IT staff costs but it's ridiculous: you need competent staff to support it. The AWS infrastructure is huge, it's a whole ecosystem in itself, and it has its particular quirks. You definitely need smart people to run it and stay out of trouble. (3) Very often when you run a cost analysis of a particular aspect (like storage, processing etc.), it turns out the difference between AWS and, say, bare metal is enormous and, consequently, increases radically with the amount of resources used. There are several large companies who decided to move from AWS to bare metal just for this reason, saving enormous amounts of money.
Now, there are several scenarios where it doesn't matter, or it matters but it makes sense to use AWS anyway, but in my personal experience this is minority of cases I had to deal with. I have nothing against AWS per se - also, there are some aspects of AWS infrastructure that are a pleasure to work with. Nevertheless, usually it makes more sense to use a whole ecosystem, and the more you get locked in, the more difficult is to get out, and the sunk cost fallacy is omnipresent among companies of all sizes.
[0] https://forums.aws.amazon.com/thread.jspa?start=50&threadID=...
VPS servers are more capable than ever, and the manageability might surprise some who know cloud as the only way. It's not the only way, but it can be valid now often than realized.
The stacks run deep on both ends .. but I'm often not sure to what end.