By Chris Chapman, Partner Solutions Architect at AWS
By Edward Abrams, Sr. Director – Software Development at GoDaddy
Serverless Framework is an open source project and popular choice for many Amazon Web Services (AWS) customers who wish to quickly construct and deploy serverless applications using services like AWS Lambda and Amazon API Gateway.
For developers and operations professionals, Serverless Framework builds, packages, and deploys code with one simple command:
As companies scale their AWS environment across developers and teams, they move to predefined standardized infrastructure templates to speed up the process of code deployment and decrease configuration time. AWS Service Catalog is an ideal service enabling developers to quickly and securely provision predefined AWS CloudFormation templates.
In this post, we will introduce an open source solution that GoDaddy and AWS jointly developed leveraging Serverless Framework to expedite and simplify the code deployment process for their development teams.
Infrastructure as Code with Service Catalog
AWS Service Catalog is a gateway for AWS CloudFormation that allows users to provision only predefined immutable templates.
Initially, this may seem contradictory to the broader serverless computing goals of agility and speed. However, many companies find that agility and speed actually increase when they consolidate the multitude of options for deploying AWS resources into standardized and secured templates.
For example, the number and complexity of options in serverless can be challenging for many development. Development teams can lose productivity by reinventing the wheel, when leveraging a standardized architecture for deployment would be more efficient.
Therefore, leveraging predefined immutable templates through AWS Service Catalog can increase the speed and agility of development teams across the organization as a whole.
Dynamic vs. Static
In large organizations, there are many perceived trade-offs, such as dynamic versus static components of infrastructure deployments and the efficiency of individual teams versus an entire engineering department.
To the first point, it is not a question so much of dynamic versus static, but rather identifying where the variance is across deployments and creating parameters that capture the options while leveraging a standardized but reusable infrastructure template.
We argue that, when looking across a company’s entire engineering organization, the deployments are far less unique than each individual team can see. It is thus possible to architect uniform infrastructure templates with sufficient parameterization to capture the variance in cross-team use cases and deployment.
How can we best combine the speed and agility of dynamically generated infrastructure with the efficiency and control of predefined reusable templates? We are excited to show how combining Serverless Framework with AWS Service Catalog can make development faster and easier on AWS Lambda and Amazon API Gateway.
GoDaddy and AWS have teamed up for a joint development effort that combines the ease of Serverless Framework with the provisioning speed and security of AWS Service Catalog.
Continuing in the spirit of Serverless Framework’s open source plugin ecosystem, GoDaddy and AWS created the serverless-aws-servicecatalog plugin to enable Serverless Framework to deploy through AWS Service Catalog. You can find the plugin on GitHub.
Serverless Framework handles both AWS Serverless infrastructure creation through AWS CloudFormation and the packaging/deployment of the project code. Most project iterations drive changes in the Lambda source code, while the underlying infrastructure deployment rarely changes, making the latter ideal for standardization.
With this plugin, AWS customers currently using Serverless Framework can easily move to a more standardized, scalable, and predefined infrastructure-as-code provisioning process for their AWS serverless deployments.
With a few easy steps, you can have Serverless Framework deploying through AWS Service Catalog in your environment.
While we have minimized the changes to a normal serverless deployment, the plugin requires an additional predefined AWS Service Catalog product creation before Serverless Framework can deploy. Once the product is in place, the process for developers to deploy changes very little.
Figure 1 – Process flow.
The complete install with deployment can be summarized into four manual user steps followed by two automated actions.
- AWS Admin user initiates AWS Service Catalog setup with the predefined serverless product.
- DevOps user installs the plugin for the serverless project.
- DevOps user configures the AWS provider section in the serverless.yml with additional AWS Service Catalog product parameters (see Figure 2).
- DevOps user executes the command: serverless deploy.
- Serverless Framework plugin automatically packages the code and provisions the AWS Service Catalog product.
- The AWS Service Catalog product automatically creates the AWS resources.
Figure 2 – Sample Serverless.yml.
How Serverless Framework Works
Serverless Framework is open source software that builds, compiles, and packages code for serverless deployment, and then deploys the package to the cloud.
With Python on AWS, for example, Serverless Framework creates the self-contained Python environment, including all dependencies. Then, it packages that environment into the standardized zip file for AWS Lambda and creates all of the associated AWS resources required for deployment in an AWS CloudFormation template.
Finally, it copies the code to AWS and initiates the CloudFormation stack creation or update, which provisions AWS services for the serverless application.
Serverless Framework does this by providing an event queue into which a combination of standard provided packages and templates can be combined with additional open source plugins to expand the functionality.
This event queue allows plugin developers to create hooks and alter the behaviors and outputs of each stage of the process (e.g. build, compile, package, provision, and deploy).
By adding plugins, users can change/replace/augment the processing at a particular stage by introducing specialized behavior into the framework. Once a plugin is added to the configuration, Serverless Framework activates the plugin and automatically builds and packages your project’s code into a ready to deploy format. A plugin, for example, is the mechanism by which you can add any coding frameworks, such as Python WSGI.
Focusing specifically on how the Serverless Framework deploys code to AWS, the AWS Provider generates a CloudFormation template and calls
create stack or
update stack through the AWS Software Development Kit (SDK). The default AWS Provider package for Serverless Framework contains the logic and boilerplate configurations to generate the most common Lambda deployments and associated Amazon API Gateways.
Serverless Framework interacts with AWS using the AWS SDK and maintains state in the .serverless folder within your particular project’s directory. After the initial deployment creates the AWS resources, subsequent code changes can easily be deployed by using the –function option.
In addition, CloudFormation’s infrastructure-as-code approach simplifies management since the complete AWS deployment is documented and visible within the console. Users could take the same template and deploy it multiple times across AWS regions and accounts. In addition, you can jointly manage coding and infrastructure changes in a single project within the version control system of choice.
AWS Service Catalog Plugin for Serverless Framework
As we have mentioned, AWS Service Catalog uses predefined parameterized templates. This means an AWS Service Catalog product for provisioning Serverless Framework packages must be in place before a user may deploy. This template does not need to be updated often and should be part of a separate infrastructure as code CI/CD pipeline.
Through AWS Service Catalog, many users can leverage the same template on-demand. Once the product is created in AWS Service Catalog, developers just need the product ID to insert into the Serverless Framework config file.
serverless deploy, the AWS Service Catalog plugin for Serverless Framework intercepts the CloudFormation creation part of the deployment event queue. This means the standard CloudFormation template from the default AWS Provider is not created.
Instead, the pipeline packages and uploads the code as normal, but the plugin provisions the infrastructure as defined by an AWS Service Catalog product.
GoDaddy Use Case
GoDaddy has long pushed the boundaries of simplifying the complexity of cloud services for their customers, the everyday entrepreneurs. GoDaddy has identified provisioning at scale to be the next hurdle for continuing their rapid pace of innovation.
GoDaddy has teams of experts who are developing industry-leading architectures for containers, Kubernetes, serverless, and machine learning. Their challenge is to more pervasively leverage the solutions and best practices created by individual teams and provide those templates to the entire engineering organization.
The AWS Service Catalog solution we have discussed in this post allows GoDaddy to quickly and securely deploy standardized serverless templates to any region in the world, driving speed and innovation across the developer community. GoDaddy is currently in the process of providing more than 60 products to their entire engineering organization through AWS Service Catalog, so developers can combine AWS services in new and creative ways.
As serverless becomes an increasingly popular strategy to get low-complexity, horizontally scaled infrastructure at a great price, GoDaddy can leverage serverless as a way to simplify operations and make infrastructure management more efficient. Instead of each team spending weeks figuring out the infrastructure deployment architecture, they can simply write code and deploy with Serverless Framework.
For example, GoDaddy recently used the
serverless-aws-servicecatalog plugin to create an API for an online survey application. Their developers were able to use the plugin to easily deploy code and then immediately focus on building the product.
Previously, each development team had to create their own AWS CloudFormation templates for Amazon API Gateway, AWS Identity and Access Management (IAM), AWS Lambda, and Custom DNS before any code could be deployed.
GoDaddy development teams now spend their time focusing on creating business value. Infrastructure-as-code innovations can be captured and immediately leveraged across the whole development organization. Development teams can then use these templates to create new combinations of services and technology that will become the next standardized infrastructure template.
Many companies are trying to increase the speed and efficiency of their software development organizations. These organizations are finding that standardized infrastructure-as-code is a good way to relieve their development teams from the heavy lifting of infrastructure. Removing this heavy lifting from developers gives them more time to focus on innovation and delivering business value.
The Serverless Framework provides a simple and effective abstraction of the AWS Lambda package and deploy process. GoDaddy has found that by providing developers with self-service, standardized infrastructure templates, they are able to get new projects running faster with less overhead.
serverless-aws-servicecatalog plugin combines Serverless Framework with predefined AWS CloudFormation templates through AWS Service Catalog. This combination means developers can deploy code faster while companies maintain the governance and security they require.
Serverless, Inc. – APN Partner Spotlight
Serverless, Inc. is an APN Advanced Technology Partner. Serverless Framework is an open source project and popular choice for many AWS customers who wish to quickly construct and deploy serverless applications using services like AWS Lambda and Amazon API Gateway.
*Already worked with Serverless, Inc.? Rate this Partner
*To review an APN Partner, you must be an AWS customer that has worked with them directly on a project.
from AWS Partner Network (APN) Blog