Some commerce did need to scale fast and easily, and AWS provided that with great strength. But I will add that the management and executive branch were constantly and relentlessly seeking to undermine the bargaining power, day-to-day operations authority, and pay of skilled engineers who could do that kind of setup. Not that it was easy or risk-free .. I did see some powerfully strained eyes and nerves on those individuals who built and ran those kind of servers at various times. But do not leave out the manipulative and gaming motives of executive management to dumb-down admin requirements, seize authority via legal means, and seek the lowest wages across borders while doing so ..
At which point, as you say, the cost and complexity of a move is huge so you are stuck with a recurring bill.
Another interesting thing is that you pay for 100% of a VM virtual CPU even if it is only utilised 40%, but the cloud is selling your other 60% capacity to another user.
They have no incentive to charge you “based on CPU usage” for VM’s that are always on, even though it is possible. I think this would be a better approach than Lambda - to dynamically add more cores to your OS as you need them.
AWS don't overprovision CPUs outside of the t instance range, in which you get vCPU credits, not full vCPUs. If you rent an apartment but don't use it, is it the landlord's fault you don't? The landlord can't rent the same appartement to another client.
Especially on AWS/GCP/Azure, where there are many alternatives ( Lambda, Google Cloud Run, Google App Engine, etc.) where you pay per compute used.
One hardware core can be running 5 VMs at 20% capacity, and each VM owner will pay for 100% of their CPU capacity right? So in this case the landlord is renting your unused apartment to other customers then evicting them faster than you can open the door.
My point is cloud is benefiting from that ability and not passing it on the customers, which they could.
Its fully wrong for AWS, where a vCPU you rent == physical core/thread.
Are you certain of this statement?
[0] https://techcrunch.com/2017/09/15/why-dropbox-decided-to-dro...
tl;dr: to save money (and to fix issues and irritations with AWS)
Another good one is microsoft initially tying excel, word, access, etc to windows. And then IIS, SQL Server, etc to NT. An entire generation of businesses and managers got tied to windows this way.
In a way facebook and social media is a form of "vendor lock-in". The network/community itself and your "investment/time" in facebook makes it costly for many to move to another "facebook" or give up facebook altogether. The more time you spend on facebook and the more people you bring onto facebook, the more "locked-in" you are. It's quite ingenious and I suspect facebook understood this very early on.
But you see part of the magic trick was Amazon spent years having companies like Garnter proclaim that cloud was cheaper, and nobody could possibly do on-premises IT cheaper because of economies of scale. As a result you've got CIOs everywhere trying to make a name for themselves by driving their company to the cloud to show immense cost savings. They don't have time to be bothered by the actual financial models or real costs. By the time finance realizes what happened they'll be on to the next gig.
It was honestly brilliant, the number of "cloud first" strategies that originated in board rooms filled with people that don't know the first thing about IT is kind of disgusting.
Small businesses don't care because they are too busy surviving.
Medium businesses don't care because why break what works?
Large businesses don't care because their managerial careers promote short-term priorities and marquee "transformation" projects which are buzzword-driven, and cloud is the current one.
Life goes on. It happens all the time. The trick is to learn and be smarter next time.
There are off the shelf things for, say, S3 and ALB which are entirely workable, but once you start getting into more complicated stuff (like S3's new consistency semantics, or SQS) then you're looking at a whole small company (at a minimum) worth of additional work. It's a non-trivial expansion, even for a large org with lots of money.
You can avoid using these sorts of services to maintain flexibility/independence, but you lose out on their unique benefits. This isn't an accident. It's not like you're going to be able to selfhost an SES clone and get the same kind of deliverability percentages as AWS netblocks, no matter how many engineers you throw at the problem.
Some of the goods you just can't get anywhere else, and they know it.
Aurora - tidb or vitess or cockroachdb or citus etc etc
Glacier - there is backblaze, also onprem vendors
Sqs - just use Nats
Having said that, and please keep in mind that I do not have an idea much about hardware so this is a guesswork; more of a question than a statement..., I do think that the Graviton price vs performance might not have a direct benefit outside of AWS. It's cool for AWS because they have less stuff to manage at that scale and it might be cheaper for them to buy and iterate because only they use it. It looks great to the clients because the perception is that the value is better. But AWS runs 80 AZs in 25 regions so it benefits them at that scale.
Realistically, even if one had couple of hundreds of racks, does it matter at that scale?
SQS is a message queue service. It's a bit weird to claim that as "simply aren't directly available as selfhosted replacements", a message queue is pretty basic stuff.
I'm super into self-hosted shared-nothing queue services, but what AWS is doing with SQS is anything but basic stuff.
It's not limited to some. You absolutely need a whole new team (or teams) to handle your infrastructure, your high availability needs, and also your security.
The nifty serverless offerings and other features are just nice-to-haves in comparison to the core infrastructure work that cloud providers put into your system to keep it running.
Just because cloud providers like GCP and AWS and Azure and etc have everything put together to let you setup your whole infra by running a small script that does not mean nothing needs to be done in order for that to work.
My company recently shifted from on prem to cloud. And we aren’t primarily a software company (although, much like most companies, we are increasingly turning into one).
We outsourced our data center needs, and I don’t remember us ever facing these middle of the night massive breakdowns (we had load balancing between a couple of data centers) and the number of ops issues hasn’t reduced a bit since the switchover.
I do think it’s been easier to improve performance for non US customers, because spinning up servers in data centers across the world seems a little easier around the world, but the millions saved by self hosting would have easily paid for someone to spin us up a Singapore and UK colo servers.
Consolidate them, and a knife fight happens between middle management machiavellis and the one that wins is not necessarily the best on price or features. It's the one who is best at winning reporting hierarchy wars.
Instead they should pit these groups against each other as internal options for hosting to various services that provide what is needed for growth, adaptation, or cost.
AWS should simply be one of those options. Really it can be the prototyping phase, and then budget squeezing will move the app to other (hopefully cheaper) inhouse options.
What is frustrating from my years in the big corps is that AWS was cheaper than the internal "clouds" or other relationships.
You can very much do that while staying in the cloud. It's all about engineering for flexibility.
Even small companies have multiple engineering teams, and each of those teams has particular needs, and each of the engineers, analysts or general users may rely on some service AWS, GCP or some other cloud provider has. Any single person can now break this ideal flexibility requirement if it makes their life easier.
> It's already demonstrated that the big cloud providers will cut you off with little warning if you run afoul of their political sensibilities. So the only way to use those services is in the most generic way you can, so that migrations don't cost more because of it.
You are stating that you moved from one cloud to another. The question is how you manage to build a company of any size that can just flip a switch and move to a new service provider without needing to transition teams to using new services and that costing money. If we're talking about moving a simple server from AWS to GCP, sure that's no problem. But if you or anyone at your company is actually using a cloud providers services for more than hosting a server, there is no possible way you can just flip a switch and migrate over.
You’re not getting retail price.
So you’re still spending more trying to maintain “cloud agnosticism” by hosting everything on VMs instead of using managed services.
Like Jobs said, Dropbox is a feature not a product.
For the same price you pay for Dropbox and 2TB, you can get the full Office 365 suite plus 6TB of storage or the entire GSuite.
And do you have multiple redundant DCs? Are all of your database writes duplicated 6x across three DCs like Aurora?
That’s just silly - dropbox is profitable if you exclude stock comp unlike box inc (who afaik runs in cloud) and also has higher margins (big shocker here). From techincal side i hear it worked out really well for them too.
> Like Jobs said, Dropbox is a feature not a product.
What does that have to do with anything? Not helping your argument at all
> For the same price you pay for Dropbox and 2TB, you can get the full Office 365 suite plus 6TB of storage or the entire GSuite.
Should be painfully obvious to anyone arguing in good faith why that is. Also do you by any chance think google runs gsuite on aws or gcp?
> And do you have multiple redundant DCs? Are all of your database writes duplicated 6x across three DCs like Aurora?
Yes, you run mutiple redunant colos/dcs and peer them. You’re making it sound like rocket science but it really isn’t. If Internet Archive can do it with their resources (not a dig towards their talent at all) so can unicorns flush with vc cash who supposedly hire “the best”
How many people who are comparing their costs to using a cloud provider are ignoring redundancy?
And I’m sure your average startup has the capability to maintain their own redundant data center. Besides, does it add business value? Would they really be better off hiring multiple infrastructure people or just paying a cloud provider.
It doesn’t matter why it’s the case. People keep bringing up Dropbox as a shining example of moving away from a cloud provider - and still not being profitable. But ignore a little company - Netflix - that did just the opposite.
Do you not use IAM? Cloud specific infrastructure as code (again TF has cloud specific provisioners), permissions, compliance, training.
Why would this happen? Because what the company builds is a large and growing money-making contraption right inside the coworking space, also using parts of the building for critical functions, and the door is intentionally kept small. The only way to move that contraption is to dismantle it and reassamble in a much cheaper, purpose-built hangar, rebuilding some of the critical parts along the way. During all that time, the contraption would stop making money.
That's the beauty of AWS business model: it's a no-brainer for a startup to use it, but the startup grows, more financially efficient infrastructure options become unattainable because of the very high cost of the move. This is the best-executed vendor lock-in I know.