Cloud Native Computing Foundation KubeCon + CloudNativeCon Europe 2022, 1 Jun 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Empower Autonomous Driving with Cloud Native Serverless Technologies - Benjamin Huo & Xiuming Lu

Description

Don’t miss out! Join us at our upcoming hybrid event: KubeCon + CloudNativeCon North America 2022 from October 24-28 in Detroit (and online!). Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.

Empower Autonomous Driving with Cloud Native Serverless Technologies - Benjamin Huo, QingCloud Technologies & Xiuming Lu, UISEE

For an Autonomous-Driving platform, the complex use cases and numerous modules pose huge challenges to the entire architecture. Take data-archiving as an example, large amounts of time-sensitive data are generated in the vehicle and cloud every second, scattered in various devices and clusters. Challenges like multi-types of storage media, non-uniform data size, mixed asynchronous operations, steep resource overhead curves all prompt for a more flexible, elastic, and cost-saving architecture. In this talk, UISEE developers and OpenFunction maintainers will talk about: - Why does Autonomous-Driving need a modern FaaS platform powered by Dapr, Keda, and Knative? - Cloud Native FaaS Platform OpenFunction Intro. - Why is an asynchronous function a good fit for Autonomous-Driving? - How does UISEE use the Asynchronous functions in Autonomous-Driving? - The benefits that a modern FaaS platform brings to Autonomous-Driving. - OpenFunction updates & roadmap.

A

Hello and welcome to cubicon next we are going to share uh how to use cloud native service technology in in the autonomous driving industry and benjamin hall, and, together with me, is assuming lou from uuc.

A

I'm the senior architect of cubesphere, I'm the also the creator of the function and xiumin is from uc and the architecture of the autonomous driving cloud platform.

B

A

Is the agenda function is a native fast platform. So the question is why we build the such a platform in the first place and how to build it. So, following that will be uh of the functions introduction, including several components and the earlier adopters contributors, the used mic and the build demo in an assuming view are introducing how the use of a function in autonomous driving okay, so why we need a open source kind of native fast platform.

A

In the first place, I think in the recent years we have heard multi-cloud distributed cloud or hybrid cloud more often than ever. I think it is because kubernetes brings the possibility of cloud agnostic right, but as for the first or service area, it's difficult to be a cloud agnostic, because each cloud provider has its own fast platform and usually this platform are tightly coupled with each cloud provider's back-end services. So it's difficult to to be a move, one cloud from another move from one club to another card for the service part.

A

So it is possible to build a cloud native and cloud agnostic fast platform. I think.

B

The answer is yes, because.

A

The new progress of cognitive service technologies make this possible. I think the most famous uh technology in this area is the community, but today I want to talk talk about another two technology that is debra and cada.

A

Cada is a great product to auto scale, applications on kubernetes based on the different metrics of different human sources. So we can use level. uh We can use alkydar to decouple the auto scaling of application with many many different, even sources, including the open source unit sources or the cloud providers even sources right. So this is cada.

A

We can also use staffer to decouple the distributed application with the underlying backhand services.

A

For example, we can use that first pub sub building block to decouple the of events and the sub of events from the underlying uh massive brokers. Right, so user can use open source message broker such as kafka or not streaming, or they can also use the massive broker from cloud providers such as a ucp pub server or azure ui bus, so usually for a fast platform.

A

A first platform should support several languages and they need to communicate with many many uh different kinds of back-end services, so suppose a fast platform need to support five languages and they need to communicate with 10 massive cures and without dapper. Each language has to use different sdks to communicate with different messages.

A

So this ends up with a 50 implementations actually, but with diaper. Each language only need to use diaper sdk to talk to diaper and therefore handle the rest communication with other message queues. So we only need to. uh We only need a five implementations in this receptor, so it has greatly reduced the complexity of a fast platform.

A

So it's like adding a additional layer between the fast and the backhand services, so dapper, acting like a unified interface for the backhand services. Actually, a couple of weeks ago, we have shared how we are, how we are using uh diver in open function with developer community and the two co-founder diver mark and jerome. We are very glad to see the integration of diaphragm of service function, runtime black open function. So, um finally, um what is open function?

A

Actually, there are several uh three components under the uh function and parallel and the first is the build now uh open function supports using uh build packs, cognitive view, packs to build function, source code into container images and the other three uh dockerfile relevant, build technology are, can be used to build applications for now. Maybe we can also use them to build functions in the future and the serving part. um The certain is the most com most important part in open function. uh Now we support each runtime and synchron app for sync runtime.

A

We currently support using native asynchronous and we are planning to support cada atp as another thing runtime. Actually we have. Actually we have uh maintainers is contributing to kida iep product.

A

I think the most unique or differentiating feature of open function is the async runtime is powered by damper and kida.

A

I will explain in more details later now. The last component is uh open function, events, it's uh it's kind of like a community event, but uh actually it is uh inspired by argo evans with some different difference. I will place them later, so open function build whenever a function is created, it will create a builder and the builder will will create a shipwright build and build run together with the build strategy.

A

Shipwright will create a titan task force and the build steps are created in the touchscreen and execute it in order, and this is how the function source code is built into a container images.

A

uh The serving parts, as I said, open function, uh countries support open uh the kinetic sync runtime and the open function is in current time the both the synchronized and the asynchronous can use data and the difference is uh for synchronoum. uh We only use the output ability of level component and because the input is from the atp and for the async runtime we use, uh we use the both the ability of input and the output uh from the entire uh component and cada is used to auto scale the function.

A

Instead in the future, we are going to support uh cada idp as another synchron type and to speed up the course start. We are also considering using a pool master as another runtime. Whenever a function need to be created, it will take a already an existing existing port in the poll to start the function instead. So this way the coaster will be very fast.

A

So this is the of the function. Storing um the open function, events, uh it is inspired by algo euns, but the difference is the even the bus in open function. Events is decoupled with the underlying massive broker by using diaper puffs up a building block, so user can use kafka not streaming or any cloud providers uh mysql such as gcp pops, up or azure universe.

A

Whenever I even arrive in the event sources, the inner source can call a sync function directly or write. The us back to the unit bus whenever the events are written to the unit device it can trigger a async function directly or user, can define a trigger to filter the events. They are interested and trigger a single function or write the filtered events back into the image bus.

A

So this is even open function. Events.

A

Another important component is the function framework the function from. Actually uh this is the inspired by google cloud function and we have add the uh our own function. Signature here, both the sync function and async function can use the same function, signature to define their functions.

A

There are several components here. You can see the context, the plugin, the runtime and the framework. The framework, of course, will read the function, context and register the plugins and start the agreed, the function runtime and finally, it will start a function runtime whenever a thing function or async function is triggered.

A

The framework will first execute the function, pre-hook and call the user functions and execute the post books and finally process a function output we had, you can find more details in the links below about the proposal and how the function implementations.

A

We have the plugin mechanism here, because we want to support function, tracing function, tracing function, performance is important to.

A

A fast platform, so let's take a example here, uh user, send a hp request to a sync function and the sync function will then publish some messages to the calculator via data set card and whenever a message is published to the kafka server and the issuing function will be triggered through the temporary setcast uh subscription.

A

So for use case like this uh user need to know uh uh how how how long the sync function takes a sync function uh takes and how long the async function takes. So uh we have uh in the last couple of months we have worked with a sky, walking, community and user can simply add the scout. The choosing like this to the function annotation you can see that here is that the provider is scan, working and the oep server and some text.

A

And of course uh you can add this choosing configuration into a copic mark and that way the tracing will be applicable will be, can will be valid for all functions instead of well function. So, if you look at the choosing configuration to the sync function and async functions annotation, you can see a call stack in this sky. Working ui like this, and you can also see the choosing data here below here- is the sky walking official site there. There is a demonstration of the integration here here.

A

You can see the function, score stack and the tracing data here. So um this is the open function tracing earlier. Doctors.

A

Actually, one of the major telecom companies in china is using the function to build their fast platform. Now and uc is using open function to process our hyper data.

A

There will be more details later and changing is a local platform and they are using open function to implement its login mechanism, and we have also contributors to writing the domain function frameworks on the roadmap.

A

Next, we are currently going all support.

A

The go function frameworks very well and next we are, we are working on the uh other languages node function frameworks, the uc team is contributing to the node.js and the person function framework, and we have also planned to add in the java.net function from work, and a few days ago we have discussed with server and queuecast community to the uh the developer. Community will add the uh level support to being the deeper support to the kokas environment.

A

After that we are going to support running from java functions in the kucas environment. It will be much faster than the ordinary java function and also we are going to support the sync function, time, data idp and besides the skywalking. We are also planning to add open temperature as another tracing provider and also we are going to support the uh function, console the service workflow in the future.

A

So this is the roadmap. Next I have two demos. uh I uh I have two demos here, but for the time reason I only demonstrated the second demo the first time. I can explain it a little bit.

A

Actually, you can use flame base to forward the combination log to kaka server and we can define async functions to consume the log from the kafka server and whenever the async function find the error, it will send an alert to the slack. So we can take a look at the function code and definition.

A

So the logic is uh pretty simple: whenever the 404 error is fun in the demo product name, space for port worth price, whenever, whenever the uh this three condition, matched the learn, manager alert will be defined and will be sent to the notification manager and, let's see how the function cmo.

A

This is how a function is defined. Here you can see here is the build stuff here. Using these settings, a user can build the function source code into a container images.

A

I can see the runtime is async and also the skill options from cada, I can say the main replica or max replicant, the cooldown area. So how how the skill will behave like this most important? This is the kids trigger how the function is triggered. The function will watch for the launch topic of this kappa server and whenever the consumer lag is over 20, we will increase our replica.

A

Yes, you can see a function has input and output and the input is from the cable cast receiver, and this is the table component defined here you can see. This is the the topic that we are watching for, and the copper server and consumer group etc um the output. Whenever the error is found in the function, it will send the output to the uh notification manager. Here you can see, I suggest a url, so this is the first demo.

A

um I will not do an actual demo, so let's go directly to the second step. This is the tracing example, send sender, request to a sync function and choosing a trigger async function. Let's take a look at the function code.

A

And see here it has the same signature context and the payload you choose the payload here and whenever the payload is retrieved from the hp request, it will assign the payload to the uh update upgrading target.

A

um Let's take a look at the functions yaml. This is a sync function, so this is the build part how the function is built.

A

The scale options the how many uh max replica and the runtime is that canadian, because the input is a single function, they input it from the http. So it only has it's only defined the output. The output is a calculator uh similar to the previous one. The calculator is uh defined as a table component here, and this is the canadian stuff.

A

So this is the first function and the async function. You can take a look here.

A

The calculate input here is the async function uh code. It has the same signature here. You choose the message from kafka and that's the the message. So this is the async function. How the look how the async function is defined same at the build staff and the runtime the async, the cadence skill options here are the same the same and trigger it will watch for the simple sample topic here from this kafka server, and this one and the html5 only has a input at this time.

A

The encoder is also a different component defined as like this and I'm putting just the seoul. So it's needed to be different here. So let's take a look.

A

I have already defined the functions here you can see here. This is the sync function. This is the async function. I can also take a look at data story.

A

Serving is also up and running and we can watch for the uh this is the this is the async function. uh This is the sync function. They both scale to zero because there are no payload here. So, let's trigger that trigger some payload on the sync function you can see here. The sync function is starting now the sync function is starting now, let's call star and take a few times.

A

Async function already start now, so we can take a look at block.

A

Async function is starting now and receive the message. Finally, so this is, uh this: is the demo okay.

A

Next, I'm heading over to zooming and zooming into your series.

B

Thanks man hi everyone, my name is jumin lu, an architect from uc and I'm so happy to share talk in cubicle. The topic I share today is in power of enormous driving with cloud-native service technologies.

B

Next, thanks in recent years, the autonomous driving field has been growing regularly and attracting a lot of attention. Cloud native came to maturity and prosperity in the same period. It is natural for these two fields to join forces and explore a route for cloud native during power autonomous driving. I would like to start my presentation by giving a brief introduction to autonomous driving here is a simplified demonstration of autonomous driving interaction where users apply for a car from the app take a car to the destination and finally get off in this classic and simple process.

B

From the user's point of view, it involves vehicle monitoring and the commands dispatching within authority framework from the perspective of the vehicle. It involves a series of ai technologies such as environmental perception, pedestrian avoidance, youth planning, two things, control, multi-vehicle cooperation and so on and in the cloud we need to ensure high availability, error, traceability, scalability security for our services and materials.

B

Next, we will start from the specific, a specific perspective of cloud agnostic agnostic, fast to explain why autonomous driving needs cloud, agnostic, fast platform.

B

First of all, cloud agnostic, one of the core technologies of autonomous driving is artificial intelligence, algorithms and the reliance reliance on data for algorithm enhancement improvement is so high that the data has a high value and customers are often reluctant to put data in the public cloud and instead build their own set of private cloud clusters.

B

In addition, the flow domain cloud providers and infrastructure choices bring challenges to the upper layer of development development. A cloud agnostic platform can make developments smoother and save significant cost costs in the face of different customer honored server environments and constrained vendors.

B

The second fast, an autonomous driving worker, is essentially an extremely complex iot device, with numerous types of sensors and suppliers resulting the need for multiple parsing scripts and extremely large number of processing modules handled by multiple development teams, leading to the introduction of different libraries and even different programming languages.

B

This poses a set of text where modules need to be merged and refactored at a later stage. In addition, the amount of autonomous driving data is far beyond the reach of traditional ite iot devices, and the streaming analysis of large amounts of data requires a tube that has great scalability.

B

Finally, the rapid development of autonomous driving also means that the logic of data processing changes frequency, frequently based on rapid, changing industry requirements, different weather sites and business models requires different processing logic, and we expect to find a fast played way to replace the computational logic at a small granularity instead of modifying one line of code and requesting time to produce a 4ci cd for the entire service, which always takes the day.

B

In conclusion, we expect to have an open source fast platform based on cloud native technologies, for us to quickly get the solution of the ground, to have control over the platform itself and to enjoy the convenience of cloud native technologies.

B

At this point, open function came into our view and introduced darpa and kida as part of its foundation into the consideration. Next, we will talk about why keta matters automatic scaling is an efficient allocation strategy for resources, often acts in acting in scenarios where data traffic is erratic, which is exactly what autonomous driving needs.

B

Autonomous driving can also be understood as an ai driver who replaces or receives the human drivers to do the job and thus, to some extent it retains the work habits of the human drivers, resulting in a potentially significant peak and valley effect on traffic. In the dialogue on the bottom right, we can see we have a range of different work patterns for the driverless vehicle according to an eight-hour workday. In some scenarios, the driving taxi is only one part of the customer's business, so there's no need for the vehicle to work 24 hours every day.

B

In other scenarios, the vehicle needs to work 24 7, to maximize its capability. This brings significant traffic differences. Autonomous driving sensors tend to maintain a high frame rate of data. Increased station for safety and later, like sensors, generates a large number of data. So a small change in the number of vehicles can also bring out a significant swing in data traffic, and next we will talk about why double matters.

B

We have already mentioned some of the cross language requirements due to the many data types and processing modules, as seen in the sketch in the lower right. We, where the data passes through many modules in the car to cloud link and as we talked about next dapper, is also very attractive for decoupling.

B

On one hand, the choice of midwest is often limited by the customers and, on the other hand, with microservice architecture. The code of establishing connections with midwest handling errors, adapting to different patterns, is written over and over again. Diapers binding can solve this problem by abstracting into a unified specification.

B

Shadow devices are an abstraction of physical devices in the cloud, and the code often uses shadow instance tensors to complete the monitoring and control of the actual devices and generally generally uses and exec synchronize the architecture to hand to handle side effects for performance reasons and the darpa's pub sub wrapper can also cover these used age scenarios.

B

Next here is an example of next. Please here is an example of using open function to solve a real world problem in the autonomous driving field. Archiving data with open function within a customer's private cloud environment. The functions in the diagram are all service functions that we have written and deployed in a cloud native fastplace platform like demo shows in this workflow.

B

The chrome drop of http requests are received as inputs and then passed to the first function, which splits the task and deliver subtitles to the message broker for driving other functions, which are responsible for handling, specifically subtext, written in different languages.

B

Those functions receive data as input in a byte array form provided by the fast platform received data, including contacts, the info and the subtask description, and then push a zip package to the s3 service. After data collection data masking and data compression and finally exit, it no need to pay attention to the middleware connection, no need to unify the language. It is convenient for each function to use the most efficient, open source library and, like programmers, finish their job as a mini level.

B

What is more, when data traffic increases keta automatically scales up function, instances based on the amount of data in the broker backlog, allowing developers to focus entirely on logic implementation. At last, we will talk about what is expected from a cloud analysis fast platform. We would like to have the following features: first, tracing and logging and metrics new data needs to go through hundreds of modules and a dozen network communications before it can be archived in the cloud and errors may occur in any step.

B

Troubleshooting is one of the most important problems in the development of an autonomous driving system. We need to create an unified tracing mechanism within a complex core chain, because efficient observability mechanism saves time and money robust system. Efficient error handling are important aspects of getting autonomous driving on the ground for the safety requirements, the second plugging mechanism and the package management. This is an important feature to make the platform more powerful and easier to use the third alternative underlying technology and easy to use interface wrapper.

B

The former ensures that no upper level development will be nullified due to dependent technology replacement, while the latter ensures the efficiency of upper level development last, but not the least active and efficient maintenance team. Currently, the cloud native serverless platform is in its early stages and needs a stable and active maintenance team-like of a function to make the community more prosperous and to make better open south products.

B

That concludes my presentation. Thank you for your time.

A

Thanks to me, I think uh that's all our sharing. So uh if you have any questions, you can ask us online. Okay,.