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.
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.
IMO this is exactly when you should not be using AWS. AWS is a premium offering and you can find cheaper alternatives for the commoditized offerings like EC2, RDS (the older, non-AWS-specific features) and (maybe) S3.
It's the high-level services where the real value is in AWS - the cutting edge technologies that only exist in a specific cloud (or multiple clouds but where it's difficult to port across clouds due to subtle differences). This is where the extremely high development cost is able to be amortized over many customers, allowing you to get scalable, easy-to-use, and easy-to-operate services at a much lower cost than would be possible outside of that cloud. A great example of that for AWS is Serverless Aurora.
So unless you're going multi-cloud from day one, it's much better to write your services to be specific to the cloud you're using and benefit from them rather than boycotting them because of a theoretical decision of multi-cloud that you might never actually make. Most companies that talk about going multi-cloud never actually do because the benefits of being multi-cloud are actually pretty small for most domains. Being multi-cloud is one of those things that sounds more important than it actually is.
I'm sure there are tons of developers out there who know a lot about infrastructure and system administration. For those people, it might be worth spending time managing infra, but my time is absolutely better spent using a turn key solution and focusing on product development.
For smaller teams, getting feature-rich products out the door can be more important than building the most cost-optimal product. Bigger teams can afford dedicated staff to optimize infra.
Back in the ‘old days’ of the cloud you’d hear a lot of talk about “commodity computing”. Compute was fungible. No salespeople, no politics. It was a utopian environment for developers.
But in the decade and a half since, the landscape has changed. Now cloud is infested with salespeople, consultants, and worst of all, third-party solutions. It’s the same old hodgepodge of half-finished incompatible products tossed over the wall that on-prem used to be, only more expensive.
That is a big tradeoff, and it's not something obvious. If being banned from AWS is an important and relatively big risk for your business, sure, go for it.
But if not, then those AWS-specific services are exactly where you get all those productivity gains from, and where AWS (and GCP for that matter) shines in comparison to smaller ones, like DO or Linode, or on-premises.
Infrastructure as code is something you can do on smaller deployment environments as well, even in air-gapped environments.
The benefit of AWS, for me, is the reliability and all the capabilities that work out of the box that aren't differentiators for my solution (so it's great that I can offload them to someone else, if security, etc. allows).
I agree that it's a good idea to have a layer of abstraction so you can use other service providers, even though you may take a bit of a performance hit for doing so.
This is the worst of both worlds. You get the expense of AWS but without any of the things that would make the cost worth it. IMO you should either avoid using their services and move to something way cheaper (OVH, as the article mentions Hetzner), or fully buy into the benefits AWS has to offer.
A lot of the things you said apply just as much to them as to AWS.
In my opinion using AWS is fine, as long as you use cloud agnostic stuff and avoid AWS specific services. That way if you ever have to switch, you just have to rewrite the provisioning part of your infra-as-code, everything else can be easily migrated over with some config changes.