Abstract: Cloud Effect, a one-stop enterprise collaborative R&D cloud, provides end-to-end collaborative services and r&d tool support from “demand -> development -> test -> release -> operation -> operation”. Yunxiao plans to collaborate with other cloud products to further optimize the one-stop experience.


takeaway


As a one-stop enterprise collaborative R&D cloud, Cloud Effect provides end-to-end collaborative services and R&D tool support from “demand -> development -> test -> release -> operation -> operation”. At the same time, Cloud effect is closely integrated with other commonly used cloud products, providing one-stop r&d experience with application as the core. First, a larger image:


Why do you need cloud effects to integrate cloud products?


Concept of repetition


At present, Ali Cloud provides a large number of excellent cloud products, such as ECS, SLB, cloud monitoring, log service, to help users with the deployment, operation and maintenance, monitoring, alarm of online services.


But when you actually use it, there’s an obvious problem. Some concepts, such as machine grouping, are implemented repeatedly across multiple products. Suppose I now have an online Web application with five machines. So I need to configure these 5 machines to a group in the logging service, and then I need to assign the same 5 machines to the cloud monitoring group in the cloud monitoring, and hang these 5 machines under some SLB. But it’s easy to understand, because there’s a basic common concept missing, which is application.


As a research and development collaborative platform, Cloud effect is inherently application-centered. There are different environments under the application, and each environment corresponds to a machine group. Using the concept of the machine group, the concept of the machine group of each cloud product can be unified. With the Open API, cloud Services can be configured at the same time as the application is created. The app will also be a quick entry point to other cloud products.


Inconsistent configurations


Let’s take a look at a single cloud product. For example, logging services. The log service needs to configure the log collection path. Typically, users configure each application individually and repeatedly. Some applications may have the same configuration, and some may be different. Imagine that if all applications have the same log path configuration, or at least regular configuration (for example, most of alibaba’s internal applications have logs under the directory /home/admin/< app name >/logs), then cloud effect can automatically configure the collection path when you create an application. So how to make the application log path is consistent, the cloud effect solution is simple, that is to use the code template. Standard logging configurations (such as logback.xml) are included in the code base created through the cloud-enabled one-stop solution wizard.


In addition to the application logs on the machine, you may also need to be concerned about the logs of the Web Server (Nginx/Apache) and the application container (Tomcat). The location of these logs is beyond the scope of the code template. The solution provided by Cloud Effect is the ECS template. You can customize ECS templates or use the templates provided by default in cloud Effect. With templates, the Web Server and application container logs can be located, and cloud effects can be created automatically for you.


Solutions from inside Ali


The problems mentioned above are only part of the problem. And the solution mentioned above is exactly ali’s internal thinking. The internal version of Cloud Effect serves tens of thousands of r&d staff throughout the group. Link the entire application life cycle organically with related services (logging, monitoring, VIP, etc.) to minimize repetitive work. When one of Ali’s classmates creates a new application, the services are almost invisible, and you only get an alarm when the machine actually has a problem. The experience, to be honest, was amazing.


We look forward to using this philosophy to serve more users on the cloud.


More scenarios based on cloud products


The above focuses on how to chain cloud products with applications as the core. From there we can do more scenario-based things like blue-green publishing and dynamic scaling. Here’s an example of how to publish the scene in blue and green.


Blue green release


Blue-green publishing is a common practice in the industry. Based on Ali Cloud SLB, we can also manually implement blue-green publishing, which is nothing more than:
  1. Create and deploy a new machine
  2. Manually switch the SLB traffic to the newly deployed machine
  3. If problems occur, manually switch back to the old batch of machines
  4. If no problem, destroy the old batch of machines


Of course, every time you do it manually, it’s painful. So what cloud effect does is it choreographs scenes on top of infrastructure like SLB. Helps you mask these details.


The original link
To read more articles, please scan the following QR code: