The previous article shared the concept, characteristics, and value of cloud-native to digital enterprises. This article will share how to build a cloud native application, the challenges encountered in building cloud native applications, and current industry solutions.
How Traditional Enterprises Build Applications
The construction of enterprise applications generally needs to solve three basic problems: how to build programs, how to communicate between programs, and program monitoring and operation and maintenance. In different periods, software infrastructure, software architecture, and application scenarios are quite different, so many different middleware software have been born to help enterprises build business applications. The following table lists the middleware that is often used to build applications.
| Time | Infra | Runtime | Async middleware | Sync middleware |
|---|---|---|---|---|
| 2000s | Hardware | Tomcat（1999） | IBMMQ（1990), ActiveMQ （2004），RabbitMQ（2006） | JBoss ESB，Mule ESB |
| 2010s | Virtual Machine | Springboot（2012） | Kafka（2010），Pulsar(2012) | SpringCloud，grpc |
In 2000 and before, applications were deployed on physical servers. At that time, most of the programs used a monolithic architecture, and usually the programs were packaged and run on web servers such as Tomcat or webLogic. The applications at that time were generally designed based on the SOA architecture, and services were discovered and invoked through the ESB before the application. In some cases, such as data exchange between different manufacturers, data needs to be sent asynchronously, and a message bus such as IBMMQ or RabbitMQ will be used.
Around 2010, there was a big change in the software infrastructure. With the rise of virtualization open source projects such as Openstack at any time, more and more enterprises feel that virtualization can bring huge advantages such as higher resource utilization, better maintainability and flexibility, and lower costs. Switched from a physical machine to a virtual machine. The corresponding software architecture has also undergone tremendous changes, and more enterprises have begun to replace the previous traditional SOA architecture with microservice architecture.
Enterprises have new requirements for the tools for building application software. Because of its light weight and convenient deployment, SpringBoot became the mainstream choice for deploying microservices at that time. Open source microservice framework applications such as SpringCloud, Dubbo, and Grpc can better leverage the flexibility and scalability of virtual machines, and have become the best practice for building microservice architectures. Compared with traditional software architectures, the cluster size of microservice architecture applications is an order of magnitude larger than before. This puts higher requirements on the middleware of asynchronous communication, because the new generation of message queues such as Kafka and Pulsar, which can support larger cluster scale and have higher throughput, became the mainstream choice for enterprises to build microservice architecture at that time.
How to build cloud-native applications
In 2020, due to the impact of the new crown epidemic, many enterprises and organizations around the world began to accelerate digital transformation, and cloud migration has become the mainstream choice for global digital enterprises. This year, the infrastructure of the application software was switched again. More enterprises are choosing to switch from self-supporting computer rooms to managed cloud services, and enterprise software is gradually switching from being deployed on virtual machines to containers, a new type of infrastructure. The cloud has become the base and infrastructure of the digital economy.
As mentioned in the previous article, the cloud has the characteristics of pay-as-you-go and elastic scaling, which can give enterprises lower usage costs and higher flexibility, and can accelerate enterprise innovation. There is no doubt about it. How to enable enterprises to enjoy the dividends of cloud computing is the key to the problem, which is also the value of enterprises building cloud-native applications. Unlike traditional applications, cloud-native applications are built on brand-new infrastructure, and many traditional construction tools are difficult to apply in cloud-native scenarios. The biggest challenge in building cloud-native applications is elasticity. How to build an elastic application that meets business requirements and cloud operation characteristics, and how to monitor and manage elastic applications if it supports communication between elastic applications has become the three problems that must be solved when building cloud-native applications.
Build fully elastic, on-demand applications
The biggest feature of the cloud is elasticity. Because cloud-native applications have good elasticity, when the business increases rapidly, the application can be rapidly expanded to support incremental business and ensure the safe operation of enterprise business. Similarly, when the business volume decreases, the application can be quickly scaled down to reduce the cost of enterprise cloud consumption. However, this does not mean that applications deployed on the cloud will be elastic. Moving traditional enterprise applications directly to the cloud will not be able to enjoy the benefits of cloud computing. Traditionally deployed applications in SpringBoot will obviously not be able to provide flexibility in the cloud. .
Building elastic applications based on K8s may be the first choice for cloud nativeization. K8s itself provides the ability to schedule, orchestrate, and expand underlying computing resources. Based on the elasticity provided by K8s, the application can automatically expand pods when the load is high, and automatically shrink the number of pods to determine whether to calculate resources when the load decreases. Many high-concurrency business applications, such as e-commerce systems, taxi-hailing systems, machine learning applications, IoT applications, etc., are more suitable for building based on k8s. K8s also provides powerful container orchestration and automatic management functions, which can easily manage and expand various services of microservice applications, including load balancing, automatic scaling, failure recovery, and deployment upgrades. The scheme of building elastic applications through k8s also has some shortcomings. K8s is very complicated, requires a lot of learning costs, and has high requirements for R&D personnel. In addition, applications built on the basis of K8s cannot obtain fully elastic capabilities. Because K8s natively supports fewer elastic scaling indicators, it currently only supports resource indicators such as CPU and memory, and business support needs to be expanded by itself. Moreover, K8s can only support the expansion and contraction of the application from 1 to N, and cannot support the expansion and contraction from 0 to 1.
For some scenarios with low-frequency high-traffic bursts or short-term tasks, it is more appropriate to use Serverless programs than to build directly based on k8s. For example, file processing, when a large file is uploaded, a large number of processing operations such as transcoding, scaling, and cutting need to be performed on the fast file, but the frequency of file uploading is very low. At this time, K8s has weak longitudinal elasticity and it is difficult to meet such high-elasticity scenarios. Serverless programs are more suitable for such scenarios with features such as fast elastic scaling and pay-as-you-go. For example, aws lambda can quickly expand the capacity of 1,000 instances at the second level to meet sudden business needs, and after processing, all computing resources can be charged according to the number of calls. Another example is some short-term task scenarios, which may only run very rarely every day. If deployed on k8s, at least one pod's computing resources will be required. It is more appropriate to use a serverless program, because a serverless program is event-driven. When a business event is required, the function will be called to run, and it will not occupy computing resources at other times.
At present, there are many open source serverless projects in the industry, such as Knative, KEDA, OpenFaaS, OpenWisk, etc. If you want to build a one-stop serverless solution through open source, Knative may be a better choice. Knative is an open source enterprise-level solution for building serverless and event-driven applications built on top of K8s. It is also an open source project incubated by CNCF. It has graduated and the open source community is relatively active. Knative can help users manage the life cycle of the entire container, and realize the automatic expansion and contraction of containers from 0 to N. In addition, Knative also provides a lightweight Function, allowing users to submit only simple functions, which can create functions and manage function workflows. The disadvantage of Knative is that it is relatively complicated and has a high learning threshold, and running Knative requires the deployment of Istio, Kafka and other projects at the same time. The operation and maintenance are very complicated, which poses a great test to open source personnel.
For users who currently deploy most of their business on k8s and want to have serverless flexibility, the KEDA project may be a very good choice. KDEA is an open source K8s event-driven scaling component, and the project is developed by Microsoft. It is also an open source project incubated by the CNCF Foundation. The positioning of KEDA is different from that of Knative. It is only an open source component and does not provide the runtime environment of the program. KDEA can help K8s applications realize automatic scaling from 0 to 1. At the same time, KEDA provides access to dozens of event sources including Kafka, Datadog, AWS DynamoDB, etc., which can help K8s applications quickly build an event-driven serverless application. KEDA itself can also detect the rate of event requests in real time, and dynamically expand and shrink Pods according to events.