As I started working with and writing about AWS, there were a few things that surprised me about how different AWS is from on-premises vSphere. As I have been teaching AWS official courses, I have continued to notice things that surprise me about AWS. I’m planning to write a separate post about each of these strange things. As I think of more strange things, this list will get longer, and I will write separate blog posts with more detail about each strange thing.
Here’s my current AWS strange things list:
- It is not all about VMs – The EC2 service is a VM service with many analogs to vSphere. However, it is not where a lot of the action is at with AWS. I usually talk about EC2 as the last resort place to run an application, for when AWS does not have a managed service that will work better.
- No VM console access – On EC2, you do not get access to a VM’s console. You will never see it post and only see the running operating system. There is no way to enter a BIOS and change settings.
- Choose a configuration from a menu – EC2 instance (VM) hardware configuration and settings are (mostly) fixed. To change the amount of CPU or RAM on an instance, you shut it down and then choose a different fixed size. You cannot merely add 4GB more RAM to an EC2 instance.
- Change is constant – AWS services do not expose any kind of versioning; they are continuously updating with new features over time. New services and new features turn up all the time, literally changing their UI while people are working with the product.
- No VMotion – An EC2 instance (VM) remains on the same physical host the whole time it is powered up. It only moves to another physical host when it is powered off and back on. There is no way to move a running instance from one host to another and no reason to do so.
- One datacentre is not enough – Many of the organizations I have worked with would have a single data center in a city; multiple data centers usually meant multiple cities, and DR is provided between cities. On AWS, a single Availability Zone is a logical data center and is considered a failure domain. Your application should be resilient across multiple Availability Zones on AWS.
- AWS is a developer enablement platform – If you thought AWS was about removing the need to run your own data center, then you have missed the point. AWS is a platform to make it easy to develop applications on the Internet; everything else comes from that objective.
- You still need infrastructure architecture on AWS – While AWS builds a massive infrastructure with complex architecture for its platform, you still need to architect how you use this platform. Unless your applications are 100% serverless, you will have some servers and need some infrastructure architecture around those servers. Bad infrastructure architecture on AWS is even worse than on-premises.
- Reduce your bill by giving AWS more responsibility – Usually, when you outsource something, the more you ask the outsourcer to take on the more they charge. When you use AWS services, you usually spend less money for a given outcome if you use AWS managed services rather than building something yourself.
- AWS has virtually infinite resources – On-premises, resources are limited but e already paid for them, on AWS resources are unlimited but you must pay each month for what you use. This new model leads to different approaches to solving problems.
- There will be more
© 2020, Alastair. All rights reserved.
I had the same kind of thinking when I moved from on-premises VMware to Azure.
It takes a while to get used to these little things we take for granted (Vmotion, console access etc..) and then you realize that you should transform your apps to NOT use VMs 🙂