Uniview DevOps brand new product - two-state deployment is launched

Another brand new product of Uway is online!

Recently, Uniview held a press conference, announcing the launch of "DevOps new product - dual-state deployment" . At the press conference, the status quo of the DevOps market was re-examined, the challenges and opportunities faced by the industry were deeply analyzed, and at the same time, it was revealed in simple terms how "two-state deployment" can deal with various current challenges.

Let's follow Luxiao U to learn more about this brand new product!

"DevOps Market Overview"

>> DevOps Market Size

DevOps existed long before the birth of cloud computing, and an integrated DevOps platform is becoming a global DevOps development trend. Domestic enterprises usually build their own DevOps systems using an integrated platform + open source software.

According to the data given in the "DevOps Application Development Research" released by iResearch in December 2020, the market size of domestic DevOps services has reached 2.7 billion yuan in 2020, and the compound growth rate in the next five years will exceed 25%. By 2025, the domestic market size will reach 8.3 billion yuan, and the market development prospect is good.

>> Common contradictions within the enterprise

 Within the enterprise, there are many contradictions between developers and operation and maintenance personnel, such as:

  • Development thinks that its main work is in the research environment, while operation and maintenance thinks that its main work is in the production environment.
  • Development is first to meet business needs, while operation and maintenance is given priority to ensuring system security and stability.
  • Development focuses more on the realization of new functions, while operation and maintenance pursues system stability without errors.
  • Development often faces some personalized and customized requirements, while operation and maintenance relies on accumulation and experience to advance daily work.

Generally speaking, developers deal with new requirements, have higher requirements for high efficiency, and have a higher acceptance of new methods and new tools. The operation and maintenance personnel deal with the daily operation and maintenance of the software system. It is their primary responsibility to ensure the safety, stability and error-free of the system. They have more worries about new systems and tools, and their acceptance is lower.

>> Difficulties in promoting DevOps products in the domestic market

Coincidentally, in addition to some internal problems of the enterprise, it is also difficult to promote DevOps products in the domestic market.

◆ The difficulty of self-developed assembly line is relatively low, and the willingness of enterprises to purchase is not strong

Although the development and maintenance tools themselves are technically difficult, the DevOps process management module is relatively easy to develop. Generally, enterprise IT teams have the ability to independently develop and integrate other tools in the open source community, reducing the demand for DevOps platform products.

◆ Get used to current process tools

Open source tools such as Jenkins have been around for many years and are well recognized by domestic developers. Changing work habits will also reduce the acceptance of new DevOps tools by enterprises, thereby reducing the market appeal of DevOps platforms.

◆ The process and technology do not meet the requirements

The changes in the workflow brought about by the DevOps platform will not only bring some troubles to the internal IT staff of the enterprise, but may also cause discomfort to the management and even customers that the IT team is connected to.

>> In recent years, technological innovation has created new market breakthroughs

There is no need to worry too much about the above difficulties. In recent years, some technological innovations have also created new market opportunities.

 The search term frequency trend of the word "DevOps" in Google (global). From 2011 to now, the global attention of DevOps has shown a rising trend. During this period, it has gone through three different periods: initial exploration period, accelerated development period and scale application period . Observing the above figure, it is not difficult to find that the attention of DevOps in the market is closely related to the innovation and maturity of container technology:

  • DevOps initial exploration period: Before the promotion of container technology, DevOps received less attention;
  • DevOps accelerated development period: Docker container engine and K8s container orchestration technology have come out and been promoted;
  • DevOps large-scale application period: Docker container engine and K8s container orchestration technology have entered a mature stage.

Especially in the third period, as far as domestic enterprises are concerned, how does their own IT form match the DevOps maturity of this period?

Is it self-developed? Secondary development? Or directly use the DevOps platform of some cloud vendors? For the different characteristics of each enterprise, will it support customization? The answer is probably no. Therefore, for general enterprises, another way out is to purchase DevOps services from some manufacturers.

"Dual-state deployment new product introduction"

>> What is "Dual State Deployment"?

In the field of IT operation and maintenance, the dual-state concept refers to the simultaneous management and operation of two different IT models within an organization to respond to different types of business needs.

The first mode is "Traditional Mode", which focuses on the maintenance of the stability, reliability and security of the existing system, also known as "steady-state mode". It usually involves traditional IT operation and maintenance practices, such as continuous and stable service delivery, change management and risk control. In this mode, the focus is on providing a stable business operating environment to ensure high availability and data security of core businesses.

The second mode is "Innovative Mode", which focuses on innovation and agility to meet rapidly changing business needs. It involves activities such as adopting agile development methods, exploring new technologies and experimenting with projects to deliver innovative solutions. In this model, the focus is on responding quickly to business needs, driving business innovation and providing flexible solutions. So it is also called "sensitive mode".

By implementing a two-state model, organizations can accelerate innovation and adapt to business changes while keeping existing systems stable. The bi-state concept highlights the approaches, processes, and technologies that organizations need to adopt to balance the need for stability and innovation under different IT models.

>> Advantages of HyperDeploy (two-state deployment)

HyperDeploy (two-state deployment) provides a set of standardized application change capabilities. Whether it is for traditional host deployment or the popular container environment, HyperDeploy insists on providing a consistent change experience to help you deliver your applications without feeling.

  • Lightweight environment management: manage and authorize the use of infrastructure resources through resource pools.
  • Self-service resource delivery: Use blueprints to orchestrate complex resource relationships in the environment, and add resources to the deployment architecture in a self-service manner without relying on vendors.
  • One-click integration of site-wide resources: openly integrate external third-party resources, such as Alibaba Cloud, Tencent Cloud, Huawei Cloud, AWS, Kubernetes, etc.
  • Standardized application governance: Standardize management of program packages, configurations, and deployment environments to reduce personalized applications and reduce the complexity of operation and maintenance.
  • Non-inductive two-state deployment: use the same deployment process to smooth out the differences between static deployment and sensitive deployment, and realize two-state application deployment without intuition
  • More reliable application delivery: Covering various application release modes such as rolling, batch, blue-green, grayscale, etc., the lightweight work order approval process builds double reliable application delivery capabilities.
  • Three-dimensional measurement system: Provides all-round three-dimensional measurement of development, testing, deployment, and operation and maintenance to help you accurately analyze process losses and build a more mature application delivery value stream.

>> How does HyperDeploy (two-state deployment) solve user pain points?

Let's take a car company of a joint venture brand as an example to describe how HyperDeploy (two-state deployment) solves its pain points from multiple scenarios.

Scenario 1: The company has more than 200 systems deployed on virtual machines and more than 200 systems deployed on containers, both states coexist and are gradually containerized.

 HyperDeploy (Dual State Deployment) uses the same deployment process to smooth out the differences between dynamic deployment and sensitive state deployment through insensitive two-state deployment, and realizes two-state deployment without any sense.

Scenario 2: Containers are deployed using OpenShift

HyperDeploy (two-state deployment) integrates all site resources with one click, and openly integrates external third-party resources, such as Alibaba Cloud, Tencent Cloud, Huawei Cloud, AWS, Kubernetes, and OpenShift.

 Scenario 3: The C-end business is released without stopping, and the blue-green release mode needs to be supported

 The customer has some C-end business, and the daily release requires non-stop, so a non-stop release mode is required. In addition to the blue-green release method, HyperDeploy (two-state deployment) has expanded to cover multiple release modes such as rolling, batch, and grayscale, and the lightweight work order approval process builds double reliable application delivery capabilities.

Scenario 4: Manual verification is required during the deployment process, and test traffic needs to be imported into Container Service.

The customer needs manual intervention in the system deployment process to verify whether there is a problem with the deployment. If there is no problem with the verification, the user's traffic will be connected online. Therefore, it is necessary to connect the test traffic to the container service, so how does U-Vision HyperDeploy (dual state deployment) solve this problem?

 From the above figure, the right side is a topology diagram. The normal OpenShift container release blueprint only needs a service resource and a deployment config resource, which are the SVC and DC resources on the topology diagram.

If the customer needs a traffic channel so that test users and testers can access the interior of the container to perform some simple tests, at this time there is no need to feed back this requirement to the manufacturer, only need to edit the blueprint on site to find the corresponding resources Added to this blueprint, it can be used directly through simple configuration: for example, add "route_for_test", "service_for_test" and point them to the "deployment config" resource.

The above operations, through self-service resource delivery, use blueprints to orchestrate complex resource relationships in the environment, and add resources to the deployment architecture in a self-service manner without relying on vendors.

"Core Functions of Two-State Deployment"

Next, I will systematically introduce the core functions of the dual-state deployment product.

 In the figure above, we sort out the four dimensions of pre-deployment access, initial deployment and daily operation and maintenance, configuration management, and policy release to explain the capabilities of HyperDeploy (two-state deployment).

A. Pre-deployment preparations

Before deployment, it is necessary to confirm what kind of environment the customer has on site, what is in the environment, and how many infrastructure resources are available.

In response to the above problems, first use the environment to isolate deployment instances for different purposes, such as isolating production and research environments. Then within the environment, use resource pools to pre-allocate infrastructure resources and authorize the dual-state deployment system to access those resources.

 For example, in the figure above, the resource pool of a host is on the left, which provides the ability to label hosts in the management of hosts, which is convenient for users to quickly filter out hosts by tags when deploying. On the right is a resource pool of a container, which mainly highlights how to authorize the state library system, so that the resource pool has the authority to access the external platform, so as to make corresponding configurations.

Next, enter the link of application access. Users who use the continuous delivery 3.0 system maintain a set of application and system systems in the CMDB. After upgrading to the new two-state deployment product, a synchronization mechanism can be provided, that is, when the user enters an application, the application overview page will have an interactive guide to guide the user to complete the application connection step by step. Income, standardization of resources, and completion of first deployment.

 Finally, enter the link of deployment orchestration, for example, what kind of application deployment do you want to describe? How to describe it?

This can be described by blueprints, an interactive package is made in product design, and standardized blueprints are provided for host deployment and container deployment respectively, and as a common function entry, users only need to customize the deployment architecture. Just define a blueprint.

B. Two-state deployment

After completing the pre-deployment preparations, the next step is to deploy.

Because HyperDeploy (two-state deployment) smooths out the differences in the deployment process, it is not necessary to distinguish whether it is host deployment or container deployment during deployment, and only needs to identify whether it is the first deployment.

If it is not the first deployment, what kind of operation and maintenance activities can be carried out on a daily basis? Such as service upgrade, service expansion and contraction, service start-stop, restart, configuration overload unloading, etc., can be quickly operated through the service card, or quickly perform daily operation and maintenance actions through the blueprint.

C. Configuration Center

When the deployment is complete, the application may need some configuration to start. U-way HyperDeploy (two-state deployment) will be used here, which is the first complete configuration center product of U-way ever.

Why do you say that? Because HyperDeploy (two-state deployment) is compatible with both dynamic deployment and static deployment configuration release modes.

 Dynamic configuration : Two-state configuration · The configuration center is fully compatible with the Apollo configuration center client, and the application configuration can be easily migrated to EasyOps. Publishing configuration operations through the configuration center server can update the application configurations of many clients in real time, with high efficiency and no downtime.

 Static configuration : The configuration center continues to be compatible with the static configuration file rendering method used in host deployment, allowing users to seamlessly migrate to dual-state deployment. The use of static configuration requires the management of configuration file templates and configuration values ​​in advance. Before deployment, the composite configuration file will be rendered and sent along with the package for deployment and installation.

D. Policy release

In addition, U-way HyperDeploy (two-state deployment) also provides a lightweight work order approval flow.

 This lightweight chemical order approval flow is completely self-consistent, does not depend on the external work order platform, and has a self-made system, which has the entire process from bill of lading to approval to release to acceptance, and finally closed.

Guess you like

Origin blog.csdn.net/EasyOps_DevOps/article/details/131581986