You probably don’t need AWS and are better off without it
trickster.dev
trickster.dev
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.
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...
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.
I remember using their email service (SES) and wanting to read logs for emails that have been sent. The only option was to point log events at an SQS queue. So, you had to create one of those, assign proper roles and access controls, etc. After that, you need to dump or consume the queue somehow. I can't remember if SQS could dump to S3, but if it could, then OK: create a bucket, assign roles, etc. Now, to parse the S3 bucket contents somehow... Wait, what was I doing? Trying to read some damn log files or set up a Rube Goldberg machine for the log files?
I get it. It's a modular system, and that can be very powerful. Sometimes I just want to do something simple without going down a multi-hour (or day) rabbit hole. The inability to perform simple actions on AWS without looping in tons of their other products means indefinite job security for a lot of people. IaC and templates for actions like the above alleviate this a bit, but it's still a dreary landscape.
They can offer awesome leverage and benefit. They can also be horrible traps that can break a company. I've seen both. As Doug Comer once told me, Unix is a Power Tool. Power Tools can kill. So can cloud platforms. There is nothing new under the sun...
Total cost 30$ per day ~900$ per month.
You can accomplish the same for a fraction of that cost.
The convenience you talk about comes with a huge bill.
If I add reserved instances/savings plan, probably gonna drop to 600-700$, but still… I can setup that myself on my local lab for around 5$ per month.
So the knowledge required to setup that and hardware is worth around 695$ per month.
Thats why Cloud Providers are biggest employers of old sysadmins ;)
* AWS MSK (Kafka server) with redundant instances across 3 AZs
* Aurora Posgres instance with redundancy across 3 AZs
* Multiple Lambdas for incoming messages from MQTT to Kafka
* IoT/MQTT and about a dozen iot devices sending telemetry continuously (every second)
* 20+ services with nearly 40 tasks, running on ECS
* All the supporting route53, certificates, VPCs etc. for the above
* A bunch of miscellaneous stuff I've forgotten that's used by other developers.
* All deployed via TF
_THAT_ all costs well under a grand. You're doing it wrong.
And yes, bandwidth costs can be brutal, especially if you try to build a hybrid solution that uses heavy services that live outside of AWS.
That said, the above comment didn't get into enough detail to get an accurate read on their bandwidth or CPU/Memory/Storage utilization, but if they can run it in a lab for $5/mo (which I doubt, since that barely covers power), then it can't be much, so I think it's fair to assume it's at least back-of-the-napkin similar scale.
My point was just that it doesn't have to cost over $1k on Amazon to run a combination of services which apparently CAN run in a private lab for $5/mo, however that is calculated. I can't run my full stack even without load (due to memory commit) on my 32GB, 3 year old Xeon workstation, and that would cost a lot more than $5/mo at any provider I am aware of.
If you wrote exactly the numbers of instances and types -> we could have a real comparison then.
That also means that a side-project that doesn't need that redundancy would be a mismatch in terms of requirements anyway. On the other hand, if you need a multi zone automatically available system, you're running out of choices really fast.
I think what many fail to realize is that - surprise surprise! It isn't that simple. Many think "if my zone goes out, I'll just migrate to a different zone!" Nope! AWS doesn't have the capacity for it - as we've seen many times, AWS can't seem to handle the migratory load when a zone goes out. Sure, the other zones don't really die, but good luck migrating your workload to them.
But when touting multi zones, no one ever mentions this little nugget of information.
All AWS had to say was “we are working hard on providing additional capacity”.
The same often happens on black friday, where companies scale up their platforms just in case because there might be no capacity on AWS.
It does cost money, but then again, so does not running certain processes. The trick becomes calculating the intersection at which point the costs outweigh the benefits, and that calculation applies everywhere.
Some sort of manual active-standby configuration really doesn't require AWS or a Cloud, that stuff is the same 90's implementation it has always been and practically boils down to attaching your RAID1 USB HDDs from one PC to another PC and booting that bad boy up as 'failover'. (yes, that's an example, and yes it's an extreme one)
If you have capacity planning, and you plan accordingly, you take service provider limits into account, just like you would with anything else. Having two power feeds into a distribution warehouse doesn't help much if neither can't handle 100% of the load in an industrial park. So while having two feeds might seem 'redundant' to a single tenant or customer, it's only really redundant if either can supply all the demand of all connected customers.
The same applies to fiber connections, plenty of fake-redundant connections that are suggested by customers to be 'redundant' turn out to end up at the same PoP and if the PoP goes down your redundant fibers are worthless. In the same logistics distribution scenario, your trucks can't deliver goods if the destination warehouse itself is offline, and now you need redundant warehouses.
That's obviously a weird thing to do at smaller scales, but the fact remains that AWS having an AZ go down is only a small piece of the puzzle, and only really a problem if you didn't plan for it appropriately.
AZ redundancy is like storage backups or backup power, if you don't regularly test it you don't have it.
>Total cost 30$ per day ~900$ per month.
Ummm... I think you're doing something incorrectly. The biggest line items on that list are ELB (assuming you mean Application Load Balancer/ALB) and NAT Gateway. But with that setup, I could maybe imagine $100/month with on-demand plans. Not $900.
How much compute can you rent anywhere for $5/mo? How much compute can you get even buying the hardware and amortizing over its useful lifespan for $5/mo (~$300 total)?
And it sounded more like a generalisation anyway. ;)
either way my biggest problem with services like AWS isn't really cost but that you end up using all of their SDKs and services out of convenicance and it becomes hard to track down or move away from.. it spiders out of control so fast that sometimes its better to spend an extra few weeks doing things the harder way that's not always an issue though espcially for startups
Managed NAT Gateways can be a very substantial cost depending on your architecture. I believe the recommended VPC layout has 3 AZs so you're paying close to $100/month for a single VPC just for NAT.
Do you really need multi-multi-region failover redundancy? Do you really need multiple NATs in every region (it's easy to share one NAT Gateway across AZs, especially so if a region is only servicing DR)? Your numbers still sound high.
x $1 + y $0.60 to make up $30 is a _lot_ of regions/AZs.
If you want a simple sight with just core aws, you can set one up on aws on elastic beanstalk for a few bucks a month. Add an rds for 15 a month. Why will you needlessly overcomplicate the system and then cry foul?
Even if it was 50$ per month, its still alot cheaper.
And the cluster we are talking here about is a raspberry box with 10 mashines each 2cpu 8gb, running k8s, replicated storage, my own domain and certificate, metalb load balancers, and few other things.
Its not as redundant as AWS, but it never broke in few years of constant work. Chances of all of those machines to break at the same time are astronomically low in normal circumstances.
If I spread the cost of that setup over two years of reservation, the monthly cost will be a lot less than 50$.
If you have high compute needs I've had good experience with that and it's cheap. You can put a huge box behind it. I did that (I have ATT fiber to the house) and for the $7/month I could still use all my deploy templates and AWS CLI commands and code to do stuff.
I tried this with an AMD home machine (AMD 5900x / 64 GB ram / nvme) and it worked surprisingly well as did a dell server (beefier). I put ubuntu on them, registered them, and they came right up in the plane.
That's an extremely cheap price to pay if you had to hire someone to do it.
I get the pain if you’re at “garage with shoestring budget” stage but $1k/mo isn’t even worth the time to set up a billing alarm.
Lets take a small production cluster of 4x r6g.large (default proposal for prod) (0.167$/h) deployed in VPC in private subnet (x2 for HA)
That’s 16$ per day for instances only and 2.5$ per day for nat-gateways per day. So 18.5$ per day and ~550$ per month.
Thats ofcourse if you disable all metrics all logs all alerting etc and it does not include Volumes cost, because its highly dependent on the domain.
AWS is expensive because you get alot of administrative work out of the box (snapshots, restores, etc). Tho sometimes have to still fix in the source. Ive personally pushed quite a few fixes to OpenSearch source, coz version 1.0.0 had a lot of issues.
So yeah, what you're saying is sort of meaningless without understanding the business type/stage/revenue/costs.
What did the hardware cost, and based on depreciation, how long will it last before requiring replacement? Is that also included in the 5$ you are quoting here?
AWS CDK is unparalleled experience. Truly a multiplier in productivity that I haven’t experienced in 20 years working on the web.
>Is it actually good as default choice to host a software system of any scale? Let us go through some arguments against going all-in with AWS and why many companies and individual side-project developers might be better off using something else.
To be clear, the author is suggesting that AWS doesn't need to be your first choice in smaller setups and side projects. I don't think they're intending to say people shouldn't use AWS under any circumstance.
There are plenty of smaller cloud service providers that can offer similar functionality to AWS that probably make more sense for smaller-scale uses. I personally love Linode, and you can definitely pull together their various services to build something without doing it from the ground up on VMs.
I think you've lost touch with where the non-AWS world is up to and are assuming it's still where it was in 2012. It's not.
They had considered switching to AWS or Azure in the past, but ultimately deccided to stay on this setup for cost reasons, and frankly I don't think anyone understood the benefits of infrastructure-as-code let alone taking advantage of all the other thing in the cloud providers.
I came in to help modernize it. Just as we were getting going with some Terraform-based proof-of-concept, a couple things happened: some sales opportunities came up that would require running in another region, and there were some harder questions on the disaster recovery plan (eg: "what happens if the datacenter burns down?"). The company doesn't want to invest in building out another traditional datacenter, let alone redundant ones, so we took this opportunity to discuss shifting this project over to AWS or Azure.
Once built with infrastructure-as-code on the cloud providers a bunch of these problems just disappear, even without making the app itself "cloud-native". Having a dev environment that mirrors production is easy. Having multiple multi-tenant environments in different regions -- and adding new regions -- is also easy. Recovering from a major disaster would also be relatively painless, provided you have a good backup strategy (deploy to new region, restore backups).
Thinking about the resource cost to prop-up, maintain, and cross-integrate a platform anywhere close to AWS is a business in itself.
But this has been shared here before and is still pretty good: https://adayinthelifeof.nl/2020/05/20/aws.html
Using a declarative language is both a pro and con.
Pros of that solution is that you are restricted in what you can do, which often results in simplier and cleaner code.
Cons are that again you are restricted in what you can do.
Now about CDK is just your preferred language library to write infrastructure in imperative way. For example you write java code that deploys infrastructure.
When using a real programming language you have ofcourse a lot more freedom in what you do, but ofcourse that comes at the cost of complexity. If your developers are “creative” it can be very hard to understand wth is happening in code.
—- So yes many ppl consider Terraform as a golden standard (me included) but after many years of working with it, like anything in IT it has own flaws and you may want to consider other solutions for specific projects.
So without knowing anything about cdk, even if it is declarative, I don’t think your conclusion is applicable.
Terraform, the language, works differently. While it has variables, you can not store state in variables and depend on side effects based on the order you read/write such variables. Every assignment and execution order of resources is purely based on dependency order and not based on the order of the lines in your code.
- CDK compiles Typescript and other languages down to CloudFormation Templates
- Terraform uses the AWS API directly via an AWS-specific provider, and does not typically use CloudFormation stacks (though this can be useful, in some circumstances!)
- Pulumi uses TypeScript and other languages to drive an engine similar to Terraform (and the Terraform AWS provider is one of the options for provisioning AWS resources).
Hopefully this clears it up?
It covers a small subset of AWS services but it is very comprehensive in what it covers.
Running things on prem or on something like Hetzner cloud can be much simpler in some cases, and with Kubernetes now you can provide a great platform anywhere. It just isn't the solution for every use case.
For sure you pay a premium for ec2, but at the least you get good reliability. Your data won’t disappear off S3 unless you delete it. What level of rigor do you need to put in your on premise game to promise the same?
Even for my side projects I nowadays just float an Elastic beanstalk flask app and a small rds instance. It costs 15 a month but I’m fine with that cost for the time it saves me. If you want to be truly cost conscious stick to lightsail. It’s a steal all things considered.
EC2 - $150 production plus few support instances = $500 Egress traffic - $4500
[0]: https://nimbusws.com
I am only familiar with EC2 & S3.
Also API Gateway, if you need.
I bet AWS loses even to inflation. Which means: in real terms - monetarily speaking - their prices went down.
And suggesting Hetzner dedicated servers as an alternative? Why not EC2 spot instances if you’re so budget conscious? It’s just Linux (or whatever you put on them).
We spent big on dedicated hardware in the early days of our biz. Sure we bought bandwidth at 95th percentile which was cheaper. But as our people became our biggest cost we quickly moved into aws and haven’t looked back. Our bill is $500K per year and we happily pay it because payroll would be way more. However it’s the richness of the toolset and on demand scalability that is the real win.
If you need to push a fuckton of bandwidth with little CPU usage you should buy your own metal, colo it and buy bandwidth at 95th percentile billing. We dug up a sidewalk and leased from Zayo to do just that for a specific thing. Most other applications belong in a cloud provider like aws.
Yep. This is the value proposition.
How much of a FTE's time goes to maintaining a scalable, redundant, durable queuing system on par with SQS?
I can run something like 500k messages for free, with all of the same service guarantees as someone running orders of magnitude more.
If I need to run an order of magnitude more? It'll cost $3.60.
If our service blows up overnight and we need another order of magnitude more? There's no pagers, no alarms, no schedule getting blown up as suddenly someone needs to figure out how to scale our queuing solution to 10x capacity... it costs us $20 now.
Sure at some point when I'm passing like 6.5b messages/mo I'll make up a half a non-SV FTE salary that I could instead dedicate to maintaining a queuing system... but why? Most places I've worked were much more constrained with finding good people than paying them. If it's not our core value proposition, I'd rather outsource it and have people working in stuff that adds to the value _we_ provide. That will make us way more money than saving a few bucks on infra costs.
Anytime I see the comparison of cloud vs dedicated bare metal, it seems that the cloud advocates have been doing all their comparisons and calculations based on the alternative being to buy dedicated hardware and maintain it yourself in a colocated data center.
That’s just for one location. If you need redundancy, you’ll also need to factor in those costs. Alternatively, I can spin up a multi-AZ database in a few minutes on a cloud provider.
That's a general problem we have.
Now for a specific project I have, I took it from on-premise to AWS and am saving over 75% than what it was to host on-premise. The majority of the savings was due to software licensing costs. It's expensive to license software on-premise. The architecture of AWS and using their services makes it so those licenses aren't required. Moreover, we've been able to add features to our product offerings that we realistically would not have been able to add while keeping the hosting on-premise. All while saving 75% over what we were paying previously.
My experience has been AWS is faster, cheaper, and better. The business loves it and we're getting more projects. They can't believe how quickly we can deploy new solutions nor how cheap it is for on-going operational costs.
Bottom line - I wouldn't recommend hosting on-premise. AWS isn't the only cloud provider in town, but I would use them over doing anything on-premise.
I bet this is exactly why you find it helpful; rapid scaling is great for when you actually need to scale. I think the post is about the people who don't need to rapidly scale (most customers probably? certainly more common than a F200 company)
Cloud is a vague term that doesn't really point to a specific thing nor does it have the same meaning to different people. "Replacing" a vague concept that may or may not be a single entity seems like a hard case to make. On top of that, the concept of a Cloud didn't replace something else either.
That’s only considering basic usage of deploying stuff on top of an existing cluster. Hosting your own cluster is even worse and one of the reasons cloud offerings are still so popular. If anything can kill cloud it will be a one click get kubernetes in your onprem rack, no config required. Just pass in the credentials and boom, all the nodes in the network just magically join and everything works, including all the often cloud-coupled stuff like ingress controllers. Operationally it need to be as easy as, or easier than, self hosted linux+ansible and deployments need to be more powerful than docker-compose.
Lambda has potential as a proprietary delivery mechanism but it has no real development model. If they doubled down on say a JavaScript SDK and provided UI elements maybe it would work.
I would prefer not to need it, but for large complex applications with a lot of parts, it's a lifesaver.
He is not saying enterprises with ability or need to have large ops teams don’t need AWS. He is saying the average indie developer does not need it.
The post closes with a 100$ example, for very early stage startups or small (most are) apps likely don’t need AWS is the premise .
For me, it's more like they have an automated ops team that my systems can interact with.
Simple integrations, e.g. among cloudwatch , dynamoDb, s3 typically require quite a lot of boilerplate configuration for networking, IAM permissions, provisioning (e.g. in Cloudformation), and the APIs to read and write are needlessly complex . Compare the API for cloudwatch to a logfile or Dynamo to redis.
If you already have unix skills, you will be infinitely more productive with a couple linode instances.
AWS (and all cloud) also has "magic constraints" like iOPS & cpu budget that you suddenly slam into. Your app typically runs fine until a certain amount of traffic reaches one of these budgets and then it suddenly hangs. If you are familiar with traditional resource estimation & constraints – this is an unpleasant and unexpected surprise.
When you run a small startup, these constraints often cause you to drastically increase your budget because the constraint is hit in the middle of business (e.g. upsizing a volume or DB instance to add additional IOPS at the cost of $20-50k / mo)
App platforms like lambda force you to rewrite your code so that it's hard to maintain and nearly impossible to test.
If you want to leverage your skills and have a predictable experience, KISS and run your services on a dedicated host.
Like any choice in technology, there's always tradeoffs. One person/team's complex is another person/team's simple. Moreover there are circumstances that definitively tip the scale in one direction or the other. If egress bandwidth is important to your product, then you're better off going with an unmetered bandwidth solution. If you want to operate as lean as possible, you're better off in a colo. But discussing tradeoffs is a lot more complicated and less satisfying than saying "AWS bad" with a bit of corporate bashing so clickbait is what we get.
One of them did a bunch of stuff that made use of AWS - but it didn't deliver any value to our customers, and probably made our product substantially worse. It cost $30k a day, and unquestionably was not worth the cost, and everyone on the team was fired after a few months.
A lot of companies are fine just using a handful of VPSes.
I think the biggest problem with starting on AWS is engineers are extremely susceptible to playing with new toys - for better or worse.
Engineers are going to try all AWSes new stuff, which is fine. The problem stems from engineers wanting to do stuff on the newest shiniest AWS toy whether that actually makes sense financially or much more importantly in terms of the product roadmap.
If design docs don't at least mention the cost - and your business cares about cost - then you should probably have a chat with the engineering dept.
At a prior FAANG job we included basic cost analysis in our decisions. You don't always need the cheaper option if it doesn't make sense, but you should probably know the traffic that shiny new toy will receive and the cost associated with it. (eg. soln A needs 25% more compute, and the internal price is X vs soln B needs 10% more compute, but will increase storage costs for caching at X per gb for ~Y gb).
I recall a case where a coworker (Senior SDE in Silicon Valley, so easily 25k a month salary) spent a month reducing our $500 SQS bill to $350 because our director wanted to see teams making smart financial optimizations. Meanwhile, our EC2 bill was $50k a month. Not everything is smart financially to focus on fixing. What is the compSci quote on premature optimization?
Of course, if you can't trust your developers to spend money wisely, you need guardrails on cost, no matter where you're spending it.
Sure - not everything at these companies needs to be on the cloud. But when you're dealing with sensitive information, you don't want people rolling their own infrastructure.
[0] https://press.aboutamazon.com/news-releases/news-release-det...
- https://www.youtube.com/watch?v=kzuCnivRoEw
Obviously there are always exceptions, but as a principle you could do a lot worse.
The main alternative is: host the hardware yourself, as it might be enough.
Cool. How many people here are also great sysadmins? Probably a very small number. That's not really an alternative. And furthermore, most of the counter point doesn't really exist.
They just mainly pointed out that "yeah, devops is hard, and lots of things are done by devops that seem simple but arent" but they didn't make an argument that aws is somehow an overnengineering thing that you can avoid if you would only do XYZ and remember that you probably have small scale.
I am. And there probably aren’t that many around here due to the extreme prejudice and derision Developers direct towards Sysadmins. We’re apparently a bunch of low-skill knuckle-dragging hardware monkeys, while at the same time able to do things so difficult that no developer can figure it out so they just go to the cloud instead “to avoid learning all that stuff”.
Very few non-cloud users actually host the hardware themselves. You can rent dedicated servers or even VMs just about anywhere. The hosting company manages and maintains the hardware as part of the monthly price.
Realistic AWS non-cloud alternatives are either colo-ing in a DC, using another semi-cloud provider (OVH, Linode, Hetzner, et al.), or buying a DIA circuit for your office and running your own servers from there.
If we're talking about serverless then I think that containerization (either running containers on bare metal, or on kubernetes) changes the value prop of serverless a lot, because if you've got a container environment you can easily just clone an off-the-shelf production-ready container to deploy your app.
As far as your host OS goes get a production ready image to run your production ready container images. It's a one time thing. Keeping the OS updated? This is not brain surgery every time there is an update. Plus you can configure it to automatically install security updates.
You're stuck on this theme that AWS is somehow akin to scaling. That's one benefit of AWS but it's not the only one. At small scale the margins on AWS are peanuts. A t4g micro is $6.15 / mo. The equivalent on Digital Ocean is $5 / mo. Buying your own Raspberry Pi 4 would be ~ $70 with an enclosure/peripherals, so you'd break even at ... 14 months of running your t4g. This isn't counting the power used (which would probably be minimal on a Raspberry Pi.) That overhead is nothing.
> As far as your host OS goes get a production ready image to run your production ready container images. It's a one time thing. Keeping the OS updated? This is not brain surgery every time there is an update. Plus you can configure it to automatically install security updates.
There's more to it than that. You're just thinking about running software not how packets get from a user's machine to your running software. Most residential connections don't come with a stable/static IPv4. You can update a DNS entry with your changing IP, but then you're down for however long it takes you to change your A record and however long your domain's TTLs to expire. If you pay for a static IPv4 then you've already paid for more than what you're getting from a cloud VPS. Then there's the fact that residential ISPs block tons of ports, have no SLAs on uptime, can drop your traffic without warning or recourse, etc etc.
If you're running a tiny, mostly-static site with minimal uptime requirements then you'll pay less and spend much less effort using a shared webhosting platform. They'll do all the ops for you and you get charged peanuts since these providers usually colo their own machines and run hundreds of sites on them. Dreamhost can serve a Wordpress site for $1.99 / mo with no ops work required. That pays for 35 months of running a Raspberry Pi.
They are valid concerns or at least warnings. You're obviously right that there's tradeoffs but the thing I'm sensing in our industry is that it's increasingly seen as just the default "thoughtless" infra model.
Are you sure it isn't relative to other solutions? I mean sure, you can learn it well enough that it's not complex for you anymore but there is still some objective measure of its complexity that relates to how difficult it was to learn.
Not to mention the lock in...
It's this. There's a growing counterculture that likes to hate on Big Tech, and a lot of these folks do so by making disingenuous criticisms against Big Tech. These criticisms are usually low-effort and inaccurate but the authors know they'll get upvotes and spread their screed because of how popular it is to hate on big tech in these countercultures. It's a shame because there's certainly valid, deep criticisms to offer Big Tech but once it became counterculture-popular to hate on Big Tech then people just began taking potshots where they can.
Criticizing the cloud is a popular one because a lot of engineers genuinely don't know a lot about ops and don't know what a cloud is and isn't, they just use it because a senior engineer at their company made the (usually reasonable) decision to opt into a cloud. Alternatively they're junior engineers that have only written software on their machines and don't know what the difference is between running on a local Linux machine and running a net-connected service. That makes it fertile ground to make unsubstantiated claims because most engineers don't actually understand what's happening.
1) Some people just like the infra work, so they presume everyone likes as well.
AWS eliminates/simplifies a good portion of it.
2) Some feel a sense of superiority saying they can pull off an entire infra on Hertzner.
They know many younger engineers can't, since they started with AWS in mind.
3) AWS has a terrible reputation as an employer.
Perhaps some these anti-AWS blog writers might have worked there, know someone who did, or heard one of the AWS PIP horror stories...
I have to have billing predictability out of my service provider.
I'm not aware of AWS employment issues other than it being a place to burn you out, but the wearhouse side has had plenty of newsworthy incidents.
> Some people just like the infra work
I think AWS improves infra work. Using CDK is a joy - primarily because it's clean, simple, and reproducible once you have stuff up and running. But the process of getting stuff up and running is its own kind of drug, it's a serious puzzle (unless you really really know what you're doing) which I find really rewarding to solve. I'm a pig in mud with CDK.
Compare that with traditional infra work and I immediately start to worry about how to make sure that everything is provisioned correctly, that other people on the team aren't messing things up, how I'm going to implement zero-trust type auth without something akin to IAM, how I'm going to implement monitoring without the monitoring system becoming its own beast....
I'm referring to the traditional infra work.
I think these people should seek a job at AWS, Azure, GCP.
I'm not particularly fond of AWS, but I think they're pretty transparent about pricing of various services - it's linked everywhere and pretty visible, calculators are available etc...I agree about not being able to set limits, though - but how many other vendors do it?
My biggest gripe is the UX of their Console and various services - I'd rate it 3/10 compared to what could be done in terms of design, displayed information and user paths / workflows.
Except that AWS (nor other cloud providers) specifically and intentionally doesn't give me a way to limit charges.
This ... is .. a ... big ... deal.
I'm happy with my site going down if I hit $1000 in charges in a month or $100 in a day.
Maybe some cryptobros broke into my instance because I screwed up. Maybe HN just threw a zillion people at my project. Maybe I just flat-out screwed up and opened an uber-expensive EC2 instance. It shouldn't matter. I don't want more than $1000 in charges in a month without me specifically and personally authorizing it.
The fact that I cannot do this means that AWS (and others) have specifically deemed this to be a significant source of profits. Who am I to argue with them?
Also, things can get pretty complicated when it comes to pricing on AWS. I'm thinking of things like S3 where at first, it seems simple. $x per gb/mo. But then you have egress charges and then operations charges, and then minimum storage time charges, and a half dozen other things that can affect the pricing.
It's obfuscation through complexity.
So, ~$5000 per hour? Either a company cares about $5000 per hour, or it doesn't. If it doesn't, then it doesn't care about $120,000 per day either. If it does, then WTF were they doing running a cluster at $5,000 per hour?
And by definition, anyone who wants to launch $5000/hour or EC2 instances, isn't able to rock up to a COLO or IT department and say "I need 1,000 96 core Intel boxes for a couple of hours."
Literally any other provider that can give you that service will require that you sign up to pay for $5,000 per hour, for how ever long you want to run them. There's nobody running a service that you go inside and ask for $20 on pump number 3. You're giving them a credit card, and then you're asking for an instance limit increase.
The author thinks this is a damning indictment of AWS when a small amount of analysis shows the killer feature underneath. It's what people want: to spend cash, immediately, on compute.
So when I was working at a startup, and I asked our COO to request an instance increase (to 250 instances, backed by his credit card) I made damned sure that I didn't "leave the cluster on". And that cluster gave us 2,000 cores! We couldn't have afforded to buy 250 servers!
Finally, when this happened to a colleague at a different company, we reached out to AWS and they refunded the money. Because if a company allows a developer to launch a $5,000/hour cluster, then that company is already spending a lot on AWS, and will certainly spend a lot more in the future.
That, and AWS has a massive scale that is useful even if you have a single server. When I was on Linode, they got DDoSed and the whole service was inaccessible, even though the DDoS wasn't targeted at my server. They didn't have enough capacity at their POPs to grunt through the DDoS. You can't do that to AWS.
Two words: billing alarms. If you have stuff on AWS, and you don't have billing alarms for actual and predicted costs, you have nobody to blame but yourself for extra charges.
EDIT>> I see they address billing alarms but claim that they only fire after you've lost the money. This is simply not true with the predictive alarms. I get the sense that this author is not using AWS correctly in general.
When I was initially perusing AWS at my current company I was able to save us a ton of (recurring) money simply by properly deleting EBS volumes of terminated machines... someone didn't check a checkbox at some point (and/or didn't understand its significance): oopsie.
It's hard to set alarms early on when you're building stuff out. In any case I think it really needs to be someone's role to understand the billing thoroughly, somewhat regularly. Our billing line items post daily to me on slack, mostly I'll just check the total vs the previous week, and cloudability sends email alarms for specific things and suggests RIs etc.
Their billing cost explorer tool is fantastic. It will show you exactly what services are costing you, broken down by their usage pattern.
And that's if you even have a budget :)
Edit: unless you mean that you'll be within AWS free-tier for a while.
Anything that helps get you to MVP faster is a huge cost-saving.
When else would you worry about lock-in? The early stages of a project involve setting up the foundation. If you build your foundation on vendor-specific tech, you've just locked yourself in or signed yourself up for a very painful transition in the future
You probably don't need that SUV/truck and are better off without it.
You probably don't need that luxury car and are better off without it.
Then go argue about the headache and the price and when you're done, your audience will just go back to their favorite toys. AWS it is. I will never advice anyone against AWS unless they are broke and it will bleed them dry. If you can afford it and have the skillset to run it, go for it. If you also have the skillset to go cheaper, go for it.
It's not that hard to avoid the infamous "AWS surprise". Just pay attention to the costs of things, and check the billing page regularly until you're comfortable with how your infrastructure is affecting the cost.
Devops complexity is a trickier topic. If you're running a startup or a small tech team, AWS can quickly mire you in delays as you become the AWS expert (or delegate one of your engineers to become the AWS expert). It's a lot easier to just use DigitalOcean or something.
That said, AWS/GCP/Azure scale in a way that other providers don't. Not in terms of technical scalability, but in terms of organizational scalability. Once you hire 2 or more devops engineers, it's likely that their expertise in AWS will pay dividends, and hamstringing them with something that isn't industry-standard is going to frustrate them and you.
Who are "you" ? That answer is crucial.
"You probably don't need to pay your power company" could be a similar headline. It's true, we could all deploy generators to power our homes(and handle fuel logistics etc), or go fully offgrid with solar panels and batteries. Why don't we do that?
Let's see - there's the equipment cost, then there's the 'installation' and 'maintenance' costs, often performed by contractors. This often makes the return on investment not worth it. It would make even less sense if we had to constantly tinker with the power solution (or keep someone on call to do that, on our own payroll).
Let's say we have an aluminum plant in the middle of a desert somewhere. It might make sense to operate a power plant tailored to our own requirements. Or pay a company to build and operate one, as it's their expertise.
Somehow, these calculations look different whenever executives try to pitch their "on-prem" or "colo" solutions. I've yet to see a spreadsheet where their own staff costs are called out. Or the potential costs because someone has to rack and stack new capacity, rather than that being automatically handled.
AWS is the 'power company'. They take care of stuff so I don't have to. If I'm pulling too much power, that's on me. Linode would be a company specialized in generator rentals. Some logistics taken care of, I still have to worry about a bunch of stuff. It might be what my shed in Alaska needs.
Now, a discussion can be had on AWS pricing structure (cough network egress cough). I would expect to pay a premium. Sometimes they are reasonable, sometimes they aren't (Hi, NAT GW).
- use requirements to find out what you need, not buzzwords
- comparing services with significantly different properties while ignoring those properties isn't helpful
- playing datacenter in a virtual environment isn't the same as cloud architecture
If you just need a virtual machine to do some stuff and loss of availability, reduced durability and lack of redundancy doesn't really matter, then you can get that pretty much anywhere. The same goes for DNS, object storage and SQL-based storage (ignoring database features). As soon as your needs for availability, durability and redundancy increase, your choices of service providers decrease because not every service provider provides the same servers at the same level. Integration of services is a whole different game as well and equally has fewer providers as the level of integration increases. Also: don't conflate integration with lock-in.
But the real magic comes when you learn to architect entire applications out of their pre-built patterns.
random examples OTOH : fan out messages to a number of lambdas when a SNS topic receives a message . processing + backing up a kinesis event stream w/ lambdas + s3. There are many many cross product integrations that make development about as simple as connecting the two ends of a (data) hose. In these sorts of cases you can trade $$ for velocity pretty easily. Yes it will cost you a bit more to operate, but far less than the humans you save.
Also on the argument about unexpected traffic leading to unexpected bills. AWS is most applicable for businesses that have a strong correlation between traffic and revenue. If you make a dollar per million, then it's fine when you wake up to elasticity unexpectedly handling a trillion. Not so much if you don't have an actual business.
But if you end up with micro services, your tests won't cover the integration of the entire system.
Typically the most important customer features will also have other suites that test end to end (API Call goes in, eventually S3 file is generated or something like that) .
Umm ... No. This blanket statement is certifiably false that it only applies to a company running maybe 1 or 10, or at most 100 physical machines. My work needs across the world presence, networking, fault tolerance and a boat load of storage and compute. I cant shift all those to on-prem or a cheaper, alternative provider.
Leaving cost aside, once we migrated to AWS we could focus on our business more than the environment.
I think you could restate this as “smaller providers need to step up their game” as well.
As far as closing the gap, I’m working on nimbus web services [0] and that’s exactly what it’s for — I want to build the middle layer (hopefully a bit less chaotic than AWS’s) so that people on smaller clouds have access to some scale/abstractions.
[0]: https://nimbusws.com
All due respect, I'm not sure the author knows what they're talking about.
I thought dropbox moved their 30PB+ data lake ONTO aws to get off of Hadoop or something because trying to do this on-prem, even with tons of tech talent and money, was not working.
They complained about onprem requiring 3 YEAR forecasts for capacity planning given their scale.
Here is what they said in 2020 for benefits of AWS:
---------------------
Hosts 40 PB of analytics data and supports 1 PB of data growth a month Optimizes costs by moving cold data to Amazon S3 Glacier Deep Archive Uses Amazon EC2 Spot Instances for 15–50% of compute capacity Doubles compute footprint using Amazon EC2 Spot Instances Enables the testing of new technologies without damaging data or affecting users Improved performance by six times for some job types Deletes hundreds of files in a few seconds compared to 30–40 minutes Runs more than 100,000 analytics jobs and tens of thousands of one-time jobs daily
---
https://www.youtube.com/watch?v=6x-XGJQwk2M
Maybe this has changed since 2020
* integration with the rest of the Oracle suite.
* compatibility with the Oracle database you’ve tightly coupled yourselves to over the last 30 years
* Various incentives for purchasing influencers
But that’s the keyword: _managed_. If you use their (or other cloud provider’s) managed services, you can just turn it on and expect it to be there, available and running all the time (or at least to however many 9s the promise).
You don’t have to worry about configuration, management and maintenance on the whole infrastructure, software upgrades, backups, etc. They take a bunch of worries off the table.
Sure, they don’t do it for free. But if you (like many companies these days) lack manpower in the engineering department, using managed services can be a way to use the people you have more efficiently.
So yeah, approach AWS with caution, be sure you don’t set things up in ways where your costs could suddenly explode. Do the math vs. DYI infrastructure, but don’t forget that your own engineering time isn’t free.
I think there's a mentality about it. When you're somewhat resource-constrained just due to the nature of having to get hardware, it makes you do some upfront design. This magic capacity lets teams punt on the problem.
Like, "We saved a day not setting up nginx, and now we pay for every image we deliver," is not the same as "we saved $100,000 this quarter because we don't need a full-time sysop team." It's worth taking a beat to consider things at these margins.
However, there is not a great S3, Cloudfront equivalent on DO so I need AWS.
For ML/AI stuff, you need Google. There are probably a ton of these little variations.
(I've been pondering using it for file storage for apps that I want to design to be relatively easily shiftable to AWS later if they hit a scale such that they need it, so I'm genuinely curious what you think)
I think so - or its competitor, Google Cloud Platform. Anything beyond a simple software system that you might deploy on heroku up to the complexity of something that requires on-prem infra (e.g. Netflix's content servers, although they're also a big AWS customer) would be a good candidate for AWS.
AWS is practically an industry standard tool. Of course you might be able to find a slightly cheaper way to do things, but training people will be harder.
The only time AWS doesn't make sense is when you hit the scale where it's not longer cost effective.
I set this all up with Terraform, and never touch the AWS UI. The code is 99.9% ignorant of the fact that it runs on AWS.
I used to self host, and then used Media Temple, and then used DigitalOcean. Maybe I'm ignorant of the latest offerings from those providers but creating, let alone maintaining, something like the above without a cloud provider like AWS or GCP would be a significant overhead.
The downsides the author points out are unpredictable costs (this is a risk, but manageable) and vendor lock in (this is low if you know how to code your services using abstract interfaces that hide the underlying vendors).
In a few years there will be a booming consulting business town up around making legacy updates, modernizing or getting off AWS. Goes for GCP and Azure.
AWS is a b2b product and the best one in its category.
Who are you? A hobbyist developer? A small team of 3 devs? A large company with multiple teams of devs dbas sysops?
What's your use case? An occasional Cron job? A small WordPress site? A distributed HA app that manages a huge ingress with strict uptime SLAs?
Where do you want to spend your effort? Happy to apt-get a few packages and call it a day? Need to create and maintain a load balanced postgres cluster with low lag and cross region replication and backups?
There are a lot of considerations that go into choosing a provider. Making blanket statements like this just feel click baity.