Having previously looked at some surprises I discovered as I learned about AWS, I’m going to take a look at some of the basic architectural design principles on AWS. As in the last series, there will be blog posts for each principle that go into some basic details. Here are the ten principles:
- Enable scalability: What happens if demand increases? Or doesn’t increase? What if demand goes up and down over time?
- Automate your environment: Computers are good at doing things the same every time, humans are not
- Use disposable resources: “Everything fails, all the time” Werner Vogels. Replace broken things with brand new things, rather than spend a lot of time fixing them.
- Loosely couple your components: When one element of your application changes or has an issue, the rest of the application should still work.
- Design services, not servers: An EC2 instance should not be a single point of failure. Use several instances and a load balancer or a queue.
- Choose the right database solutions: I don’t mean Microsoft SQL Server vs Oracle. I mean use the right database for the data you need to store, some will be better in non-relational databases.
- Understand your single points of failure: There are always SPOFs, make sure you know where they are and try to eliminate as many as possible.
- Optimize for cost: Your AWS bill will arrive every month & you will pay for what you use. Make sure you are getting value for every dollar spent on that AWS bill.
- Use caching: Your data is not all of the same value or location, nor are resources of the same cost. Caching uses small amounts of resource that is fast or close.
- Secure your infrastructure at every layer: “Dance like nobody’s watching, encrypt like everyone is” Werner Vogels. By now, we should all understand that defense in depth is the only viable strategy.
© 2020 – 2021, Alastair. All rights reserved.
RSS - Posts