Best Practices in AWS Management(adair.tech)
adair.tech
Best Practices in AWS Management
https://www.adair.tech/blog/2018/4/30/best-practices-in-aws-management-part-1
7 comments
Not exactly sure what I just read. A list of statements without any real arguments or insight in why they are the best practices.
I think it is very hard to have such a list without over-generalizing or writing a book.
The piece could use some rework. The idea is nice, a series on best practices, but the execution needs to be looked at.
P.s. AWS has a whitepaper on the subject which is an OK read for starters in the area. I would redirect any reader of this post to the collection of whitepapers by Amazon. They also have the same for security. They cover the basics.
[0] https://aws.amazon.com/whitepapers/architecting-for-the-aws-...
I think it is very hard to have such a list without over-generalizing or writing a book.
The piece could use some rework. The idea is nice, a series on best practices, but the execution needs to be looked at.
P.s. AWS has a whitepaper on the subject which is an OK read for starters in the area. I would redirect any reader of this post to the collection of whitepapers by Amazon. They also have the same for security. They cover the basics.
[0] https://aws.amazon.com/whitepapers/architecting-for-the-aws-...
Yeah that was really high level overview of very specific things. I'm not sure if people without any prior knowledge of aws are getting anything out of it. For those who aren't familiar with aws i would recommend using most of the fully-managed services that aws offers. Then if you think you can save a buck by running your own databases you should go start considering them. Granted some aws services are not that great like EFS - it's just useless. But still dont go crazy with optimizing your cpu cycles. Sometimes it's just better to pay some extra for not having to spend hours debugging things that are not in the core of your business.
I find that all “best practices” are a lazy way to avoid justifying a position. Often the advice is almost always incorrect or situational, but the claim maker hasn’t done the work to understand why.
I don't agree with the paragraph on databases, unless there is an implicit assumption that you're migrating an existing database.
- dismissing DynamoDB unless you're doing "just key/value pairs" is IMO too reductive. You can go a long way with DynamoDB, and for smaller tables it has the most bang for your bucks (plus it's dead easy to set up and configure)
- building and maintaining your own DB cluster should not be your first move, even if you think you need "a high level of engineering". Start with a managed RDS instance and only if you reach its limits should you consider rolling your own (unless, of course, you already have an exquisitely tuned DB that you need to migrate to AWS. But honestly, as long as you're migrating, shouldn't you take the opportunity to move to something with less maintenance?)
- managed RDS is fine, but, once again, DynamoDB will frequently be cheaper.
- dismissing DynamoDB unless you're doing "just key/value pairs" is IMO too reductive. You can go a long way with DynamoDB, and for smaller tables it has the most bang for your bucks (plus it's dead easy to set up and configure)
- building and maintaining your own DB cluster should not be your first move, even if you think you need "a high level of engineering". Start with a managed RDS instance and only if you reach its limits should you consider rolling your own (unless, of course, you already have an exquisitely tuned DB that you need to migrate to AWS. But honestly, as long as you're migrating, shouldn't you take the opportunity to move to something with less maintenance?)
- managed RDS is fine, but, once again, DynamoDB will frequently be cheaper.
Don't forget "raid 0 on your hand rolled ec2 db instance". A lot of the other stuff is forgivable, that right there is downright dangerous.
You see this stuff all the time:
* Person starts $consultingCo
* Person creates website for $consultingCo
* Person adds "blog" section to website
* Writes a few vague, high-level pieces like this
* Spams them everywhere
* Almost all new business still comes from Chamber of Commerce mixer
* Person loses interest and stops updating "blog"
It reads like it's trying to get the attention of a CIO at some Midwestern Widget factory.
I'm always on board with idea of spreading knowledge and ideas around. High-level, introductory pieces are also good.
BUT... You've got to know your audience. The typical HN reader is not going to find an article like this novel or useful, and might even find it off-putting. The type of people you want to read this article are probably not avid HN readers.
All that aside, you've also got some pretty dangerous generalizations like:
> "Is my data just key/value pairs? If yes, use DynamoDB. If no, keep going."
Yikes. I really hope deeper considerations are being paid to choosing a database technology beyond "Welp, it's just k:v, let's use NoSQL!"
If you have some novel, technical insight into utilizing AWS, please share it here. This article does not qualify.