Serverless world, we don’t need to setup server. We just take care of codes (called
functions). However, one of the major drawbacks of the current FaaS (Function as a Service) providers in the
Serverless world is they support lack of code management features. In this post, we’ll compare both AWS Lambda (
Lambda) and Azure Functions (
Functions) in regards to the source code management.
Lambda doesn’t natively support code management. We can do version management by uploading a
.zip file as an artifact.
However, this is not an option from a DevOps perspective because we should manually upload the artifact. Web editor doesn’t store any change history. So, what should we do for
Lambda? Fortunately, there a nice open-source tool called
Apex claims that it helps us manage codes for testing and deployment. Sounds awesome, doesn’t it? Let’s have a look.
In order to use
Apex we should have AWS CLI installed on our local machine (and build server, too). Take an appropriate installation method based on our OS (let’s say Windows in this context). Once we install AWS CLI, then we can check if it’s properly installed by typing command like:
Now, we’ve got AWS CLI installed on our dev box. Let’s configure my AWS settings. Type
aws configure and enter
AWS Access Key ID,
AWS Secret Access Key,
Default region name and
Default output format like:
We’re ready for
Apex. Let’s move on.
Apex is platform-agnostic. Its binary can be downloaded from their repository. Make sure once download a binary, rename it to
apex for your convenience (of course you can use its original name, if you prefer to do so). Then run the following command:
By giving a project name and description,
Apex is ready for deploy.
apex init, several files and folders are generated.
Run the following command:
Now, we have a Lambda function deployed to AWS.
Note that deployed functions through
Apexcannot be modified directly on the web as it’s zipped and uploaded by
We have looked how
Apex sets up and deploys functions to
Lambda. Now, we just simply type
git init and push this to our build server. From now on, we can manage our code history.
Managing codes in
Functions is far much easier than how it is done in
Lambda, with being helped by
Functions natively supports git, so we can simply take the repository URL from Azure Portal and use it.
If we choose
Local Git Repository, access details will be automatically displayed on the display panel.
With this git access details, we can integrate our build server to manage code change history.
Note that deployed functions through git cannot be modified directly on the web.
So far, we’ve briefly looked at both AWS Lambda and Azure Functions with regards to the code change management.
Serverless is surely an attractive and emerging technology, so it would be worth watching how it grows up.