There's a lot of misunderstanding about what it means to build serverless applications and this is video aims to help clear up some of those misconceptions and if you have no conceptions at all and are brand new to serverless development, great, then let's get started.

Let's start by taking a quick history lesson as to how web applications have been built. Back in the late nineties web applications were only beginning to make their entrance onto the software development world. Frontend and backend as two separate concepts didn't really feature the backend code that spoke to a data store of some kind was intermingled with that front end code.

But more importantly, if you wanted to get an application on the web, you often had to run your own data center or co-locate your own physical hardware into a local data center that only provided you network rack space and power. It was still your machine and you needed to manage that. If you went to the upgrades, you had to buy them and book time to install the new hardware. And that also means that if you had a sudden spike of demand and you didn't have enough hardware, your application just fell over from the load.

A lot of companies would have had to then make sure they had way more hardware available in that data center than they really needed for the base activity on their application just to make sure that they were able to meet them on for those massive spikes, which ends up being really wasteful as the majority of the time the machines would be doing very little move forward a few years and the advent of virtual machines arrived, which gave us admins the ability to squeeze more fake machines onto the same bare metal to try and make better use of excess capacity.

However, the real evolution came in around 2008 when Amazon released their EC2 service to the world. EC2 gave everyone the ability to add new server capacity to their applications whenever they needed it. This gets us closer to being serverless, but there was still some work to do.

You had to install and maintain your own operating system and application software. If you were to load balanced operation for example, you would need to spin up the required EC2 instances yourself, set up the software such as a HA proxy to distribute the traffic.

The only change was your hardware was elastic. No need to go through the purchase agreements for new hardware and then have to spend a lot of time configuring and installing them and to some degree you're no longer stuck with excess capacity. You could spin up hardware up and down as needed.

But let's take another step forward alongside the EC2 launch with two other services S3 they're block storage solution for storing files and SQS - their managed message queue service. This set the premise for the expansion of AWS into providing more and more services. Sure you could have set up your own rabbit MQ EC2 instance to provide what SQS gave you, but then that was your problem to manage.

Fast forward to today and AWS has an entire suite of services you can use that traditionally you would have needed to configure, deploy, and maintain and manage the capacity for yourself or you can just use the already managed services provided under SLA and with specific capacity parameters that you know about upfront.

The last cog there was needed to truly go serverless, in other words, without the need to spin up any infrastructure that requires some form of handholding to keep running was compute and that's where AWS Lambda enters the scene.

AWS Lambda gives us a way to integrate all these separate managed services like S3, SQS, SNS, DynamoDB, API Gateway and more with business logic. We can now build applications fully serverless-ly and this is where we come to the properties of what makes an application serverless and following the serverless way.

A serverless application is usually comprised of many individuals, serverless microservices. Each service does one particular job within one domain very well and only that one example is an authentication service. All it does is accept credentials, verify their authenticity and return some kind of token like a JWT to be used by other services to validate requests. Each serverless service is configured as much as possible to make use of existing managed services of the cloud vendor chosen and even sometimes external to that vendor as well.

This reduces the amount of code usually needed for that service, which is one of the central tenants of the serverless way. Reduce code as much as possible. Serverless services only cost you when they're actually executing and this is important.

To be a truly serverless service, there needs to be no idle running cost. This means services such as EC2 which charge by the minute even if there is zero traffic are not considered serverless.

Scaling up happens automatically. The services you use have features that allow a certain amount of capacity to be instantly available to you. Ideally you play no part in managing the capacity, but at the very least it requires very little effort. Scaling down and even to zero is also automatic and this is a concept that is often forgotten. Scaling up even in a non serverless environment is usually easy, but knowing when to scale down is hard.

But because serverless services such as S3, SQS, DynamoDB, and so on, bill only on usage, there's actually no need to even consider scaling down. It just happens automatically as a nature of the way these services are architected and if they are not being used, they are not being charged.

Managing infrastructure needs to be portable and decoupled and this is what the serverless framework gives you. The ability to define a specific configuration of a service including all related services you need in a way that makes it possible for another developer to clone your service from your get repo and deploy it into their AWS account if they need to and make changes.

This is how you maintain software and by decoupled we mean that it does not require another service to be active. Communication between services should be asynchronous and deploying one service does not require that another be deployed prior.

The short version to summarize it all up, is that serverless application development is all about taking existing managed services and using them along with glue code in AWS Lambda to build a solution that scales has redundancy and disaster recovery built in, and often at the cost of $0 dollars.