They definitely need a senior executive to stand up and say, "The Customer wants us to be transparent in billing, fix that now."
Then they need to start a team dedicated to finding a good way to let customers halt spending at a given limit with minimal impact on their operations.
They already win on UX (okay, okay, it's an opinion ffs), but unlimited liability makes a lot of people very uncomfortable. Those two actions would go a long ways towards demonstrating good faith in that area.
If it would cost too much, maybe they could present it as an easy way to cut expenses at the same time that they introduce a small price increase. This is a common and long-standing complaint/feature request.
As someone that has tried and failed to get some small personal sites running on AWS a couple times, I'm going to have to tag this snippet with [citation needed].
From my admittedly limited experience with GCP and Azure (and this is obviously subjective), the UX in the most successful competition is, at best, no better than AWS. It isn't that AWS has good UX, just that all the cloud providers have bad UX.
Oh man, I have long been joking about the AWS UI. Like how it will gladly walk you through all the steps for launching a server and only at the very last step says “oh you don’t have permission to do that lol, get permission and start over”.
I compared[1] it to a bartender who walks you through an entire sale and only at the last second rejects your purchase for being underage (instead of denying you the at the initial request for something alcoholic).
Of course, that’s one of the minor things in the grand scheme.
agreed especially when compared to say Heroku or Digital ocean. I see many new comers struggling to deploy a small website. It's overwhelming. I understand that Heroku exists for such users and they are using AWS under the hood, but is there any service which takes AWS cloud APIs and simplifies it with a leaner UX?
> agreed especially when compared to say Heroku or Digital ocean.
Funnily enough, I've never ever been able to understand what Heroku is, or how to deploy anything useful on it :) But I'm old, and I've always found it easier to tinker with nginx configs.
Heroku is very simple - you just create an app and "push" code to a repository tied to the app. You need to write code of course, but they auto-detect the language and prepare the environment or platform for you (so platform as a service). They tried to appease the geeks by making everything powered by CLI - but otherwise its just point and click for deploying apps.
Tinkering with nginx is good, but what if you want to add a database, a cache, a logging service? What if you want to automatically build code when you push to github? What if you want to easy clone multiple environments (for staging, prod etc) without never doing an SSH into server? What if you want to have versioned releases that you can easily rollback to a specified version or push a branch into one environment and another branch into another environment? And you get a workable subdomain for every environment you build with SSL enabled. All of that can be scaled down and up with literally few clicks.
> but what if you want to add a database, a cache, a logging service?
I... just add it. How do I add it in heroku where everything is "just create an app and push it" and everything is separate "dynos" (whatever that is), each with different pricing, storage, bandwidth etc.
that is true. everything is a separate dyno - means separate machine/vm to which you need to connect to. You get free tier for almost all databases and you only need to know how to connect to it, not tinkering with the storage, tune the parameters, scheduled backups, automatic scalability etc - that's done for you. it will become expensive once you go past free tier or the cheap tiers though.
> not tinkering with the storage, tune the parameters, scheduled backups, automatic scalability etc - that's done for you.
Thing is: if we're looking for free, that may make sense. you still need tinkering though: you need to figure out what the whole dyno thing is about and how to connect from one dyno to another, and so on.
However, if we expand this a tiny bit to cheap and/or free, then simply running the lowest-tier server at Digital Ocean will be a better proposition. And installing a database these days is basically the same thing: run a command to install, all you need is to connect to it. No tinkering. And it will still probably scale significantly better than a free tier at Heroku :)
Once again, I'm biased and old, and can afford to spend money on side projects. I know that sometimes even $15 a month is out of reach (oh, I've been there). But yeah, this sorta prevents me from ever understanding Heroku :)
I think that's basically what Lightsail is supposed to be. I haven't used it myself, but from glancing at it they're pretty clearly targeting DO/Linode/Vultr etc.
I think there's some verticals - players that simplify/aggregate SES, or S3, or whatever - but none that handle being a layer on top of most/all of AWS.
Have to agree with the others. For example, while setting up ELB it's possible to select at least one option (un-checking the Public IP box) that causes the setup to just fail with a nonsensical error message. Turns out ELB requires a public IP to communicate with the nodes. That's just the most glaring one off the top of my head.
I also remember trying to set up SFTP whenever it was first released. It was literally impossible to do what they were advertising (S3-backed SFTP with jailed homes for each user) without writing a manual json config (I never got it to work). I had built my own solution for this exact thing on EC2, using a bash script more or less, and thought the hosted option would be less of a maintenance burden. Needless to say I quickly gave up.
The more annoying part is that the service only supports public/private key logins. If you want user/pass you have to write a lambda. The lambda is pretty simple though, it checks the credentials (so it can hit any backend you like), and if they pass it returns a 200 with a json doc of role (which is just sftp assume role), policy (the scope down from above), and home dir.
This touches on a larger issue with AWS though. It's that they are trending to leave out functionality and point to lambda as the solution. On one hand, I get it. The lambda solution is infinitely more flexible, but what if I just wanted an sftp for a couple users that uses user/pass?
To your final point, it is so much less maintenance. There is no server to manage, and since I want all the data in s3 anyway, it's already there. This solution replaced a server with chroots, EBS, scripts to move data to s3, etc...
terraform 'destroy' isn't infallible. There are certain resources that trigger the creation of other resources (for example, lambda functions will create cloudwatch log groups, and dynamodb tables create cloudwatch alarms) and when terraform destroys the resource, it doesn't necessarily clean up all the associated resources.
Terraform has it's shortcomings for sure, but I don't think it's reasonable to expect Terraform to go out and clean up second-order effects of it's resources.
I'm not doubting that the situations you describe are true, but abandoning resources like that is an AWS-lifecycle problem, not really a Terraform one.
Sure. My point is just that `terraform destroy` doesn't necessarily solve the problem at hand. And you could still end up continue paying for those second-order effects after running a terraform destroy.
I am pretty senior and can thus sometimes afford to do a new thing and try doing it the right way, at the same time. Not even always. Many people just take one learning curve at a time...
Typically Terraform takes longer to get something working than mindlessly clicking through the console. In my experience those mindless clickthrough things end up sticking around for years even when they weren't intended to.
This is why you have separate development and production accounts: a development account where you mindlessly click through so that you can learn through the UI what's available and how it works; cleaned up on a regular basis by something like aws-nuke, and a production account where you have the discipline to only create resources through Terraform / CloudFormation etc.
Even CDK sucks though because if you’re still kinda new to it all, you want to login and make sure that it’s all hooked together correctly. And you’re back using their shitty UI.
Why you can’t look at the load balancer, look at the listener and then show what’s in the target groups is beyond me.
I have a different take on it. I started out doing everything through the console, then learned the cli and boto3, and very recently CDK.
CDK is another tool that build on the cli and boto3 concepts, and also manages the orchestration and dependencies.
Having to go back to the console isn't a fault of CDK. Learning the right tool to use for a situation is part of the learning curve. I go back to the console all the time to look something up quick or to understand what config options are available. Or I repeat the same steps in the console enough times that I get bored with it and automate
Edit: also I tried and have given up on CloudFormation more than once. CDK is like a wrapper layer around it, and has been pleasant to use.
It either works great or barely depending on the service you're using - some AWS teams have dedicated dashboard teams, eg 'ec2 dashboard team' which solely focus on the dashboard experience, while others touch it as an afterthought.
I'm pretty sure something along the lines of this^ was posted on HN by a former AWS employee but I can't find it now.
Their web console UIs vary widely by service. IMO, the UX for most of their simpler services, specifically SQS, S3, Lambda, DynamoDB, are really easy to use and work nicely. If you want to start with a Docker image, send it to AWS, and have it get spun up and attached to a DNS, well that's a huge complex mess to get set up.
Unfortunately, modern regulations forbid manufacturers from easily making a "dumb car". For example, backup cameras are required in new cars.
It's the same deal with avoiding wire insulation that rodents enjoy eating. Your only option is to buy a car from before 2000-ish.
I'd actually like to find a DIY subculture of taking old car frames and swapping in newer features a bit at a time. People do it with electric motors, but it still seems hard to get decent range/mileage/etc on a DIY EV project.
And buying a pre-2000 car involves giving up a lot of safety. That’s before regulators started looking at partial offset crashes, so older cars perform poorly if you clip a pole or oncoming vehicle with one of the headlamps.
You gain basically nothing in safety from the adoption of airbags in the early 90s to the improvements in roof strength and passenger cabins in the mid-00s (many models had their improvements in the early 00s because the regulations were known in advance). From there nothing changes until the proliferation of side curtain airbags.
Does NHTSA recommend rearview video systems?
Yes. As of May 2018, NHTSA requires this lifesaving technology on all new vehicles. We recommend you look for RVSs that meet NHTSA’s performance specifications when shopping for a vehicle.
The actual requirement is a series of rear visibility tests that are done on a vehicle through the full range of seat adjustability.
A rear view camera allows any vehicle to meet the regulation regardless of vehicle styling and design. They are cheap, too.
But they are not strictly required. Your average 1980s sedan probably would meet the requirement as long as it had mirrors on the driver and passenger side.
You're not wrong but in practice they're all but required because the corner that fuel economy and cabin strength requirements box you into is a corner with really high belt-lines and really poor visibility. You couldn't build something that's the shape of a 1990s sedan today.
Absolutely insane. I wonder how much cheaper and better a modern car could be if I didn't have to pay for legally-mandated safety features that A) are probably not utilitarian B) I don't even use.
For example, I am 100% certain that the benefit of having an airbag between my legs does not outweigh the monetary cost plus the comfort cost of not having an AC vent under the steering wheel.
>are you saying that you think AC between your legs is a worthwhile feature but airbags are not?
Why should people not be allowed to make that choice?
Keep in mind that the only reason we have airbags is because Naderites did not believe that one could rely on people using seatbelts so there needed to be technology that did not require cooperation from humans.
Fast-forward a couple of decades. Oooops. Airbags have no use without seatbelts and provide only a small amount of additional protection in most cases (thanks to crumple zones and improvements in shaping the interior of the car).
Crumple zones themselves aren't really that big of a win either. They basically just buy time to set an airbag off unless you just so happen to crash into something approximately like what the crash tests use at whatever speed the relevant crash test is at. A little blow that speed it will be too stiff to do much. A little above that speed the car will blow right through it like it's not even there.
The real benefit is in rigid passenger cabins that keep tires and engines out of the occupants legs.
IMO side curtain airbags are a far better safety improvement than frontal airbags because the safety technology in the sideways direction and space for dissipating force is lacking so something needs to pick up the slack.
Well, safety features also benefit the people who ride in your car with you, and those people weren't necessarily involved in your purchasing decision.
There's a happy medium somewhere. In an ideal world, we would regulate what is really important and ignore what isn't, but we're still figuring things out.
Personally, I like the idea of universal sunsets to deal with the difficulty of repealing old regulations. Codes could be reviewed on an N-year basis, with old rules requiring a cost/benefit analysis and 'yes' vote to renew. But in practice, those kinds of processes seem to end up with people rubber-stamping "last year++" revisions, like with the USA's defense re-authorization acts.
Then they need to start a team dedicated to finding a good way to let customers halt spending at a given limit with minimal impact on their operations.
They already win on UX (okay, okay, it's an opinion ffs), but unlimited liability makes a lot of people very uncomfortable. Those two actions would go a long ways towards demonstrating good faith in that area.
If it would cost too much, maybe they could present it as an easy way to cut expenses at the same time that they introduce a small price increase. This is a common and long-standing complaint/feature request.