Tell HN: $13K Sales for “The Good Parts of AWS” on Launch Day
11 comments
At a conceptual level, I support this, but there should be no need for a cottage industry to explain how to use AWS. The UI is a nightmare. I have to open my browser's element inspector to see full docker image names in ECR. That's atrocious for a product that brings in billions. Clearly the UI's deficiencies "don't matter" to AWS' success, but they could try a smidge harder to make user's lives easier. But they likely won't, since it's business, and many of us using AWS aren't doing so by individual choice. But next time, when I am the decision maker, ...remember that, Amazon. People (individual contributors) do occasionally ascend upwards in technology organizations, and they will know what it's like to use your technology, and it will absolutely influence decision making.
For any proper use the AWS console is nothing more than a brochure of what you could be doing.
If you want to use their services properly, read the documentation for the ones you have chosen and use proper tooling that provides repeatability (for the lack of a better word), provided by AWS themselves or by a third party.
If you want to use their services properly, read the documentation for the ones you have chosen and use proper tooling that provides repeatability (for the lack of a better word), provided by AWS themselves or by a third party.
The thing is, even “proper tooling” is a nightmare.
Tons of consistency issues in APIs, poor documentation, boto3 is atrocious where services names are passed as strings and why not use ‘args’, ‘*kwargs’ so you don’t know how to use the method by looking at the signature.
I had to implement s3 presigned URLs generation as we had no access to SDKs, the documentation is littered across their website, you literally have to go through dozens of pages to compile enough information.
Their quota system is borderline frightening, there is so much individual limitations that you may really never know if some limit is not gonna blow up in production.
Not to mention their voluntarily incomprehensible pricing. You may brankrupt your company just doing a few API calls and anyway, I generally found the overall quality of their products so poor that their premium just kills it.
Every time I know I’ll need to use one of their service, I prepare for the pain.
Tons of consistency issues in APIs, poor documentation, boto3 is atrocious where services names are passed as strings and why not use ‘args’, ‘*kwargs’ so you don’t know how to use the method by looking at the signature.
I had to implement s3 presigned URLs generation as we had no access to SDKs, the documentation is littered across their website, you literally have to go through dozens of pages to compile enough information.
Their quota system is borderline frightening, there is so much individual limitations that you may really never know if some limit is not gonna blow up in production.
Not to mention their voluntarily incomprehensible pricing. You may brankrupt your company just doing a few API calls and anyway, I generally found the overall quality of their products so poor that their premium just kills it.
Every time I know I’ll need to use one of their service, I prepare for the pain.
I generally support most things AWS does, but agree with you here. Though documentation you get a handle on fairly quick... Nearly all SDKs follow the same pattern. Still room for improvement. The lack of easy helpers (like for signing setup and validation) got us too.
Kinda to the other replies point though: does anyone do it better?
Kinda to the other replies point though: does anyone do it better?
>does anyone do it better?
Not currently, sadly, imo.
Not currently, sadly, imo.
What other providers do you use?
> The UI is a nightmare.
While I definitely wish it was better, I’m tired of posts implying it’s completely unusable like this.
First of all, it’s night and day better than GCP and Azure to me, both are far worse UI wise. I spent 30+ min once trying to find the magic incantation to just update the billing CC in GCP and only after reading dozens of google SERPs wading through lots of negative comments online of people ranting about the same issue did I figure out what was wrong.
But that’s not the point, having better UI than your two leading competitors doesn’t automatically make yours not awful too. So to that I have to ask, what makes it so bad to you? From the very beginning I was always able to find everything I needed without much difficulty. Sure, there were rough places, especially around ECS when it first came out, but overall it felt intuitive for the most part.
Furthermore, AWS APIs (which is imho how you should mostly be interacting with AWS) are generally feature complete and not overtly painful to use in my experience. Sure, I’ve had to add a busy loop in my code before to poll for completion, but there’s far worse sins with other APIs I’ve had to use. There’s also head scratching “why must I do this in two or more separate calls” moments too, but again, if you read the docs it’s all easily doable.
Endpoint, can you actually provide some definitive examples to justify that “UI is a nightmare”, or is it just FUD to relieve your own stress on something likely unrelated?
While I definitely wish it was better, I’m tired of posts implying it’s completely unusable like this.
First of all, it’s night and day better than GCP and Azure to me, both are far worse UI wise. I spent 30+ min once trying to find the magic incantation to just update the billing CC in GCP and only after reading dozens of google SERPs wading through lots of negative comments online of people ranting about the same issue did I figure out what was wrong.
But that’s not the point, having better UI than your two leading competitors doesn’t automatically make yours not awful too. So to that I have to ask, what makes it so bad to you? From the very beginning I was always able to find everything I needed without much difficulty. Sure, there were rough places, especially around ECS when it first came out, but overall it felt intuitive for the most part.
Furthermore, AWS APIs (which is imho how you should mostly be interacting with AWS) are generally feature complete and not overtly painful to use in my experience. Sure, I’ve had to add a busy loop in my code before to poll for completion, but there’s far worse sins with other APIs I’ve had to use. There’s also head scratching “why must I do this in two or more separate calls” moments too, but again, if you read the docs it’s all easily doable.
Endpoint, can you actually provide some definitive examples to justify that “UI is a nightmare”, or is it just FUD to relieve your own stress on something likely unrelated?
> I’m tired of posts implying it’s completely unusable like this.
I didn't say it was unusable. I just said it was atrocious and really bad. If it was literally unusable, I wouldn't even consider it an option to try and navigate it or even consider it part of the offering, I'd just use the CLI instead.
> or is it just FUD to relieve your own stress on something likely unrelated?
No. My pain point of AWS is the UI. When I do use the CLI, I find it quite reliable. However, I occasionally like to use the UI to confirm a deployment occurred, or inspect when ECS containers are unhealthy, etc. I primarily use it in a "read-only" way.
I really dislike that your comment suggests that I don't understand what my own problems are. Try not to de-legitimize the experiences of others.
I didn't say it was unusable. I just said it was atrocious and really bad. If it was literally unusable, I wouldn't even consider it an option to try and navigate it or even consider it part of the offering, I'd just use the CLI instead.
> or is it just FUD to relieve your own stress on something likely unrelated?
No. My pain point of AWS is the UI. When I do use the CLI, I find it quite reliable. However, I occasionally like to use the UI to confirm a deployment occurred, or inspect when ECS containers are unhealthy, etc. I primarily use it in a "read-only" way.
I really dislike that your comment suggests that I don't understand what my own problems are. Try not to de-legitimize the experiences of others.
ohh, i could not agree more!
Is this a good book for dipping your toes into AWS?
I'm mostly a front end developer and have used Google's cloud services and others for my personal apps and experiments.
... but always found AWSs multitude of services and administration interfaces daunting.
I'm mostly a front end developer and have used Google's cloud services and others for my personal apps and experiments.
... but always found AWSs multitude of services and administration interfaces daunting.
Yes, definitely. The first part is very high level. It’s our opinionated perspective of the most important AWS products and how we think about them (which is not exactly how Amazon describes them). The second part is more technical and focused on developers who want to set up an AWS environment and understand what’s going on.
And if what you find doesn't match what you're expecting, just reply to the email and you'll get a full refund – no questions asked.
And if what you find doesn't match what you're expecting, just reply to the email and you'll get a full refund – no questions asked.
Thanks!
When a company builds a certification system around its thing, you can be sure that simplicity and ease-of-use has stopped being a problem for them.
If you want “ease of use” there are plenty of “easy ways” to get things done in AWS like just accepting defaults when creating a VPC, ElasticBeanstalk for deployments , and CodeStar for getting started templates.
There is not a single bit of technology that doesn’t seem overwhelming when you first start looking into it - and that’s from 30+ years of programming either personally or professionally. I know most of the core fiddly bits of AWS like the back of my hand but Azure and GCP are completely incomprehensible to me. But, I also haven’t taken time to learn them.
There is not a single bit of technology that doesn’t seem overwhelming when you first start looking into it - and that’s from 30+ years of programming either personally or professionally. I know most of the core fiddly bits of AWS like the back of my hand but Azure and GCP are completely incomprehensible to me. But, I also haven’t taken time to learn them.
>I know most of the core fiddly bits of AWS like the back of my hand but Azure and GCP are completely incomprehensible to me.
You don't think there's anything wrong with that, given how they're tackling almost an identical problem?
You don't think there's anything wrong with that, given how they're tackling almost an identical problem?
That would be just like saying that if I were an iOS developer and was good at Swift I should just be able to automatically know how to write Android apps.
Best of luck with launch. I had pre-ordered the book and am exited to dive in.
For what it’s worth, following you on twitter gave me a great window into your skillset and experience which prompted me to by the book.
For what it’s worth, following you on twitter gave me a great window into your skillset and experience which prompted me to by the book.
Congratulations! I've been working with AWS for over 5 years now and I still feel like I have to reach for a tutorial every time I go to use IAM
What was the marketing? Was it because of the contacts you had through working at aws spreading the word?
I can imagine this selling a lot more as so many businesses are using aws and spending a lot of money on that too.
Maybe the next step is a top selling udemy or Udacity etc. course.
I can imagine this selling a lot more as so many businesses are using aws and spending a lot of money on that too.
Maybe the next step is a top selling udemy or Udacity etc. course.
Almost all on Twitter. (But got some sales from this too now :))
I've been active on Twitter for the last 10 months, since I left my job. I've been documenting what I'm doing and my professional story as it happens. Gradually built a following of 13K, and they helped me spread the word when I launched this.
I've been active on Twitter for the last 10 months, since I left my job. I've been documenting what I'm doing and my professional story as it happens. Gradually built a following of 13K, and they helped me spread the word when I launched this.
The Good Parts
...
CloudFormation
Really? I mean, I get you want to recommend an infrastructure as code tool, but I really wouldn't consider it in the category of "[features] which you almost never need to consider alternatives."
...
CloudFormation
Really? I mean, I get you want to recommend an infrastructure as code tool, but I really wouldn't consider it in the category of "[features] which you almost never need to consider alternatives."
I've used Ansible on AWS for 2 years to build out over 50,000 servers, to set up the vpc architecture, control IAM roles, nearly everything.
Ansible kept breaking. A minor patch on v2.5.x destroyed my VPC links, 2.6 broke my IAM, at one step I had to have an intern set log group expiration on 200 log group across several accounts because ansible doesn't support log group going from "undefined" expiration to any value.
I started with ansible because the the server modules are good... But I'm leaving them (for aws components) because there's just no quality control on the releases. I was tired of multiple sprints a year getting side tracked by a tool meant to help.
Now our DevOps team uses SAM templates, a superset/tool on CloudFormation. We've had 0 outages or sidetracks over the last year due to a SAM/CF bug, and we now have access to be features that came out in the last 18 months that ansible still doesn't support.
I don't suggest CloudFormation as a solution if you co-exist in multiple clouds, but I also reject the common belief among managers that teraform and ansible are the "god tools". Or team was almost forced onto teraform because a manager was convinced by a Hashicorp marketing guy that you could take a complex about setup from one cloud to another in 4-6 weeks using their product because the modules are cross-cloud. Right...
Anyway, Ansible is still our server control platform (though we are moving more serverless), but cloud formation is what we use to build the entire accounts supporting ecosystem
Ansible kept breaking. A minor patch on v2.5.x destroyed my VPC links, 2.6 broke my IAM, at one step I had to have an intern set log group expiration on 200 log group across several accounts because ansible doesn't support log group going from "undefined" expiration to any value.
I started with ansible because the the server modules are good... But I'm leaving them (for aws components) because there's just no quality control on the releases. I was tired of multiple sprints a year getting side tracked by a tool meant to help.
Now our DevOps team uses SAM templates, a superset/tool on CloudFormation. We've had 0 outages or sidetracks over the last year due to a SAM/CF bug, and we now have access to be features that came out in the last 18 months that ansible still doesn't support.
I don't suggest CloudFormation as a solution if you co-exist in multiple clouds, but I also reject the common belief among managers that teraform and ansible are the "god tools". Or team was almost forced onto teraform because a manager was convinced by a Hashicorp marketing guy that you could take a complex about setup from one cloud to another in 4-6 weeks using their product because the modules are cross-cloud. Right...
Anyway, Ansible is still our server control platform (though we are moving more serverless), but cloud formation is what we use to build the entire accounts supporting ecosystem
Ansible is awful to use with AWS. So many modules are "community" written with nowhere near the feature parity of Terraform [0] and are full of bugs [1].
[0] - https://docs.ansible.com/ansible/2.3/s3_bucket_module.html
[1] - https://github.com/ansible/ansible/issues/47945
[0] - https://docs.ansible.com/ansible/2.3/s3_bucket_module.html
[1] - https://github.com/ansible/ansible/issues/47945
I assume you just read the ToC, not the chapter? In the book we recommend using an IoC tool, and that CloudFormation is good enough. We don't think that CloudFormation vs Terraform is a very consequential decision, so choose whichever tool you prefer. But we also share our perspective about what should go in IoC and what shouldn't, which is a much more important issue IMO.
IoC or IaC? I assume you mean infrastructure as code, or is it something else?
https://en.m.wikipedia.org/wiki/Infrastructure_as_code
https://en.m.wikipedia.org/wiki/Infrastructure_as_code
Oops. Typo. I meant IaC.
The book doesn't say CloudFormation is in that category.
Great job! How long did you spend on writing the book?
Started in October, spending about 1 day a week. Then we did a big push over the last 10 days.
Thanks for replying!
Another question is, what motivated you to start this effort in the first place? And why do you think it's useful. I haven't read the book, so not really sure
Another question is, what motivated you to start this effort in the first place? And why do you think it's useful. I haven't read the book, so not really sure
Mostly an experiment. I wanted to get a concrete idea about whether it's possible to make a living producing digital products like these (and whether I could do it :)). I don't have that answer yet (too early), but now I have some evidence that something like this can sell.
Bought this on my phone and downloaded the PDF but didn't create an account - assumed it'd remember my email. How can I download it again on my laptop?
The email receipt should have a download link. If you didn't get the receipt, email me and I'll resend it to you.
Fantastic!
Great resource. As someone who's used AWS before but always felt lost, this is great. The writing feels like I'm talking to a colleague sharing their experience, which makes it super approachable.
There was a repeating element of "x is a bit like y" (e.g. DynamoDB is like a super-durable data structure", which I found to be a really useful / easy way to think about each service.
Great resource. As someone who's used AWS before but always felt lost, this is great. The writing feels like I'm talking to a colleague sharing their experience, which makes it super approachable.
There was a repeating element of "x is a bit like y" (e.g. DynamoDB is like a super-durable data structure", which I found to be a really useful / easy way to think about each service.
Thank you! I'm very glad to hear that, because that was the intention.
Good parts series, one of the best, congratulations man!
Good
I'm an ex-AWS employee, now working for myself. Together with a friend of mine (who also recently left Amazon) we tried an experiment and put almost everything we know about AWS in one short digital book. We launched the book yesterday (xmas day) and it sold over $13K already: https://twitter.com/dvassallo/status/1210352939539161088
This is the first time I got paid for something I wrote, so I'm still very new to this. But I'm happy to share what I learned so far, so please feel free to ask me anything.
And here's a discount link for the book if you'd like to check it out: https://gum.co/aws-good-parts/hn