In the 90s the web as we know it began to explode into popularity. However, all sites had to initially be hosted by individuals or organizations in their own data centers if they wanted to be online and sites going down for hours and sometimes days at a time due to outages or just upgrades were not unheard of.

Very quickly, however, companies that specialize in allowing you to install your hardware into their data center arrived on the scene so at least you didn't have to worry about provisioning power, air conditioning, permanent connections to the internet and a secure location.

However, you still had to handle hardware upgrades yourself. These co-located data centers didn't just expand your hardware capabilities automatically for you. You still had to source upgraded parts, get quotes, workout special deals with the suppliers, sign contracts, get the machines shipped to the location. All the while, your users may already be suffering from bad performance on your older hardware.

This meant that organizations that really wanted to make sure that they were available for the users would have to over-provision extensively. In other words, they would need to far more capacity serving customers. And then really needed in order to not have to upgrade so often and to handle any potential traffic spikes.

All of this hassle had some other significant downsides. Marketing and sales teams trying to sell a digital product were hamstrung by how much capacity was available in the data center. You can't push hard to sign up new customers and make sales targets when your server is about to run out of capacity. There's also meant that developers in these organizations spent a lot of time trying to optimize code. It might sound fun as an engineer working on solving performance issues, but it's not so much fun for business owners who get value out of selling product features to users.

Users don't care about how well optimized your product is. They care about what it can do for them. Developers, content enhance products features if they're always trying to optimize speed. Thankfully some radical changes were forthcoming.

The ability to create virtual machines in the early two thousands was a large step into the future, allowing organizations to more cleanly separate workloads on the same bare metal and make better use of the machines resources.

But the real game changer happened in 2006 when AWS made three services generally available S3, SQS and EC2. EC2 probably had the biggest impact as it finally allowed organizations to easily create and destroy virtual machines and only pay for what you used. This meant no more worrying about purchase agreements for hardware when upgrade time came. You could just create a new virtual machine to add to your fleet or just swap existing virtual machines with machines with the highest specifications as needed.

As time marched on, so did AWS, releasing service after service SNS, a pub sub system, DynamoDB, API Gateway and Lambda. All services we will be using throughout this course were added and all of these services were deliberately created in response to customer needs.

Instead of having to configure, deploy and develop similar services yourself, you just use the already available services provided by AWS and focus on what is important to your business instead because resources and services on now so easily available, developers no longer need to focus quite so much on performance of their application. They can spend more of their time on making sure that their organizations and user's needs are met. This is often far more valuable today, and this is what makes serverless development so powerful.