Community

Blog Events Webinars Tutorials Forum
  1. Blog
  2. Events
  3. Webinars
  4. Tutorials
  5. Forum
Create Account
×
Community Blog Terraform for Serverless Devs – Implement Enterprise-Level Multi-Environment Deployment (Part 2)

Terraform for Serverless Devs – Implement Enterprise-Level Multi-Environment Deployment (Part 2)

Part 2 of this 2-part series explains some common problems with Serverless Devs and addresses some of the common questions after reading Part 1.

By Fengchong (Senior Technical Expert of Alibaba Cloud Serverless)

Part 1 of this 2-part seriesdescribed how to use the multi-environment features of Serverless Devs. Part 2 will answer some common questions readers may have after reading Part 1.

The Relationship between Serverless Devs and Terraform

Since you have supported Terraform, what is the role of Serverless Devs [1]? Is it enough to use Terraform directly?

The orientation of Serverless Devs and Terraform is significantly different. Serverless Devs is oriented to application management and DevOps, and Terraform is oriented to cloud resources. They are two different fields, but that does not mean that they cannot be integrated (or cannot be integrated at some levels). Integration and integration capabilities are standard to measure whether open-source tools are standardized.

Terraform addresses the provisioning of cloud resources. This field has a very clear methodology. Serverless Devs should emphasize how to make good use of cloud resources. The relationship between the two can be told from following scenarios.

  • Serverless Devs pays more attention to how to upload code or install dependent parts to NAS and pays less attention to how to create VPC, VSwitch, security group, or NAS mount point.
  • Serverless Devs pays more attention to how to upload files to OSS and automatically triggers functions to generate reports. Serverless Devs pays less attention to how to create OSS buckets.
  • Serverless Devs pays more attention to how to build code/image, make Layer, deploy code, release version, and release volume to build a complete CI/CD experience. It pays less attention to how to create FC networks, log warehouses, and ACR instances.
  • Serverless Devs focuses more on how to remotely debug code, log on to online instances, and quickly detect business exceptions through logs and monitoring.
  • Serverless Devs focuses more on the application running state and operations in the O&M state, which is also the most important mission of Serverless architecture tools. However, Serverless Devs is responsible for the full lifecycle management of Serverless applications, which inevitably requires resource management.

We found that whether using cloud product SDK or GPLs (such as Pulumi), lots of efforts are required in the lifecycle of resources, which is very inefficient for component developers to connect to more cloud products.

However, Terraform is the most professional in this area. Whether it is standardization, recognition, and resource richness, it can meet end users' and developers' needs. Therefore, Serverless Devs and Terraform are triggered to combine this idea.

Serverless Devs is not coupled with Terraform. On the contrary, the HCL language of Terraform is naturally used in the component specifications of Serverless Devs, which can be considered as a capability of Serverless Devs to support multiple languages.

The value to developers is that they can complete the construction of infrastructure with relatively low code and devote their energy to the development related to Serverless EDAS application lifecycle management. Otherwise, they have to develop a large number of resources CRUD code, which is very inefficient.

What Is the Difference between a Multi-Environment Feature and Using Terraform Directly?

If you use Terraform to deploy resources in multiple environments, what is the difference between using Terraform to deploy resources?

  • Terraform is a personal tool, that requires local management of ak/sk and local installation of Provider. However, multi-environment is a multi-tenant service, and users do not need to maintain these.
  • Multi-environment functions are important for management capabilities. For example, templates have version management capabilities. When a new version of the template is released, and IaC changes are incompatible, if users update the environment, unknown problems will occur. In this case, the system will automatically identify and ensure that changes in the existing environment also use the old version and will not be affected by incompatible changes.
  • Terraform is a purely resource-oriented orchestration tool, and its association with applications is very weak. However, the environment, services, and pipelines can naturally form a connection relationship. For example, the environment can perceive which services are used by resources, and services can obtain access permissions through environment authorization. Services can be deployed to all environments at one time in the pipeline, which Terraform cannot do.
  • Terraform is only one technology selection for implementing IaC in multiple environments. It plans to connect with ROS, Pulumi, and other IaC projects in the future.

The Relationship between Multiple Environments and Environmental Variables

Use environment variables in CI/CD, configure VPC and NAS in environment variables, and reference environment variables in s.yaml seem to be ok. Why does it create an environment concept?

We can distinguish the difference in positioning from their names: environment and environment variables. Environment variables are a set of static configurations. Although some resource configurations can be written into the environment variable and referenced in the CI/CD pipeline, this method cannot manage resources.

The environment is an entity resource with the ability to manage the lifecycle of the infrastructure. The environment can be used to add, delete, modify, and query the infrastructure and grant the user the operation permissions by RAM. When updating the environment, you can also connect with some security checks.

The environment can be used to protect infrastructure. For example, when multiple services share the environment, if environment deletion is initiated, the system will automatically find that the environment is dependent on other services. In this case, the deletion will be rejected.

Can It Only Be Used by Enterprise Users? How Do Individual Developers Use It?

Is it suitable for me to use this function?

Individual developers are also applicable, but these users should not be allowed to write templates. Instead, the platform should provide templates for various business scenarios. Developers can use them out of the box, which will be our main work in the future.

The most complex concepts of Alibaba Cloud for individual users are RAM, VPC, ECS, SLB, and NAS. The learning curve is too high.

This problem is clear under the Serverless architecture. Serverless claims it has a low threshold, low cost, and low O&M. However, many users give up Serverless because they need to understand a lot of concepts and configure a lot of things to get started with Serverless. Environment templates and environments can significantly simplify the cost of starting cloud products and operate safely at the same time.

For example, if you select a template deployment environment, you can pull up all cloud resources with one click. This is a real Serverless.

Implementation

  • Follow the Serverless Devs component development specifications and implement one component to connect with backend services.
  • The backend service uses the Serverless + Kubernetes architecture and uses messages to trigger functions to perform template rendering and deployment tasks.
  • Use KubeVela [2] to manage Kubernetes resources and execute Terraform tasks

1

Is Multi-Environment a Component-Level Capability Or a CLI Capability?

Serverless Devs consists of CLI [3] and components [4]:

  • CLI provides the most common capabilities and does not rely on any components, such as s init, s config, s verify, -- template, and -- debug.
  • Components provide specific functions, such as s deploy, s build, and s invoke. These are the capabilities of FC components.

From the perspective of the generality of env commands and the problems to be solved, it is also appropriate to implement the CLI. However, from the implementation point of view, a server control plane is required to complete the deployment of user resources. Specific cloud services must be completed for security reasons, so it is completed through a component.

References

DevOps Terraform Computing Serverless Function Compute Deployment R&D Serverless Devs
0 0 0
Share on

Read previous post:

Terraform for Serverless Devs – Implement Enterprise-Level Multi-Environment Deployment (Part 1)

Read next post:

The Ten-Person Team Using Function Compute to Develop the Wolai Online Document Application and Reduce Costs by 50%

Alibaba Cloud Serverless

99 posts | 7 followers

You may also like

Comments

Alibaba Cloud Serverless

99 posts | 7 followers

Related Products

More Posts by Alibaba Cloud Serverless

See All