An easy way to achieve continuous integration (CI) for a Serverless stack

Building an agile DevOps process for Serverless developers with Seed

In the last guest post, we alluded some economics of building services with serverless paradigm. Specifically, we got to know that acloud.guru shared that they were running 287 Lambda functions, 19 microservices with 3.68 TB of data at the mere cost of just $580 per month. This probably puts that startup in an unfair advantage position over its competitors; and it deserves CTOs in the cloud era startups to take a look at the serverless paradigm as the options on the table.

A deep economics analysis for serverless paradigm is out of the scope of this post, which we will find a time to discuss when enough interests arise on that topic — though in my opinion, the infrastructure saving probably is even NOT the dominant advantage for adopting to the serverless paradigm — there are much more profound product and engineering impacts such as team structure and production system maintenance practices.

In this article, we are going to discuss how a small and agile engineering team, with little DevOps engineering capacity, to build a production serverless backend micro-service.

Serverless (sls) as a single person project

Note: this is an intro section for people who did not use serverless (sls) framework. Please skip it if you already used sls.

1. Install serverless (sls) framework

   # npm install -g serverless 

2. create a serverless project with a helloworld endpoint

   # serverless create --template aws-nodejs --path my_first_sls_project && cd my_first_sls_project

3. (assuming you have already set up your AWS environment on your client) deploy the serverless project to your AWS account

   # serverless deploy
     ...
     ...
     You will see the endpoint here

4. Now you can curl and hit your helloworld endpoint

   # curl -X POST https://xxxxxxxxxx.execute-api.us-east-1.amazonaws.com/dev/hello
   
     You will see the endpoint result

This is just a helloworld. Needless to say, to shift toward a team work and production service, we need more…

How to make `sls deployment` a team effort

Serverless (sls) is good for single person to roll out a micro-service within a couple of days — to change the above helloworld skeleton project into a petstore project, it probably can be done within several hours. But how to work as a team?

1. The problem

For a single person hobby project, a local #serverless deploy will be enough, but if a 2nd engineer wanted to fix a bug and then push the code and roll out the fix to the production, then we may run into conflicts. What’s problem? Let’s say engineer 1 changes the serverless.yml or the handler functions in his local machine and makes the #serverless deploy; and engineer 2 practices the same workflow, then engineer 1 and engineer 2 will cause conflict of the desired serverless stacks state.

2. The simple solution: Seed

An easy way to solve the above problem can be simply connecting our github repo to the serverless CI/CD cloud service call Seed. Basically, Seed is a cloud CI/CD service designed for serverless (sls) projects — it understands the serverless (sls) project structure and made the CI/CD pipeline setup straightforward.

In the above diagram, when there is merge to dev branch, we can run the testing by adding test suites into the pipeline (https://seed.run/docs/running-tests.html) — as engineers, we never want to deploy something onto production without running tests.

And then we can manually ‘promote’ our change from a development stage (to qa stage and then) to Prod stage. During the ‘Promote’ step, we can see the serverless stack change in a much visual way than the AWS Cloudformation change-set:

As we can see from the example here, the change is visually very clear (at least I myself am a very visual person), so that engineers know what change he/she is pushing into the target environment.

Summary:

1. serverless framework really made building a serverless backend easy to start with; and for a lot of simple backend architecture, it gives you enough mileage to service your customers;

2. But once it comes to the service deployment, you need a central deployment service

3. Seed is a cloud service that helps startups or small agile engineering teams in a large organization to tackle the CI/CD problem for serverless projects.

Hopefully, with this post, you can roll out your serverless backend to production in a couple of days. Happy hacking……