During my experience as a cloud specialist, I've been part of a general movement in the industry for things becoming increasingly codified, which is probably a trend that won't surprise most people in the industry. Things that were manual tasks or sets of implementation instructions are now likely to be cloud resources declared as code and follow some sort of software development life cycle. I'm mostly eluding to the existence of Infrastructure as Code, which is a term that now encompasses a large area. What this means is a general convergence of responsibilities for software developers, engineers, and operators. Because all of our artifacts exist as code, we can now work closely together and share similar toolsets. Did you ever think you would be able to set linting rules on the infrastructure definition of a database server? Or deploy a YAML template for the entire resource stack of an application?

Because our infrastructure is easier to create and operationally manage, we can spend more of our quality time on the business code and on the function that is adding the value. What we care about is primarily the function code, then the event that makes the code run, and then any supporting resources that we might need to facilitate data movement and persistence. What we've learned so far is that we can architect entire applications as functions and events, so what if we could represent and manage that application with one tool?

The following diagram provides an example of the scale of complexities in a serverless project. The 12 components might make up a single solution or application. If you were building this manually using the console, or even the CLI, this could potentially be 12 lots of configuration, infrastructure declaration, and deployment activities. What if there were 100 or 1,000 components?

Serverless Framework is an open source application framework that allows you to create serverless applications and manage them throughout their life cycle. When a serverless application grows, it becomes incredibly hard to manage the multiple functions, buckets, security, and permissions for each deployment artifact. The framework provides a new developer experience that reduces the overhead and complexity of managing serverless projects. At the moment, the Serverless Framework is the most popular framework on GitHub and receives improvements from many contributors from the community and from Serverless Inc. as well.

For reference, I've included the following screenshot of the GitHub project, showing the popularity usage statistics:

The framework is used for developing functions in a supported language and then wiring those functions up to events. How the events are implemented is abstracted away from the developer, so all they have to do is design for reacting to the event data coming into the function. The Serverless Framework is also multi-platform, meaning that you can deploy to multiple different cloud providers from the same developer experience.

It's comforting to know if your organization has a multi-cloud strategy because now you can standardize on one tool across the enterprise. We'll be focusing on Amazon Web Service in all our examples.

The next section introduces you to an approach for managing your Serverless Framework projects.