10 Automation CICD and Canary Release #
Environment Management and Automated Deployment #
When we migrate from traditional development to Serverless, our approach to environment and deployment management will also differ. When users switch to Serverless, they can easily provide more environments, which is a benefit that is often overlooked.
When we develop projects, we usually need a production environment, a staging environment, and some testing environments. However, each environment usually requires resources and costs to keep the service online. Most of the time, the traffic on non-production environments is very low, and it is not cost-effective to pay a lot for it.
But in the Serverless architecture, we can provide each developer with a quasi-production environment. When doing CI/CD, we can create independent demo environments for each feature branch.
When team members develop features or fix bugs and want to preview new features, they can immediately deploy them without having to simulate them on their own machines or coordinate with other colleagues to use testing environments.
All of this is possible because of Serverless. We don’t need to pay for idle resources. When we deploy environments with little to no traffic, the cost is very low.
Because deploying new environments has become easy, the demand for automated deployment has increased. Of course, whether using Serverless architecture or not, automated deployment is important. The ability to automate the building, deployment, and creation of entire environments is an important factor in judging the excellence of a development team. In the Serverless scenario, this ability is particularly important because it allows us to fully leverage the advantages of the platform.
In the upcoming lessons, we will learn that with the help of the Funcraft tool provided by the function computing platform, developers can easily deploy and test code in quasi-production environments in ways that were previously impossible.
Gradual Release #
Due to the elastic mechanism provided by Serverless, it can automatically scale down to zero when there is no traffic, greatly saving the costs of deploying multiple environments. However, different versions within the same environment can also benefit from this mechanism.
Although traditional applications also support multiple versions coexisting in one environment, it is more difficult compared to Serverless. Firstly, each version requires relatively independent runtime environments, which will consume more resources. Secondly, it is necessary to solve the traffic distribution issue between multiple versions.
In the FaaS environment, these issues have been perfectly solved by the versioning and alias mechanism. Since no traffic means no consumption of computing resources, the cost of releasing a version is extremely low, and a version can be formed with each release. Then, version switching and traffic allocation can be done through aliases.
Based on this abstraction provided by FaaS, gradual release and A/B testing become very simple. There is no longer a need for complex underlying settings like in K8s, and developers can easily enjoy the advanced features of smooth upgrades and quick verification.
Conclusion #
Serverless makes development and deployment much simpler. I hope you continue to explore other serverless and function computing content. For more related information, please visit the product page of function computing at https://www.aliyun.com/product/fc.