Hacker News Reader

Comment by pritambarhate | Hacker News Reader

It's sometimes very frustrating the poor UX AWS forces on its customers. If you read the post, they have made the high-speed network available, but you can use it only if you use the AWS cli.

> Enhanced networking cannot be managed from the Amazon EC2 console. [1]

AWS (and other cloud providers) charge a huge premium compared to smaller dedicated and VPS providers and yet the customers need to suffer things like this and that too when the product has been available for around 11 years.

The complexity of AWS billings system is astounding. Setting the billing alarms is somewhat easy now (using the budgets features), but still needs some careful reading about the options available.

It seems like the ease of use is near to the bottom for AWS product managers.

[1] https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/enhanced...

View on HN

So, I remember when EC2 didn't have a UI at all: it was just a set of APIs and a handful of command line tools which were mostly for use as a demo. The entire concept was that you were either going to use the API directly in order to build a fleet of automatically-scaling servers or you were going to cobble some system management shell scripts together that just ran the command line tools. For some services, a UI really makes sense (like Route 53), but for EC2 a UI is only going to be usable if you want to boot like, a handful of one-off hand-configured machines... that isn't really the use case for EC2. I mean, I do do that, and to be honest I have often used the UI to do it, but the only reason is because searching for the current Ubuntu AMI is easier using the UI... otherwise, using ec2-run-instances is pretty simple, and I frankly shouldn't be doing that as those one-off hand-configured servers are the bane of my existence when it comes to later system maintainability.

It just isn't clear to me what the job of a user interface is to EC2 other than as a kind of fallback / emergency dashboard for when your software loses track of what you have running; it is essentially the Task Manager / Activity Monitor of AWS: a tool you only use when you screwed something up or have to fix something by hand. The kinds of workloads that you do with EC2 just don't map well to a UI without some kind of deep framework integration (such as "understand enough about my database server stack to determine that I've run out of connections in order to trigger an autoscaling event"; the way you'd normally do that is by building a custom CloudWatch metric with a daemon on your database server, at which point the software you wrote is probably handling that <- if what you are looking for is so specific, you usually want to be using a more dedicated/SaaS part of AWS or using a service like Heroku that is built on top of AWS).

I guess maybe the disconnect is that you seem to feel like "smaller dedicated and VPS providers" are a competitor to EC2, when in my mind the entire reason someone would use EC2 is because they need to do something you fundamentally could never do before using those existing services: automatically provision as many machines as you want, all of which become available within minutes, and where you can turn off machines you don't need and be build in by-the-hour increments. That was just fundamentally never possible before, which meant for the kinds of use cases for which EC2 was designed (workloads with high variance, whether temporary high-throughput batch jobs against data stored in S3 or services that have periodic or even unpredictable usage) they could be charging three or four times as much as their competition and you'd still use them, as to use their competitors you'd have to have five times as many servers constantly all doing nothing but burning cash.

Your comment is so important to grokking and exploiting the full value of public cloud.

I happened to be on the front row at re:Invent listening to Andy Jassy’s keynote with another AWS Customer Advisory Board member who has used EC2 since launch.

We joked it might be dangerous to drink a shot every time Jassy said “just click” or “with a click of a mouse”.

As believers in the value of repeatable declarative “infrastructure as code”, we were dismayed at the increasing tendency to prioritize “AWS Console” web UIs over APIs for a number of AWS capabilities.

> If you read the post, they have made the high-speed network available, but you can use it only if you use the AWS cli.

You're misinterpreting the documentation- as long as the AMI you are using or are basing your own images off has support for this high speed networking you will end up using it without taking any additional steps.

If you read their instructions for enabling it on ubuntu it starts off with this-

> The latest Ubuntu HVM AMIs have the module required for enhanced networking with ENA installed and have the required enaSupport attribute set. Therefore, if you launch an instance with the latest Ubuntu HVM AMI on a supported instance type, enhanced networking with ENA is already enabled for your instance.

That being said I don't disagree with your premise, as the AWS Console is not exactly known for being user friendly.

Yeah. Quick, what are the restrictions for this identifier? Letters? Spaces? Dns? Globally Unique? Who Knows?

Even though they've got the validation, you only can tell once you submit and it complains.

Agreed. It’s ridiculous you don’t even see the price of an instance when you’re launching it in the console. In fact I usually look it up on a third party website.

Compare this to GCP that shows a live price updated on the side of the page as you configure different aspects of the instance.

In Amazon's defence their billing system is far more complex than Google's, not because Google have done some marvellous job on theirs, but because it is a solid decade younger and hasn't caught up with all the bells and whistles yet.

The price you pay for an instance not only depends on what you've already spent up to that moment in your account, and all accounts attached to the same organization, but also any reservations in those accounts which may /float/ into your account should they not be used in their home account, and crucially, _the price varies according to what you use, and every associated account uses, in the future_.

Finally at month end, your entire account receives a bulk tiering discount that cannot be calculated until your full usage is known.

If you have 1x t2.medium reservation and there is already a t2.medium machine running in the account, the price displayed would likely be the on-demand price. However, if after starting your new t2.medium you kill the old one, the price _applied_ will likely be the reserved price -- so long as both instances did not use more than 60 minutes runtime in that hour.

You can however, get a reasonable preview of your daily spend with 24 hours lag using Cost Explorer, which I think is more than resonable considering it is a meaningful, comprehensive account view, and not some tiny datum associated with a single item on your bill. For anyone spending serious money with either Amazon or Google, there should be a large upfront modelling step involved before stuff starts to get purchased, no per-item price preview can avoid that.

Meanwhile I wonder if Google's display price reflects sustained use discounts or committed use discounts. Given how underbaked most of Google Cloud is, I suspect (before ever having to look!) the answer to that is a resounding "no".

So the question becomes, would you prefer no information, or information that may be off by in excess of 70%?

A lot of the complexity parent describes in billing is Amazon's own fault for their user-hostile "reserved instances" feature. If Amazon canned reserved instances and replaced it with automatic volume discounts, or just discounts, then they could well simplify billing quite a bit. But they made design mistakes by introducing reserved instances in the first place, they've dug in their heels on it with revisions, and they don't want to give up the fatter profit margins they get from this differentiated pricing.

Parent attributes that to Amazon's age, which I agree has merit. But if Amazon has become inflexible and impenetrable with age, then we should up and leave for better platforms.

Google offer reserved instances too. They're called committed use discounts

They are not comparable. On google you pick a continent and a number of CPU to reserve. On AWS, you have to pick 10 different parameters for the exact reservations you want and you better not miss it because you can't change.

AWS billing model is not only antiquated but hostile to their users.

Half of the parameters relate to features Google doesn't support yet

- instance type - Google schedules you on whatever random CPU they have at hand unless you specify otherwise, with no ability to reserve capacity ahead of time, never mind tying it to a particular hardware architecture.

- placement - Google does not offer single tenant or dedicated placement instances

- scope - Google does not offer capacity-reserving discounts

- convertibility - Google does not offer reservation of particular hardware types, so this option makes no sense

But give it another a few more years, and let's see what their billing offering looks like then

The one thing it looks like Google really did nail here, though, is decoupling bundled licensing from their discounts. With AWS when you buy a RHEL reserved instance, it's a RHEL reserved instance.

Google has everything. See sustained use and committed used discounts.

https://cloud.google.com/compute/docs/sustained-use-discount...

https://cloud.google.com/compute/docs/instances/signing-up-c...

Did you even read what I wrote? They offer neither single/dedicated placement, capacity reservation (nor for that matter arch-specific capacity reservation).

Meanwhile thanks for those links - I didn't realize Google, despite having such a youthful billing system already has the mess that is Instance Size Flexibility, they just call it "inferred instance sizes" instead, nor did I realize their discounting scheme is in fact _more complex_ - committed use discounts are mutually exclusive to sustained use discounts.

That's even harder to model upfront than AWS' offering!

Disclosure: I work at Google on Google Cloud

What kind of hardware architecture do you want? You can reserve CPU type easily (https://cloud.google.com/compute/docs/cpu-platforms), including if you need it to be "Anything newer than <x>".

Also, sustained use discounts AUTOMATICALLY discount you (including binpacking a bunch of machine, so let's say you ran 4 machines for 7 days at the beginning of the month, you'd get the discount of running 1 machine for 28 days).

To play devil's advocate it is a platform for building scalable systems, not everything is going to be point & click & their users are fine with it. Their business model is providing infrastructure, not UX. Even amazon.com the marketplace does not have great UX, and if you view source their code is messy, it just goes to show it doesn't matter.

Other cloud providers may have a 1-click UX to deploy a load balancer, but they lack features Amazon has, like logs... once your app needs to scale you don't care about 1-click UX, you care more about how easy it is to debug & scale your platform...

Good UX can also make complex applications simpler to manage. Also, not all applications are complex and have a huge scale. There are many IT admins who need to manage a lot of small applications that support small departments.

Also, I think AWS can have both. Great CLI and APIs to deploy complex infrastructure, and great visual UX to operate, monitor and manage it. I think we as customers should demand it. If we won't let them know of our pain, how will they know? I hope they are listening.

There are security issues that stem from the crap UX. Ever set up an encrypted + restricted S3 bucket? You need to mess with AMI + KMS

Angel’s advocate.

Those using the APIs for repeatable infra are on the side of the angels. :-)

It's amazing that not more people realize the complexity is by design and intended to be so. There is a thriving AWS consultancy business that relies on AWS being overly complex. This in turn incentivizes hundreds? of thousands of consultants to push AWS to their clients over simpler solutions.

This is pretty wrong.

AWS makes money from usage over consulting, and the stock value multiple on recurring usage revenue is many times the stock value of consulting billings.

AWS is relatively straightforward to developers who know infra or sysadmins who can code. But now AWS is rebalancing the API-first model and prioritizing GUIs because that drives sooner usage from traditional enterprises with ITIL IT guys who don’t want to code.

These are the same enterprises spending money on consultancies (mostly not on AWS consulting, even a decade after launch AWS still has a tiny fraction of the professional services that an IBM or an HP has) to decipher an API-driven infra and make it palatable to the mouse jockeys rather than replace dozens of manual admins with a developer or spend money training their admins to code. (Then the consultants leave and the company has no idea how to use infra-as-code.)

The enterprises are doing it wrong, AWS is accommodating them because otherwise enterprises will mess around for four or five years and never manage to move any significant percentage of workload and AWS won’t have usage revenues.

Reply on news.ycombinator.com