[Live Review] 2021MAXP Open Class 3: Cloud Native Applications and Rapid Development

This article is a review of the full version of the third lecture of the 2021 MAXP series of public courses. It is lectured by Mr. Huang Shuai, a senior developer evangelist from Amazon Cloud Technology, and introduces the knowledge of cloud native application development and a rapid development case of flight query and booking application. share.

Live video review: https://www.bilibili.com/video/BV1RL41137rA?spm_id_from=333.999.0.0

About 2021 MAXP

The 2021 MAXP High Performance Cloud Computing Innovation Competition (2021 MAXP) is guided by the High Performance Computing Professional Committee of the China Computer Society and the China Academy of Information and Communications Technology. It is co-sponsored by the ACM China High Performance Computing Expert Committee (ACMSIGHPC) and the Cloud Computing Open Source Industry Alliance. Amazon Cloud Supported by technology and Tencent Cloud, with participation from vendors such as Alibaba Cloud, Huawei Cloud, UCloud, and Tianyi Cloud. With the theme of high-performance cloud computing, the competition aims to further promote the development of domestic high-performance computing, and provides participants with a prize pool of up to 400,000 yuan, as well as internship opportunities and authoritative certificates of honor.

Live review

Huang Shuai, a developer evangelist from Amazon Cloud Technology, has been engaged in software research and development and related consulting fields, has more than 10 years of experience in architecture design, and has experience in operation and maintenance practices, cloud-native reliability governance, and observability construction. In-depth research and rich case experience. In this issue, Mr. Huang Shuai introduces the relevant knowledge about cloud native applications:

• What is a cloud native application
• Delivery form of cloud-native applications
• Core expectations for the rapid development of cloud-native applications
• The basic characteristics of the rapid development of cloud native applications
• Serverless building blocks for rapid development of cloud native applications
• Quickly develop a flight inquiry and booking app
• Review summary

What is a cloud native application

Cloud native applications are a way to build and run applications on the cloud. Because this method uses the delivery model of cloud computing, no matter it is the part that builds the code, the part that executes the code, or the part that maintains and runs the code, there is a corresponding cloud service support. Therefore, it can be used to quickly develop corresponding software applications, and then quickly market them, and then respond to customer needs more quickly.

At the same time, on another level, cloud native applications also provide developers with stronger capabilities.

In today's era of big data, applications are changing rapidly. In the past, the development of applications was based on the existing framework, and after years of accumulation, the application could be done well and stabilized.

But in the cloud, especially new technologies such as Serverless in the following article, most of the work in software development can be hosted by cloud services. Therefore, software developers can pay more attention to their own business code, which greatly reduces their workload.

Another big feature of cloud native applications is that cloud native development integrates the concepts of DevOps, continuous delivery, microservices, and containers. The entire cloud native approach also includes the concepts of DevOps, continuous delivery, and microservices. Related architecture and governance models and containers.

The container can now be simply understood as part of cobordism.

Delivery form of cloud-native applications

The definition of cloud-native applications is about its development, molding, production, and promotion. There is a gradual evolution process behind this.

The first stage is Demo, which is to implement the demonstration of new business, make some core functions and specific functions into Demo, and attract relevant users to invest in it.

The second stage is PoC (Proof of Concept), which is the proof of concept. For Dome, PoC will be relatively independent, and it has begun to involve more specific requirements and use cases. So it can also be called an independent partial use case.

The third stage is Prototype, the part of prototype design or prototype development. At this time, the actual application scenarios it covers are not very comprehensive. The system is also relatively complete, but not large enough.

The fourth stage is Pilot. After Prototype is finished, the application must be pushed to production, so it must be made into a production system. It is different from the more complete system in Prototype (prototype design). It has many considerations. Whether it is architecture, operation and maintenance, or actual code changes, continuous delivery, and so on. Prototype is the Pilot, which is a pilot. This may still be a part of the use case, but it is better than Prototype because it is a production system. At this time, there will be real users participating in the investment.

The fifth stage is Production, that is, after a real production system is produced, all the use cases defined before must be able to meet the needs of users.

Therefore, the delivery form of the entire cloud-native application has gone through five stages: Demo→Poc→Prototype→Pilot→Production.

The most important part of this is Prototype, which is the part of prototyping or prototyping. This is a truly complete system. Therefore cloud native applications is actually focused on the prototype design . It can be considered that the rapid development of cloud native applications actually refers to Prototype-prototyping or prototyping.

Core expectations for the rapid development of cloud-native applications

The expectation for rapid development is that it can quickly verify that all projects are feasible, and in essence it is to innovate quickly, because behind this is basically new business and new needs.

First, in the process of rapid development, new software technologies can be used. For example, Serverless architecture: Serverless method, which is a new type of software technology, which means that after using cloud serverless services, developers no longer need to care about the needs behind the application, such as computing and storage resources; they don’t need to pay attention to automatic expansion. For the part or the part of operation and maintenance management, developers only need to focus on their own code and the business logic written by it.

Second, through rapid development, you can promote the final development of the application in the direction of production, which may require relying on third-party software. More importantly, the application must run on the infrastructure, and it is expected that it has all the relevant, automatic, and scalable capabilities on the infrastructure. Therefore, in terms of comprehensive governance, cloud services must be used.

Third, the part of continuous optimization is also the expectation of rapid development. That is, in the process of rapid development, not only can the development cycle be shortened, but also risks and costs can be reduced.

So, in simple terms, the core expectations of the rapid development of cloud native applications are basically three points: rapid innovation, comprehensive governance, and continuous optimization.

The basic characteristics of the rapid development of cloud native applications

The basic characteristics of the rapid development of cloud native applications are lower costs, higher efficiency, and better products. Start small, fail quickly, and continue to iterate.

In the process of rapid development, we must start small. If the application is delivered quickly, and there is a failure, let it roll back, and then continue to develop, so the part of continuous iteration is required.

In the development process, the basic characteristics of the application are large, and the process of rapid development of the original application can be clearly seen. Basically, this is a fast process: first list the user stories in one day, and this is the part of the requirement.

Then, spend another day to design the architecture according to the requirements, and then spend another day to prototype, because it still has an interface part.

In the interface switching part, as well as the related front-end or back-end prototypes, they will undergo a longer period of development later, and finally realize the real coding, which can make the product run. This process is mostly within 5 days.

Finally, it takes two days to do the test. This is the verification part. Basically, the developer's application is quickly developed and the process experienced is this.

The low-cost and high-efficiency that developers expect, that is, the product can fail quickly and continue to iterate, which is such an accelerated innovation process.

Serverless building blocks for rapid development of cloud native applications

As can be clearly seen in the above picture, if you want to quickly develop a good native application, you will basically use Serverless building blocks. The building blocks of Serverless are actually cloud services on Amazon Cloud Technology, such as Lambda, which can be regarded as Function as a Service; the part of Fargate is a fully managed cloud computing service.

Regarding the service of Kinesis, there will be S3 for storage, and DynamoDB for NoSQL as the database; and Aurora Serverless for relational database. Developers can easily make choices according to different scenarios.

There is no problem in the development coordination process, the debugging process, and after the debugging is completed. It is actually delivered, including testing in the middle, because it is a continuous delivery pipeline. During this process, Amazon provides a lot of development tools, including infrastructure and code. and many more.

The governance part is also observable, so you can use the serverless building blocks for rapid development of cloud-native applications to help developers really do a good job in rapid development.

Quickly develop a flight inquiry and booking app

Next, a practical example is used to show the core technology of the rapid development of cloud-native applications, that is, the rapid development of a flight query and reservation App. The first is to determine the user's destination and departure place, estimated departure time, and arrival time, to help the user analyze and evaluate the selected flight and ticket price, and finally the user determines the flight ticket that needs to be purchased.

In addition, more importantly, users will implement a membership system in the process of purchasing air tickets, and members will have corresponding membership points, as well as the status of relegation upgrades. For this type of situation, use the developed flight query booking app. Corresponding membership services are required.

This may seem complicated, but it can be simplified by using the serverless building blocks in the rapid development of cloud-native applications.

The picture above is a relatively complete flight query booking and membership service App.

It can be seen that there are a lot of content on the App interface, such as data analysis and data processing, which will use API gateway; Lambda or Fargate will also be used.

In addition, there are related front-end, back-end and its data, as well as machine learning for analysis.

Therefore, enter the departure airport and arrival time on the front page, and then click Search, the corresponding API will be displayed behind it.

There will be actual business logic behind the API, and even query data and feedback results in the database, so we need to develop such an App:

First, if you use Serverless building blocks, including the front-end part, there is the Quasar framework, which is also based on Vue.js through packaging to get the out-of-the-box framework of the website and application.

Second, the progressive JavaScript framework.

Third, our Amazon Cloud Technology service is called Amplify. That is, it can help developers to make full-site applications for front-end Web and mobile apps. You can use Amplify to configure the corresponding application back-ends and connect them within a few minutes, which simplifies the development process, just a few clicks The entire static external application can be deployed. It also supports many external frameworks, such as Android, IOS, etc., so when Amplify is used, the front-end and back-end processing will become easier.

Fourth, Stripe Elements is a payment service abroad. Because in the process of using the App, tickets will be purchased, so there will be a payment framework accordingly, which involves the front-end framework of the application.

Fifth, it is the authentication part. The authentication part is coordinated with cloud services, namely Amazon Cognito, which can help with user management and authentication management.

Sixth, it is the core part, that is, API. If there is a front end, an API will be required. This is because the gateway of the API is used.

Seventh, is Amazon Cloud Technology AppSync. The real meaning behind Amazon Cloud Technology AppSync is that it uses GraphQL technology. The benefit of GraphQL is that it can improve efficiency. In many cases, it is necessary to check more complex information content in the database, or when there are many federal queries, it may This rest method is actually more difficult, so GraphQL can help front-end developers query multiple data, and then help develop applications faster, which greatly improves efficiency, so Amazon Cloud Technology AppSync is very meaningful.

In detail, the first page will be in the airport of departure and the airport of arrival. You need to select a specific date, and then click SEARCH FLIGHTS. The corresponding API is well defined. Then the front-end part will call this API. The API needs to query the flight information in the destination database.

The later VTL, called Apache Velocity's template language, can easily define the GraphQL request from the client, and then convert it into the required data source method or format.

The above page indicates that the flight has been selected, and then the order is placed. The actual back-end part behind this process is the API gateway, and then there is the Lambda part, which writes the corresponding logic, then calls the API of the third-party payment platform, and finally implements the corresponding payment action.

At the same time, it should also be noted that there are payment failures, cancellation of reservations, or user not paying, etc. In such a process, another Amazon cloud technology service needs to be used: Step Function. There is an orchestration service behind Step Function, which is actually a design. Workflow, that is, all the workflows in the entire booking and payment process.

So it has a certain logic, this logic needs to help realize the corresponding state machine and workflow through Amazon Technology's Step Function method.

Further down, there will be listBookings, that is, query records, which can make the user's actions clearer.

Because this involves querying relevant flight information from DynamoDB, and the other DynamoDB may need to query relevant order information. They are two different databases, which store different data content, one is flight information and the other is reservation. information.

Of course, when doing the listBookings API, you need to read the contents of these two parts at the same time, and then combine them to rearrange the data, and then display it to the front end, so this process must use AppSync, because AppSync uses GraphQL Ways to help front-end developers query multiple databases.

Finally, there is the issue of membership that needs to be considered. After all, members have membership points, levels, etc. The specific operation is simple, but the principle behind it is to formulate detailed rules for membership levels. After each formulation, all members The calculation of level points and the rise and fall of levels all need to write logic through the Lambda service. The data may be stored in the DynamoDB database. The API gateway actually represents the supporting part of the corresponding API, so you can see that if there is a successful order confirmation, there will be a program to calculate the relevant member scores, and this process depends on the service of Amazon Cloud Technology , This is all related to Serverless, that is, native applications, all the building blocks needed for rapid development.

To sum up, basically the architecture is very clear: there are front-end and back-end. The front-end part, that is, the real user's flight query booking and membership App opens. During this process, the page you see is actually a website mobile terminal. On this website, there is its CDN at the top, that is, the content distribution and hosting part. It uses Amazon Technology's CloudFront. The front-end part is the object storage S3, which stores all the information of the page, the resources of the page, and so on. The framework mentioned in the previous article will also be used, which can facilitate developers to provide urgent support for related out of the box, and its support for desktop and mobile browsers is also very strong.

The back-end part is the API part, and the API part uses AppSync of Amazon Cloud Technology. There is a lot of complicated logic behind AppSync, because it often involves a lot of content, such as flight information query and membership level.

The predetermined part and the payment part are divided into four different types of APM. Among them, serverless building blocks are needed, such as DynamoDB, Lambda, API gateway, Step Functions, etc., which are all the cloud native applications mentioned earlier. The building blocks of Serverless in the development, therefore, Amazon Technology's cloud services can help developers quickly develop cloud-native applications.

In addition, there are continuous automated monitoring and other content, included in the final part, will also use Amazon Technology's CloudFormation, X-Ray and CloudWatch and other tools.

What follows is an overview of the code. Basically, at the beginning of the app, login and user authentication are required. Behind this is the Amplify framework of Amazon Technology, and the user authentication part behind this is implemented by Cognito of Amazon Technology Services.

The figure above shows signUpConfig, which is all the parameters used in the registration process, such as the user's name. At the same time, in related resources, do certifications related to Amplify development.

The more important point is that a lot of the front-end content is obtained through losses. The API part basically uses the Amazon technology App, so you can get a lot of data, such as flight information, reservation information, and membership level information. Defined in the establishment team.

Basically, most of the codes you can see are int (integer), string type, and a few Boolean types. These are detailed data definitions and structure definitions.

The above is about the code of the API. In fact, the API is very simple. The above code has added the authentication process, and it also defines all the relevant fields. In this way, the API of Amazon Cloud Technology App is formed, and related logs will be generated behind this API, which can reflect the status of various indicators.

In practice, after the App is developed, most services are managed. Developers only need to write content related to the front-end. Kinesis is an out-of-the-box accessory, so many functions only need to be simply matched by the developer.

To put it simply, serverless can basically help complete the back into part, the infrastructure part, and the third-party part, so developers only need to pay attention to their own code. In this way, you can use the functions in Amazon Technology's Amplify, and then quickly do the relevant build deployment and verification parts, which is a very convenient process.

In addition, it is more important because it involves a lot of calling relationships between different services. Therefore, you can use the X-Ray service of Amazon Cloud Technology, which can display various called information and called services in the X-Ray link tracking topology map, so once any problems occur, you can clearly see The green circle will change, it may partly turn yellow, all turn yellow, or appear red. Red indicates that the developed product cannot be used.

And, in the monitoring part, Amazon Cloud Technology's CloudWatch is used, which can help developers quickly make corresponding dashboards.

All KPIs like orders and payments, including many other data points, can use CloudWatch's cloud service to draw corresponding dashboards. This is also an important supporting force for rapid development.

In the log part, you can also use Amazon Cloud Technology's CloudWatch service to filter out the data in the corresponding log by querying related statements and fields, and do the corresponding analysis or accounting work.

All in all, in this seemingly complicated flight inquiry and booking and membership management App, a large number of projects are involved, but there are many services that can be quickly developed using cloud-native applications. As long as they use the Serverless building blocks (Serverless services) provided by it, developers can quickly build this App.

The QR code on the right is the open source address of the app’s get up. If you are interested, you can scan it to find the relevant code. Read today's sharing after reading the code, you can have a deeper understanding of the rapid development of cloud native applications.

Summarize

To summarize briefly, first of all, cloud-native applications are a way to build and run applications on the cloud, and their delivery patterns go through five stages.

Second, it is also the most important part of the sharing in this issue, that is, the part of rapid development. For rapid development, the desired effect is low cost and high efficiency. Among them, there are three basic processes and six characteristics. At the same time, rapid development needs to use the serverless building blocks provided by cloud services, also called serverless services, to support the rapid development of the entire cloud native application.

Third, the real example is the flight booking query and membership management App to help understand how to quickly integrate the seemingly complex App from the front-end, back-end, database, and related API parts. Realize the effect of rapid development through related serverless cloud services.

Hope this sharing can inspire readers. In practice, with cloud technology, people's views on many things will change accordingly. It is hoped that in the future, through learning and development in the cloud, we can obtain more continuous and iterative business value. This is also the original intention of the core technology for the rapid development of cloud-native applications in this issue.