Hence “you probably don’t need AWS”.
> On the other hand, if you use Kinesis, Lambdas, RDS, VPC peering, and IAM accross all of them including EC2 and EKS, then no, none of those other options can even come close. Purely the lack of system-wide IAM alone would be a dealbreaker.
Hence you are locked in and have zero negotiating position. Your business has an existential risk based on AWS - assuming your code is critical to the business and could not practically be rewritten because of all this special sauce you’re using.
That might be okay but I sure hope your CTO made that decision consciously.
Sure, you can play FUD games about AWS suddenly raising prices, but I doubt you'd have any historical evidence to back that up. So you'd better be able to say why being cloud-agnostic is critical to your business.
You generally pay for what you need and for what you can afford. If you don't need AWS or you can't afford AWS, it wouldn't make sense to use AWS. That goes for in-house software development, infrastructure management and pretty much anything else too...
In my startup we use mostly linode and handle a lot of volume. I have a few VPSs and some dedicated hardware for specific tasks. Monthly bill roughly 200-250USD all included.
The other startup used the AWS free credits. Got extra credits and lived it up. Adopted Kubernetes and all the big AWS stuff. Brought in a few devops professionals. All super smart people.
Monthly spend 7kUSD on traffic/usage that's actually much smaller than the one I have with my startup. Availability is roughly the same (if anything, my startup has better uptime).
So yes, this is an Apples to Oranges comparison. I get that. They can better scale in theory etc. But if they pay 7k right now, I can't imagine how expensive it will be when they scale.
They started just using EC2 but slowly got roped into AWS services so now they have no vendor neutrality and no viable/easy way to reduce these costs.
If you need 'some random compute and a bit of networking' then no, do not use AWS.
Vendor neutrality isn't worth match to a business unless you are the EFF or intend to move vendors all day long.
You don't need AWS or any other cloud for volume (traffic volume, that is), heck I'd say stay away from the clouds for volume since that is where the bulk of your money disappears anyway.
If you have less traffic then you should spend less.
This sounds like they don't have anyone who actually knows what they are doing, or did any form of cost/benefit analysis which will always mean you spend more than you should.
I'm not sure if you're being serious here. It's not about rising prices but making your business completely dependent on another entity and losing any options you might otherwise have.
As for past data, history is rife with stories of companies who made the mistake of trusting a big player their technology will be around forever. So many have invested in technologies like Flash because they were 100% sure they will be there forever.
If I was in charge of AWS, I would avoid sudden price increases, but instead focused on many new features and small charges. These look insignificant, "This is just 20 buck per TB, less than our spending on toilet paper." And then these slowly accumulate and the TCO is getting higher and higher, and again some new* smart features lure you - again, at a small cost. In the end, it turns out you can't leave even if you want.
*Or just your old open source library/framework repainted in AWS colors.
Simple things are simple: need IPv4 networking? Get an IPv4 allocation and route it to a (virtual) port of your choice. That is no different between on-prem, managed-dc, unmanaged-dc, managed server provider and cloud provider. There might be some semantics that are different, where a physical port cannot be unplugged via an API (at best you can down/up a switch port but that's not the same) and routing may or may not be implicit, may need a firewall or routing rule and may need translation. But all of that applies always anyway and gets named differently on who you are paying for it.
If you create something very complex, but it didn't have to be, perhaps it's simply a bad implementation and not a property of the technology that was applied. There are plenty of engineers that think they can roll their own crypto libraries, write their own filesystems and their own RDBMs... but what business case for the 99% out there really requires that? Nearly everything in a business is a generic problem any business has; it's always about products and/or services, and it's always bound to some legal and financial system the business operates in. Everything beyond that is just marketing and trust building.
The only unique thing in most cases is the data you have and the degree of integration of processes within the business. And neither of those are an actual technology problem or complexity driver.
As soon as you have decent amount of data which you care about AWS became dirt cheap compared to on-perm when user right. Look at the list above and imagine how much effort you would have to put on an ongoing basis to support this.
For example, let's take a simple producer/consumer system with some sort of queue. That's an easy enough problem. But add in some additional requirements:
* Data encryption - both in transit/rest * Access control * Audit logs
And it becomes much more complicated. It is a trade off. But the productivity gains available by having a common consistent solutions to issues like this... shouldn't be underestimated.
Doing it "right the first time" in one of the big three, then building a skunk works to replicate efforts as a blackout scenario, seems much more cost effective.
The key term is Total Cost of Ownership. Lockin is a cost. Legacy stacks are a cost. Learning three times the tools are a cost.
You don't have a negotiation position based on your ability to switch even if you are huge. AWS pricing negotiations is almost exclusively based on volumes.
There is no real lock-in other than the requirements of your own implementation. A lambda on AWS can just as easily be run on Kubernetes, but that means that on top of running the code that you wanted to run, you now have to run Kubernetes too. You could use a hosted Kubernetes control plane, or fully hosted setup, but according to your same logic you would now be locked in to Kubernetes.
It seems to me that you might have a very special use case, or simply not have had the scaled experience or requirements that made a lot of other vendors non-viable.
Business risk-wise, AWS is a very low risk when compared with pretty much anything else. What do you think will fail first, a custom in-house maintained setup (expensive, non-portable between companies and people) on Digital Ocean, Linode, OVH, Hetzner, etc or all AWS Availability Zones in all AWS Regions world-wide? (and we ignore the lack of IAM, lack of things like RDS, SQS, SNS etc)
Another term which is more descriptive for cloud native is vendor cloud lock-in, which could be reasonably but descriptively shortened to cloud-locked or cloud-married maybe.
Native sounds cool but completely loses sight of the cost of lock-in, while locked or married talks to both the benefits and the costs.
> Do not use AWS if you just run a few virtual machines and some basic networking. That also applies to GCP and Azure. It's too expensive for what you need.
Currently on a contract where I've saved them 6 months of my costs over 3 weeks of part-time development on a single year long project. They saved half of my entire contract on their first foray into AWS compared to Digital Ocean charges.
When you know what you're doing AWS can become very cost-effective. Build it with $PLATFORM in mind and all sorts of savings are possible.
But the tricky part is whether the team is ready for it, or whether they'll spend more time learning the ropes than the company saves over $NUMBER years. Which I think is what you were getting at?
If you use those, AWS starts rubbing its hands together and cackling in an evil laugh. I bet they even have an mp3 that plays whenever a major player uses a lock-in api product on AWS.
"aws lambda install blah blah" < I obviously don't know the api
Somewhere in Seattle: Mwahahahahahaha! Bwahahahahahah! Kwahahahahah!
Although RDS is just hosted SQL databases. It isn't a pure lock-in. Identity management, key management, firewalls, and networking all exist in some form at most places.
And don't underestimate how bad internal "clouds" are in large enterprises. AWS pure EC2 can still be a huge win, especially if that is the only one that has been "expertly" vetted or negotiated by some lofty level of management on a golf course somewhere.
I use AWS, but I suspect I'm a fair bit older than you.
Those things you say "you can't come close" - they exist elsewhere. There are just software libraries. It's the reverse of "can't come close" - there is a plethora of implementations to choose from, and most are free. Lambdas is just CGI on steroids, RDS is just a database, IAM is just one of any number of authentication / authorisation platforms the most notable one being kerberos which is literally decades old.
It's true that AWS's versions of these libraries all play nicely together, whereas the others are going to require more glue. But on the other hand AWS nickel and dimes you on every use. The price of writing the glue can be high and has to be incurred up front, whereas the price of the nickel and dimes - that's a future self problem. Just like smoking and crack. Not unsurprisingly the cloud vendors use the same tricks as the smoking and crack vendors too - they give away their delights for free to early users by handing out free credits like candy, knowing once you're locked in as a heavy user there is no way to avoid paying the piper.
The price difference in my experience is typically of the order of an an extra 0. That's not a big deal with your primary costs aren't CPU cycles but rather developer time. That's absolutely the case at the start of an enterprises life, and it seems to remain true for many enterprises for their entire existence. So perhaps AWS works out for many.
But personally, I would not take it for my business. There are lots of implementations of all the things you mention, and much more besides out there. Worse, many of AWS's products seem to exist to solve problems created by using other AWS products. Need to monitor you SES reputation? Don't record it yourself - send it to CloudWatch! It's only a small cost. Oh you need to get it to CloudWatch - use SNS - it's only a small cost. Oh you want to trigger stuff from CloudWatch - just use Lambda - it's only a small cost. Oh, you need to control access to all those things - use IAM. Maybe it's true it's all only a small cost - but it a very complex solution compared to parsing you SMTP server logs and writing them to a open source database, which is all that is happening under the hood. At times it seems the only reason AWS structures things in the way they do is to induce you into buying more AWS services.
Which is why things like TerraForm exist. Some are happier to where the cost incur the expense of gluing together the many free alternatives out there, in return for the ability to roll it out to the lowest cost provider out there.
On the other hand, if you use Kinesis, Lambdas, RDS, VPC peering, and IAM accross all of them including EC2 and EKS, then no, none of those other options can even come close. Purely the lack of system-wide IAM alone would be a dealbreaker.
This is also why being 'on the cloud' and 'cloud native' is very different. While the latter is a bit too buzzwordy for my taste, it does show the difference between "playing datacenter" and "getting stuff done in new ways, both cheaper and faster".
Do not use AWS if you just run a few virtual machines and some basic networking. That also applies to GCP and Azure. It's too expensive for what you need, and too easy to misconfigure and shoot yourself in the foot.
On the other hand, if you need API-driven infrastructure with a large gradient between IaaS and SaaS to pick from, then by all means, use AWS.