Building production-grade AWS serverless product — Lambda versioning and API gateway environment variable.
My story: After working for years building applications using traditional architecture, we started building a financial trading product using a serverless event-driven architecture.
Those who are new to event-driven architecture :
The event-driven architecture is an architectural style where components in the system emit events and react to events. Instead of component A directly calling component B when some event occurs, component A just emits an event. Component A knows nothing about which components listen for its events.
Read Serverless Architecture: https://medium.com/@cuelogicTech/event-driven-serverless-architecture-using-aws-lambda-6aef8d52ba80
Stage 1: Learning and adapting to event-driven architecture thinking. When you for years build more traditional systems, concepts look logical, but it takes an effort for your mind to think and design an application that is 100% serverless and event-based.
Stage 2: Feeling of enlightenment. We were building serverless lambda functions. A small team of one or 2 team members was building functions at lightning speed.
Learning: Proper design of event-driven architecture makes work much faster. Teams are clear on their deliverables without dependence on other teams or resources.
Stage 3: Lambda function editing and uploading on AWS code editor. I will write about this stage story later as to how we solved the problem of editing via AWS layers and SAM CLI tool kit.
Stage 4: Release and deployment. We realized we are running only one AWS serverless environment, any impact on the existing lambda will impact the current test cycle. We realized we can't live with this in production.
Once you know your problem then life becomes easy, we start with multiple strategies.
- Github of serverless code and keep on manual syncing the changes — Too old style and error-prone.
- Create another AWS account and deploy everything on that separate account — This was good but the challenge of merge still exist and this is not automatic.
- Build lambda functions with environment suffix. We also create a new API gateway to release those functions into different environments.
- Versioning of lambda and setting environment variables in AWS API gateway stages. This made everything so simple. Developers don't have to worry about release and code deployment on the specific environment.
Let me explain to you how to do versioning and setting stage variables in AWS API gateways.
Open the lambda functions screen.
Click on the action button and click Publish new version.
Provide a description for the reason for creating a version.
Versioning solves the problem of the history of changes on the AWS itself. We need other features so different versions are called in different environments (Dev, Test, and prod). AWS provides the feature of creating an alias for lambda functions. The alias can be assigned to any version and alias are called in the API gateway stage variable.
Now you can see version 1 is assigned an alias uat. Now when in API gateway we call alias uat, version which is assigned to the created alias will be called.
Now we create environment variables in API gateway alias.
Stages help you to define different stages of application.
Create a stage variable name as lambdaAlias and give it values as uat.
You change the Lambda function call to Lambda name:$stageVariables.lambdaAlias.
This helps us to deploy the changes to a different environment with ease and without any extra effort.
Hope you enjoyed reading the above article. I will write about our experience of building applications on cloud platforms.
