What's the portability blocker with git? It's pretty easy to pull your repo and clone it to a new server, and you keep your history and everything I thought.
Nothing. That’s why SaaS providers like GitHub start to build up features like GitHub CI to lock people in. You can easily move the repo, but moving your full CI has a real cost that businesses will take into account when they are considering to move anything.
What do you think, what is the business for GitHub in providing limitless private and public repo hosting?
I agree with you at some degree, but I would like to point out that AWS pricing is much more complicated that you can calculate how much will you pay from a static number showing up on the UI.
If it bothers you that you need to open two tabs for cross-checking the costs, you may want to avoid every cloud provider, not just AWS.
Once you have NAT gateways, CloudFront, S3, auto scaling, loadbalancers, etc, calculating the cost becomes an art rather than an exact science. And if you don't use these, there is no point of using AWS, there are plenty of "cheap" VPS providers.
I think AWS billing is quite complicated that they probably don't even know what did you get charged specifically for this machine.
You might have leftover reserve instance that applies, which make the listed price inaccurate. That reservation might even be in a different AWS account in the same organization that you don't have access to. That reservation might not even be there between the time you quote and the time you actually launch it if someone/something did launch before you.
Your organization might also have discounts. I believe some discount may also be very confidential. For example, my reseller policy is that the customer must not be able to see AWS Billing in the organization root account as supposedly the price in that console are the price AWS charged the reseller, while we pay listed price minus any discount we negotiated ourselves.
Finally, I suppose they don't want to have prices shown in multiple places as they will need to update it when prices changes. Doesn't want to risk forgetting one place and getting sued for it. You can see that AWS documentations often do not want to mention the price at all, even if that price is currently free.
Chinese clouds kinda make this simple by making reservation part of the buying machine itself - you have to mark that particular machine as monthly/yearly committed when you start it (or convert it later). The complicated part is recycling instances - if you delete a server before its reservation ends it ends up in a recycle bin that you need to look before making new reservations.
They don't know in advance how much bandwidth will you use, how much traffic will you have, what auto-scaling rule will it trigger, etc. It's not obfuscation, it's billing based on your usage. And as with everything in life, there are tradeoffs.
Give me a slider for bandwidth used or a formula where the variables are abstracted away. If a computer can tell me how much I owe, a computer can be made to show how it came to it’s conclusion.
IMHO it should be illegal to force consumers to have an infinite spending limit on a post-paid service with consumption charges. If I want to cap my unpaid expenditure at any amount, I should be legally entitled to do so.
How many real applications actually want this behavior? AWS is not built around hobbyist needs. It’s built around being a platform to run most shapes of production use cases.
This has been a feature request since AWS was a thing.
>AWS is not built around hobbyist needs
Yes, as if no startup teams are tasked to remain within hard spending targets when they're trying to build a POC with technologies that they are not initially experts in.
It's very common for companies to have a $1M/year contract that depends on $100k/year in AWS resources. (and maybe they have 3+ such contracts.) They could lose a contract if their account gets shut down for nonpayment, it's hard to say how much of an overage they would prefer to having their account suspended, but AWS is optimized for these kinds of customers where every dollar spent on hosting drives some multiple of revenue.
You can set up cost-based alerts (actual or forecasted) that send notifications via email or SNS. Based on this you can set up automations, such as applying an IAM policy to prevent further resource creation, shut down resources, etc.
Interesting to see that some people assumed there are no kill-switch mechanism, and when it turns out they just did not know about it, the (totally valid and factful) comment gets downvoted because it is against their initial assumption. Not what I would have expected on a professional forum.
I do not downvote comments when I disagree, and I think it’s better to explain why I would strongly disagree. Downvoting in this case almost reinforces the notion that the downvoted comment makes such a good point that it causes people to give up on the discourse and just smash the panic downvote button. It’s obvious to me why this is not the case for this comment.
The suggestion to setup some kind of IAM policy to shut things down and stop resource usage is insanely complicated for users who need this kind of feature the most. If I’m learning AWS and just added my CC to it, I am the last person to be qualified to setup this kind of an alert and policy from scratch. This needs to be a single text input in the billing page, like it is for countless spend-as-you-go services. When the limit is hit, the service needs to stop the usage at the customers peril, because that’s what they customer requests.
> The suggestion to setup some kind of IAM policy to shut things down and stop resource usage is insanely complicated for users who need this kind of feature the most.
We set this up at my last job like in 10 minutes. Complexity is a matter of perspective, and if your job to do this, you have done this many-many times, and you have ready to use infrastructure as code templates.
Yes, AWS is massive, the documentation is huge and makes things inherently complex, but flexible too. You can define what behavior do you want when you exceed your limits. We can argue whether this is obfuscation or complexity or what, but based on my experience AWS optimizes it's product for enterprise-ish companies, that can afford to have SREs who knows exactly what to do in such cases. That is where they have their own training/certification program.
For simple use cases there is AWS Lightsail where pricing is simple and easy to understand.
But even if it would be insanely complicated, that is a reason to downvote? HN used to be better than this kind of "I don't like your comment, let's downvote it".
Sure, but providing estimated costs based on reasonable pricing buckets alongside the options to add the new machine is something that every other vendor manages to do..
...and AWS does it too. I can go right into an account and see an estimated cost per hour, and even pre-pay at a fixed discount for longer terms if I want to. They tell me right there what it will cost. They do this for everything that is reasonably a "fixed cost", like CPU time.
They cannot predict what my bandwidth consumption will be, or other such variable costs. For those, they tell you rates.
No it's pretty bad. They show you the cost after all the resources are set up. Even setting up an ec2 instance, a really basic use case that has a fixed cost based on size, you have to go Google it and find their ec2 pricing table. It would take no space to just put the price per hour in the drop-down as you're picking an instance. But no, they obscure it on purpose.
That's just for ec2. Everything is like this. Super awesome when you're being brought onto a new project and trying to estimate costs for your client. And let's not forget the little tiny things that should cost nothing. A NAT gateway with no redundancy is $30/mo. That's a fun surprise.
> Even setting up an ec2 instance, a really basic use case that has a fixed cost based on size, you have to go Google it and find their ec2 pricing table
For the record, my original complaint that ec2 did not have pricing in the dropdown seems to be untrue right now, which is great! For the sake of UX discussion, I want to talk about your picture as if that were the only way to get this info. So let me explain why that's bad.
The main reason is this is only true for ec2 and every other resource has its own slightly different way of getting the cost, making it really easy to miss things like this. But here are the steps we take to get to your image.
- First you click compare instance types, and you're brought to a completely different page with a table.
- By default, there is no column for pricing, but two columns for "storage space" even though most of the instance types have these blank.
- There's nothing that says you can add columns to this page. You eventually figure out it's the gear icon.
- Then you click the gear on the top right to look at column names. You try searching the 44 column names for "price" or "cost" but both of those turn up blank, because there's no fuzzy searching.
- So rather than use the search box, you manually scroll through all 44 column names and find pricing at the bottom of the list.
This is the definition of out of the way. It's hard to imagine why you would default to showing two different storage columns over the pricing column, when half the instances are blank on storage.
Now do FSx, which has no pricing information at all, or any links to pricing information. They have an info tab telling you your backups are incremental, which would make you think they are fairly inexpensive. Not more expensive than the filesystem itself!
This is simply because AWS UI is not made by one team. Each individual team makes their own UI/UX decisions, and things like pricing info just get forgotten and/or scheduled "for later".
So they just added a default table widget, and they didn't even bother with customizing it. You can enable the context menu for the table's rows, which works and is empty.
I worked at AWS around 6 years ago, and we had a great win with just getting access to a service that provided the full list of available instance types and base prices.
This kind of disjointness is both good and bad. It's good in the sense that individual services stay within reasonable complexity, and usually all the functionality is available through the public APIs because the UI console is just another consumer of these APIs. AWS is also very careful with permissions, internal services try to avoid escalating privileges and try to perform everything using the user-visible access policies.
But it's bad because integration just sucks, and the UI layer is the ultimate example of this. AWS console _is_ really messy.
And to add to this: AWS teams were also quite focused on avoiding surprise bills for customers. Because surprise bills led to customer support interactions, Sev2/3 tickets that needed investigation, etc.
Price simulators are fine. They also know the distribution of use. They can do cost plus pricing (many cloud providers do). You're defending deliberately obfuscated pricing when it need not be obfuscated.
Yes, as long as you do not have seasonal traffic, auto-scaling, spot instances, burstable instances, saving plans, reserved instances, floor/custom pricing, etc. These are tools to optimize your spendings and spend less if you know what you are doing.
> defending deliberately obfuscated pricing
A bit contradictory that price simulators are fine, but then the pricing is deliberately obfuscated. Then which one?
As I read through these comments I’m thinking about the dynamic range of AWS customers: from my little hobby account to my business account to some hyper-scaler’s account.
I think about the diversity in usage patterns: from generating giant video stream broadcast somebody trying to calculate yet another digit of pi. It’s wild.
Is true, probably, that AWS doesn’t know how much anyone’s use case will cost (even when it’s yet another version of something we’ve seen before). Too many variable.
If only there were some kind of software with a text based, natural language interface that we could ask a question like “how much would it cost to do XYNZ on AWS?”
I don't think your comment hits like you think it does. I think your intent with "cheap" implies some level of being lesser. In my experience that is not the reality. Similar to opp I migrated a startup from 5x cost in AWS to DO years ago. In fact that "cheap" competitor was able to give them better performance, more reliability and more features for a lot less.
AWS is almost never required and almost never the best option. It's the Cisco of options, it's often the default but for no good reason other than someone on the team probably knows enough about AWS to make it work.
Almost every startup I've worked at has leveraged AWS as their primary but when not they end up using AWS for something. And in every startup there's always contention with AWS spend and all of these startups invest significant time and, funny enough money (via cost savings products or consulting), to reduce their AWS bill. And yet, they never seem to try anything else. Doomed to the cyclical cost savings cycle. Amazon knows this and the UI/UX is designed to keep companies in this money burning loop.
Finally, AWS isn't a silver bullet. For anyone in us-east-1, you know [0].
> Finally, AWS isn't a silver bullet. For anyone in us-east-1, you know [0].
I probably should have commented on the original article here, but I pulled all of my company's production infra out of that AZ back in 2019 because AWS dragged its feet for too long deploying 5th gen hardware there.
I assumed the racks were full or something. I still don't know if they ever did get newer hardware in that AZ—I just avoid it like the plague.
I had a light chuckle this week when I discovered the work I did out of sheer frustration saved us from a partial outage seven years later.
Not showing the price was not "my problem". It was the sign of a product packed with traps, footguns and all kind of things that would go wrong and the blame goes to the user.
> It was the sign of a product packed with traps, footguns and all kind of things that would go wrong and the blame goes to the user.
I spent 5 years optimizing spendings on AWS at various companies. Yes, it does come with traps and footguns. On the other hand if you know what are you doing, there are plenty of tools to optimize your spendings with RIs, saving plans, auto-scaling, etc, and spend less than the list prices.
Based on my experience AWS for the companies that can afford to pay surprise bills out of pocket if something goes wrong.
In completely unrelated pages to where you setup resources, yes. Ec2 pricing is in a random doc disconnected from the AWS console.
They absolutely could to you a base price on the ec2 setup page, but they don't. And I have been absolutely surprised by pricing. Services that do almost nothing could cost more than your ec2.
Respectfully, I think this is more of a use case where you aren't the target audience for a service like AWS.
I've been working with AWS for nearly 10 years. Many people I know, both small and large, just don't even use the console. If I need to figure out how much a project costs I use the AWS pricing calculator. Having an ec2 pricing on the pricing page is meaningless once you spend any meaningful amount of time in AWS. Once you add discounts and reserved instances, that number is going to be inaccurate anyways.
If you just need a VPS provider, there are better, less complex options. I find these complaints kind of like stepping into an F1 car and complaining that the F1 car is deceiving you because theres no fuel gauge.
I'm a contractor, so my deployment complexity is whatever my current client's complexity is.
> If you just need a VPS provider, there are better, less complex options. I find these complaints kind of like stepping into an F1 car and complaining that the F1 car is deceiving you because theres no fuel gauge
That's fine if you feel that way. The article and following discussion is clearly about the smaller audience, and I think you're underestimating how far up these little problems stack and scale. If a couple grand is a rounding error to you, that's great. Most businesses fall firmly in the place where that would be a problem.
I think there is a value add for large companies on AWS, but for smaller ones, I don't particularly feel like AWS is an F1 car, more like a self driving Tesla that locks you inside when it's on fire. And I find the cavalier attitude that these companies aren't important enough to add the distinction to be exhausting. AWS is being pushed on everyone.
AWS is being pushed on everyone the same way Hadoop was pushed on everyone in the 2010s and IBM in the 90s. Everyone sees themselves as webscale, when their data can reasonable fit in Excel. If the only product on AWS you are using in EC2 and S3, you are choosing the wrong tool.
The complexity of AWS is because a service like AWS is complex. Neither Azure or GCP has any less complexity. DigitalOcean offers way less services and as a result is way less complex.
>And I find the cavalier attitude that these companies aren't important enough to add the distinction to be exhausting
They aren't important in the same way a F1 car doesn't think families are important enough to add a back row seat. No company is going to have fidelity to serve a perfect product to every market. The frustration comes from the misplaced belief that a product should serve every kind of user in the market.
>I don't know of anyone saying you should buy an F1 car for your family, do you?
It's a metaphor. Your clients telling you they need you to deploy on AWS are the kind of people I believe are telling you to buy an F1 car to daily drive to whole foods. You said it yourself: "AWS is being pushed on everyone".
>I do see people in this very thread with very different ideas of when AWS makes sense for you.
Naturally. However, 99% of, what I believe are illegitimate complaints of AWS (AWS has tons of legitimate complaints), are from people who were probably better served by a using a simple VPS provider than a cloud provider. A VPS provider is simpler, easier to understand wrt to pricing, and cheaper. Most of the complexity in AWS comes from the fact that AWS itself is a very complex tool targeted to large organizations and deployments where people aren't using EC2 instances, or are using 100s of them. The complaint that the UI doesn't have enough affordances when trying to create a single EC2 instance is kind of ridiculous when you consider it's a tool designed for people launching 100s of instances. Nobody is reasonably launching 100 instances through the dashboard. Furthermore, if vendor lock-in is a concern you have AWS is the wrong tool.
Likewise for IAM. People complain a lot about IAM. But AWS has thousand different user types, and a 1000 different services. I've written my fair share of permission systems with a fraction of the amount of permutations. They always become complex due to the combinatorial nature. GCP manages to somehow be even worse. But you wouldn't need to deal with something like IAM if you just stuck with a VPS.
Replying to myself, this is not true anymore, for ec2 at least. I think that my comment was upvoted so much really speaks to how chaotic and inconsistent the UI is, because you get a totally different experience using other services.
For instance, I don't see any pricing information when setting up an FSx filesystem, even for the size you setup. And there's definitely nothing saying backups will cost you more than storage (even though they are incremental?)
Not unrelated pages. All AWS pricing is and has been for a very long time posted on predictable pages alongside the service marketing and documentation. The console is the console. I, for one, don’t want to see pricing in the console or in cloudformation or CDK documentation — because if in one then in all, right?
> The reason this blog post does not come with any concrete examples how to use this enablement for useful and constructive things tells you something very important - it is a toy and they do not know who and how they will use it.
Every time I come across AI projects and AI integrations (including my previous job where I full-time worked on one), no one was able to show me concrete examples how can I use it for constructive things.
Not the one down-voting you but I suspect IPv4 and IPv6 will run side-by-side dual-stack at least until 2050 and IPv4 would not be fully deprecated until probably 2323 star-date 0 as future quantum interstellar communications subspace will deprecate both standards. Only half kidding as nothing ever gets deprecated or decommissioned until it breaks something important.
The question isn't whether this took longer than a weekend or whether you personally have open source experience, it's whether Emdash is actually being built as an open ecosystem or as a Cloudflare-bound platform. Bringing up your background reads like using prior credibility to justify the project's quality, instead of demonstrating it.
If it only runs properly on Cloudflare's infrastructure, then invoking "understanding open source and community" feels misleading. Those values usually imply portability and independent ecosystem growth, not tight platform coupling.
Also, "not vibeslop" here isn't about effort, it's about whether there's a clear, defensible reason this exists beyond being an AI-accelerated WordPress-like system tied to one vendor.
I think pretty much every corporation that can have had this thought, has had it. Really "any popular software" where they can provide similar functionality. And I think this is going to happen more often before it becomes less common.
reply