Deploying an HTTP Backend Service on C4c7us

Introduction

In this brief post, we'll provide a practical guide to quickly and easily deploy a backend HTTP project using our platform c4c7us.

As an illustration, we'll take a project written in the Go language, which is running locally on port 8080, as an example. (The source code of the project we'll use as an example is available in the following repository: https://github.com/c4c7us-cloud/backend-demo)

Requirements

As requirements for our project, it must have at least one endpoint serving as a health check, indicating that the application has started correctly. It should respond with a status code 200. For the particular example, the health check endpoint is located at /api/demo/health-check. When queried locally, it responds as follows:

Additionally, we'll have another endpoint (/api/demo/hello-world) as a demonstration of any other route that can be configured within our code.

If we wish to expose the above service using our platform, we must perform the corresponding login and ensure that the necessary preliminary configurations have been made. These configurations include setting up the API keys of our cloud service provider, creating a domain and environment, and registering Git keys in our online repository manager, be it GitHub, GitLab, or Bitbucket.

Configuration

Once we have completed the configurations described above, deploying our service is a simple and user-friendly process. First, we go to the microservices section in the main menu. Then, we select "create" and proceed to register the parameters of the service we will create, using our project as a base. The parameters to consider are described below:

• Name by which we will distinguish the service within c4c7us.
• The repository where our code is hosted online, in our case, the repository on GitHub looks as follows:

Service type, in our case, it will be a service, but there are different options such as workers, schedule tasks, or lambdas. Build belonging to the service in question (language/framework and version). Type of access the service will have, either public or private. If we choose private, the service is only accessible by other services deployed on the same VPC network. The prefix path under which the endpoints of our application will be located. The health check path (discussed in a previous point). Once configured, it should look similar to the following image, then click the "Save" button.

Verify that it was created successfully.

It is crucial to configure some variables before attempting to deploy any new service in any environment. Therefore, we enter the settings section of the selected environment. In this section, we will find the possibility to configure the variables necessary for the deployment to be successful.

Once we are in the settings section, we can configure the parameters with which the service will run. These parameters include:

• Cpu units: Here we can assign the number of CPU units that will be allocated to the service. This can be useful to adjust performance based on the processing intensity of our application.
• Memory: Here we can set the amount of memory allocated to the service. Depending on the needs of our application, we can increase or decrease the amount of memory allocated to ensure optimal performance.
• Minimum and maximum of instances: We can specify the minimum and maximum number of service instances we want to run simultaneously. This allows us to control the horizontal scalability of the service and adapt it to the expected load.
• Health check grace period in seconds: This parameter is configured as the number of seconds to determine the maximum waiting time to get a response from the endpoint configured as a health check.
• CPU percentage to scale: We configure the CPU usage percentage to control the performance of the instances. If that percentage is reached, and the configuration allows it, a new instance is started to distribute the workload and avoid overload.
• Memory percentage to scale: We configure this parameter to control the performance of the instances. If that percentage is reached, and the configuration allows it, a new instance is started.
• Spot instance percentage: We configure this parameter to determine the percentage of service instances that will be of spot type, remembering that a spot instance is a cheaper but more unstable instance.

Remember that it is important to adjust these parameters properly to achieve an optimal balance between performance and allocated resources.

After selecting the desired values, save them. Additionally, if our project requires environment variables for its operation or configuration, we can add them in the tab called environment variables.

Deployment

Once we have allocated the resources and configured the environment variables, we can proceed with deploying the project to the desired environment. To do this, go to the deploys option in the menu, and when selecting create, enter the name of the tag, branch, or commit you want to deploy from the source code. In the case of our example, we will use the main/master branch.

By entering the tag or branch name, the platform will start the deployment process using the corresponding source code. This involves compiling, building, and running the project using the resources and environment variables previously configured.

Upon clicking the create button, the project launch will begin, and all that's left is to wait for it to be successful. Similarly, we can see the stage and status of the deployment, which if successful will look like the following image.

During the deployment process, we can see in detail the instances created to host the service. The number of instances is determined by the value assigned to the minimum of instances configuration variable. In the previous image, you can see the state of the instance, its identification (ID), and which deployment it belongs to.

Verification

Finally, with our deployed service, we can access the endpoints it exposes over the internet, by pointing to the domain associated with the environment where the service was deployed, and respecting the prefix path configured at the time of creation. As an example, the results of querying the endpoints we had locally, once the deployment is completed, are shown below.

Summary

In summary, throughout this post, we managed to deploy an HTTP backend service that was initially running locally. Through our c4c7us platform, we managed to expose this service to the internet. The key steps we followed were:

1. Creation and configuration of the new microservice: We defined the type of microservice, the programming language used, and the repository where it is hosted.
2. Configuration of instance variables: We established the variables that describe the behavior of the instances where the service will run. This includes aspects such as the minimum number of required instances.
3. Deployment of the service in a specific environment: We launched the deployment of the service in the desired environment. This resulted in our service being exposed and accessible to the public we want to reach.

In summary, we successfully migrated our local backend service to an online environment, allowing it to be publicly available using our c4c7us platform.