Serverless apps : Why IaC should be the direction

Serverless applications is often inclusive of many services such as EventBridge, Simple Notification Service (SNS) and Simple Queue Service (SQS) which play a vital role in decoupling and enhancing the performance and robustness of the Serverless application itself. And also services such as AWS API Gateway, AWS AppSync for API provisioning which are backed by Amazon Lambda functions, Fargate, AWS Step Functions. These services have configurations and IAM permissions of their own.

Most of us who are familiar with server-based architectures (hosted on virtual machines on cloud) are also familiar with the "lift and shift" based migration or setting up with different development and staging environments. The application level configurations are more centered to the virtual machine itself.

But with serverless applications, the whole "lift and shift" based migration or sync between different development and staging environments is not maintained in one place rather the configuration is spread across different services and each of it would need an IAM permission of it's own (following the security recommendations of least privileges).

Serverless applications are best managed with Infrastructure as Code (IaC) which maintains a configuration file either as template file in YAML or in the programming language which specifies configuration as code (literally) with variables and method initialization.

   // Function that returns 201 with "Hello world!"
    const helloWorldFunction = new Function(this, 'helloWorldFunction', {
      code: new AssetCode('src'),
      handler: 'helloworld.handler',
      runtime: Runtime.NODEJS_12_X
    });

    // Rest API backed by the helloWorldFunction
    const helloWorldLambdaRestApi = new LambdaRestApi(this, 'helloWorldLambdaRestApi', {
      restApiName: 'Hello World API',
      handler: helloWorldFunction,
      proxy: false,
    });

The sample code is using AWS Cloud Development Kit (CDK) with TypeScript sample

• Creation of Lambda function with runtime, handler and code properties defined to mention the Lambda function is powered with NodeJS 12.x and the handler for the Lambda fn.
• REST API via AWS API Gateway set with the properties restApiName for the name of the REST API, handler to mention the Lambda function name which the API Gateway is used to invoke and proxy based invocation type for the Lambda function.

The feasibility of defining and building your Serverless architecture with programming language of your choice on AWS CDK makes it a good choice of IaC for developers. However, if you are into defining the infrastructure with YAML based template file or a CLI which can walk you though is also available.

Options of IaC for AWS Serverless

• AWS CloudFormation
• AWS Serverless Application Model (SAM) CLI
• AWS Cloud Development Kit (CDK)
• AWS Amplify CLI
• Terraform
• Serverless Framework

Reasons to opt for IaC

• Single source of truth helps in maintaining your complete infrastructure in one centralized Git or a template file shared across different developers so that everyone has access to same configuration which is ready to be deployed to their environment.
• Managing and provisioning resources on the cloud with code has become very easy for developers to get started with the feasibility of code of their choice.
• Easy to replicate to multiple instances as the common template which defines the infrastructure could be easily deployed / re-deployed / rollbacked.
• Best known method for CI/CD pipelines as the CI/CD pipelines are automated and runs based on actions or triggers in the cloud.
• Test in multiple instances / environments has become a standard of testing process and with CI/CD pipelines which is powered with IaC makes is easier for load testing on a specific replica of production environment.
• Improvised development practice for developers to collaborate between different developers without having to disturb other development or staging environments.
• Consistent configuration across environments as different environments are used, configurations should also have to be in sync with all environments.

To know more about how to build Serverless apps using IaC, the session explains about IaC with SAM CLI.

Comments

[Johannes Koch]

Hey - Cool post, thanks! What would be your IaC of choice and why? ;)

[Jones Zachariah Noel]

Thanks Johannes.
I prefer SAM as I'm more comfortable with writing YAMLs and it's simplistic CloudFormation templates. I'm also experimenting with CDK but first preference is SAM.

[Johannes Koch]

Is your background a developer or an operations background?

Did you try the cdk/Sam integration yet?
I didn’t and I am eager to try it…

[Jones Zachariah Noel]

I'm from a developer background but as the earlier days didn't have CDK or SAM so was used to CloudFormation based templates.

Well, like I said I'm still getting my hands dirty with CDK so haven't tried the SAM-CDK integration.