Why I didn't choose serverless framework?

The architecture of site, I am working on, includes serverless functions, DB, API gateway, CDN and web-hosting. To address the deployment challenges when I searched best options - I was pointed to serverless framework.

This post details my decision making process, key points for not going with serverless framework, and details what my alternative selection is.

The key points to be noted for the architecture in discussion are

• The architecture is built for AWS. No multi-cloud hosting is needed
• MySQL is used as DB
• API hosts multiple methods, resources and has request validation
• Lambda functions behind API
• Cloudfront serving all content with multiple origins and behaviors

YAML + CLI Serverless

Serverless lets you deploy and define your infrastructure as code through declarative YAML. Examples from serverless are easy to pick-up, and quick examples create required stack/deployment easily.

For example, following is sample YAML configuration file

service: aws-node-mandar


frameworkVersion: ">=1.1.0 <2.0.0"


provider:
  name: aws
  runtime: nodejs12.x


functions:
  landingPage:
    handler: handler.landingPage
    events:
      - http:
          method: get
          path: landing-page

All you need to do is run following command, and it will deploy your function, create API endpoint and link function to API endpoint.

$ serverless deploy

However, when application and deployment starts getting complex - it becomes difficult to define various components and link them through YAML configuration. Challenges I faced when using YAML for my deployments were

• Significant learning curve : learning YAML deployment serverless to be able to use across wider components is significant learning curve.
• Defaults : There are lot of default parameters and it is key to understand those. e.g. default function deployment is 1024MB memory allocated. If not understood well, you will end up spending too much cost.
• Linking various components : if you have complex architecture CDN, API with multiple resources then writing YAML starts getting complex - including defining various variables, outpus and passing them across
• Limited support for some components : CloudFront distribution setting up is not supported out of box. Additional plug-ins are required to get this done. Further it makes it difficult to link to API or others. Another learning curve.
• Slow to Deploy : Given serverless uses Cloudformation as base, building cloudformation template, uploading and executing takes long time.
• Limited or not clear documentation adds to learning curve.

Overall, this process was long time taking process because of learning curve, and was not providing straight forward simple solutions to the architecture needs.

Serverless Components

Serverless Components, still in beta, is relatively new release. It tries to address lot of these issues, and abstracts lot of these issues moving to use case based deployment than earlier component based deployment. Components at core uses AWS CLI, for AWS deployments, making it relatively faster, and is JavaScript library.

Following is example of serverless component configuration

name: website


website:
  component: '@serverless/website'
  inputs:
    code:
      src: dist
      hook: npm run build
      #domain : www.example.com

 

After installing node serverless module, if you run following command then it will deploy website using S3 bucket. If domain name is provided then, it will configure CloudFront along with SSL certificate including DNS entries in Route 53 for domain.

$ serverless 

Given serverless components use AWS CLI, instead of CloudFormation, deployments are much faster than earlier version. Complex deployments are possible given each serverless component is made for each service, and accepts multiple parameters. Serverless components are written in JS and wraps AWS SDK, making is easier to build your own custom components.

Although, flexibility and control serverless components give - following are my key reasons for not going for it

• Learning curve again : components are built with understanding that work with each other. e.g. domain configuration components goes with website component, but if I want to use domain component directly then it is tough
• Limited documentation : Documentation on use of specific component is limited. One can go through source code of component to find details but it is time consuming process
• Generic Components : Given it is framework, components are built generic to suit many use cases. It is right thing to do, but adds to learning curve if one is starting.
• No partial deployments : e.g. only web component or backend API cannot be deployed straight out of box.
• It is still beta version

serverless component show lot of promise, especially with increase speed, use of AWS CLI and ability to built custom components for custom stack. However, it is still new and needs learning curve to pick it up. It is good candidate if one has time to learn and build custom components.

AWS CLI + Bash scripts - My Solution

The final choice was AWS CLI + Bash scripts as golden mean providing flexibility I needed, and speed of AWS CLI.

Sample output of my script below just as an example what is it doing

$  ./deploy.sh aws-profile 

=====
Do you want to deploy web? [n]
y
starting website deployment.... 


deploying to test environment... 


syncing s3 bucket with local changes - deploying 
bucket name - s3://my-test-s3-bucket 
...
...

Web deployment completed.... 


===== 
Do you want to deploy API? [n]
y
starting API deployment... 
deploying to test environment.. 
Building the API functions for deployment.. 
...
...

Uploding API... 
...


API deploymnt completed... 

Following are key reasons for the choice

• AWS only deployment : I did not need cloud agnostic solution as AWS was clear and only choice.
• AWS CLI documentation : AWS CLI is well documented along with examples making it easy to learn and implement.
• Speed : Direct use of AWS CLI is fastest deployment given it native. e.g. S3 sync only uploads files if changed - making deployments even faster
• Control and Ease : Total control over deployment scripts, and it was faster to write them than to learn a new framework. Complex architecture could be handled easily as part of deployment scripts. Master script is interactive - asking user inputs in the process.
• RDS deployment : MySQL RDS creation and running of DB migration scripts is easier using AWS CLI / Bash scripts.
• Partial deployments : scripts are structured for different deployments such as web, API, cloudfront etc - making is easier to deploy only changed components than everything always.

Currently bash + AWS CLI scripts I have written are specific to my project. I plan to upload those generic scripts to github for reference in near future.

Conclusion

Serveless YAML based approach had long learning curve and limited support for complex stack I was building. However, Serverless Components definitely holds promise - I did not have enough time to spend learning, and building custom components to suit my needs.

In my context, I needed a quicker solution with more control to implement my services to AWS, and chose custom AWS CLI + Bash approach for my needs. The custom scripts may not be as flexible as serverless framework but it does serve all my needs, and provide me control.