 Hello. This is Bin from AAC. Hey, Bin. Good morning. Yeah, let's give it another couple of minutes for people to join. All right. Looks like today we may not have a very large audience. Yeah, thank you for joining us and excited to be here and hear about your project, ThoughtFlow. We want to learn more about it and how that fits into the cloud-native ecosystem. Yeah. Then we're happy to learn and this session is recorded too. So for somebody else who wants to come in later, they can actually see it too. So yeah, go ahead. Okay, so I can share my screen. I prepared a few slides. So I would like to go through the slides and also have some discussion with all of you. First, thank you for inviting me to this session. Also, it's my pleasure to introduce what I have been doing in terms of ThoughtFlow. So today, yes, this is a project I have been working on for many years. So it's really my pleasure to introduce this to you. So ThoughtFlow, it is a... You can call it the age computing framework or for computing framework to support IOT applications on top of this cloud and age environments. So it has a special kind of capability to support applications with advanced programming model and also it is a runtime system to support such a programming model and also to optimize the deployment of IOT services. So I will give a little bit more detail. So let's start with a little bit of background. So I have been working in the lab for this project for many, many years. So I'm from AAC Lab Europe. We are located in Heidelberg, Germany. We initiated this project nearly four to five years ago. Right now, it has been an open source project based on the prototype we built before. So we are from IOT area, which means so we collect data from sensors and do some data processing and then derive some timely results, situations, so that actuator, which is also device can react on the results. So the major thing we did is to be able to run such data processing in between the sensors and actuators. So in the old age, this type of data processing can be supported by different type of big data processing frameworks like Hadoop, for batch processing, Spark, for stream processing. Nowadays, Flink could also combine both with the unified programming model and everything works very well in a cluster environment. That was the way we do before. But nowadays, since the system architecture also changed and also there kind of for requirements in terms of for latency and also privacy and the cost in order to support large scale IOT service. So we have to adapt to this type of new requirements and also adapt to the new environment. In this environment, we call it cloud age environment that means it is highly distributed and also have this hierarchy with different resource computation resource, including resource in the clouds and some computation resource located at IOT gateways. That can be deployed on the street or in the factory. So with this kind of for highly distributed architecture, in order to deploy IOT services, we are basically facing two type of challenges. So the first one is to program kind of for such IOT services. First, then according to that, we can easily deploy them to this highly distributed infrastructure without having too much management complexity. So what we did is to improve or to overcome the complexities of from both sides. One is to have this easy to use programming model we call it internet-based programming model to program age applications. On the other hand, to have some kind of efficient framework to be able to manage the task to first translate the programming model into concrete deployments, plan and then also optimize the plan without having too much involvement from the users or system operate. So that are two type of focus we do in workflow. So there are a few principles that we try to follow in our design. By the way, if you have any questions just interrupt me so we can have some discussion. So there's few kinds of principles we try to follow in the design of workflow. So the first part is we try to decouple this kind of computation logic, how we represent the service, the design phase, and also the deployment requirements that we may face at the wrong time when we start to use the service. So that is the decoupling strategy we try to follow and there's some consideration behind this principle because for the same kind of service which may be a same pipeline, but the way to trigger this pipeline may need to be different according to how we use it. For example, if we use it for simulation kind of cloud environments, we may not care about too much about the latency. So we may want to just reduce the cost to use the resource for doing that. If we trigger such service, some pipeline for some kind of for device, then the time may be important, we like to get this result as soon as possible. So that's why we kind of separate out this computation logic to represent it as a kind of for graph which consists of multiple data processing units, each one we call the task. And then on the other hand, we have this kind of for deployment requirements, we call it intent. This basically represents how would you like to trigger such computation logic from different perspective like whether you want to trigger that for a large amount of data or small part of the data, or some kind of for service level objective you would like to achieve. So I will come to that soon as later. So this is first principle in our design and second principle we try to make the data visible. The data between tasks. So in like Spark, Hadoop, the data is basically it's not only to the specific application developer, but it's not open to everyone to share. So that means this inter-probability and also capabilities to share the task or the data processing logic is a limited because you don't know which type of input data you need for the task, which type of output data that could be produced by the task. So we try to make them kind of for standardized based on some common data model so make it visible to share. And also, around time we try to leverage this type of information for the authorization of the application or the service. I have a question. So the intent basically the way you compute the steps on a DAC or that would be, okay, so that actually means the trigger too, right? So the trigger happens at the DAC level or happens at the intent level. The trigger for the computation. Yeah, yeah, that is the trigger, including some kind of specific or customizable requirement, but this intent is a trigger. Got it. Okay. Thanks. And then, yeah. So in terms of programming model that we follow the same way as this Apache link, that's trying to unify the programming model for different cases, especially for this data incentive, intensive or I will do services data oriented application. And then internally, we try to optimize this runtime deployment is regarding to with regard to the high level service objective or constraints like optimize everything based on in order to minimize the cost or in order to minimize the latency, or even for machine learning application you may consider to cover some application level requirement in terms of accuracy. This is still ongoing and try to optimize the pipeline by taking into account this application level requirements. So, at very high level, you can see that for flow is a runtime system on the one hand provide some interface for application developer to structure their applications. And based on our intern based programming model, basically to define this computation logic as a graph, and then by taking that into account, and then with this intent as a trigger, then this a workflow runtime system try to decide how to construct the the instance of the task and then how to conflict the task and the way to deploy the task. In the end, we consider several type of for context, including the system context, we available three resource in the overall system, and then data context, because we make this data visible based on some common data model. And then we also know exactly which type of data available at which place. So this type of for metadata is also taking your account for the orchestration task. And then the usage context is what I mean by intent. It's from the users perspective how they would like to trigger the task. So we consider these three type of context to orchestrate this application over this distributed environment. I think this is somehow yeah self explained. So, as I explained before, we have a graph because service topology, which consists of multiple tasks with some data dependency. And then later, this can be triggered by a defined intent objects. And just to mention the task, actually, the task in the graph refer to operator operator is a docker application, which can take certain input and then do some data processing and then produce some output. The task is just try to annotate this operator in the context of service topology. And then come to the point about intents. This is just a data structure, but to represent covering different part of for requirement like you define which service topology will you like to trigger. And here's a kind of geoscope to fit out the data, you would like to select and put into this computation logic, and then service level objective. This represent from different perspective where the basically is your optimization objective to run the task defined from the cost perspective lentence perspective or this accuracy perspective if that is about a machine learning pipeline. This is the priority of this task for using the resource in the overall system. Yes, so then let me give you a little bit introduction about the system itself. This is a layered view of full flow system. So the top layer we have some interface or graphic user interface for the users to define service computation logic, which is the graph. And then the management layer basically is the core is the server topology master topology master make some decision based on the information come from this discovery because discovery and broker they are the core component for the data management layer. So data is will be managed by different broker at each age, and then reports, which type of data can be available at local age report this to the discovery and discovery, give this information to the master for making decision. About how should, how, how we can plan the computation tasks like basically figure out how many tasks we should prepare for each for many instance we should prepare instantiate for each task in that graph. And later then decide well to deploy. And then once decided to do well to deploy then tell the worker to decide worker is basically this to exclude the command to auto serve to to launch the task. And then the lower layer is the data source layer or some device layer, which basically produce the data to the report to the system but also consume data produced by the task, the data processing tasks in the system. So this may be more concrete than that layered view. So basically, in terms of department we have what we call a full flow cloud notes. And this is kind of centralized part, including all the core services we need for the set up for flow system, including this master for making the orchestration decision and discovery to report availability of the data in the system. And also, this cloud node can also partially be age notes, which is more powerful with more resource but normally this age note located close to the users, like, like IOT gateway. For that, so on the age node we have only two components, one broker and one worker broker basically manage the local data and worker receive the commands from the central master to decide what to do for launching the task and configure the task. And overall, there's a if I get come back here here they are kind of basically two major channels. One is for this data management channel between discovery and broker on the other hand, it's the control channel between master and worker. There. So for, for that we have, yeah, we try to separate out because combined and we may have kind of for buffering issue to propagate this commands in real time, as fast as we can. So we separate two channel to make this control channel to be more efficient and fast. In terms of data management in folk flow as mentioned before. So for each age node as a broker to kind of manage the local entity data, which represents some states or device or just represent the entire IOT device. And then the central discovery just index all this availability of the data. So, just one of the unique thing is the data we kind of follow a standardized data model in this was in the context of five well, as a European community for IOT system. So we define a standard as data model is called and just I but it covers two parts one is this and just say nine for managing the metadata part and just 10 for manage the full entity data. And those provides pops up interface. So for flow is built on top of that. In terms of the last part how we orchestrate this orchestrate the service. Yeah, so basically this graph is given by this application developer. And then after receiving a trigger which is intent, and then the system start to figure out how to generate this execution plan, which consists of for the concrete instance of each task and also this concrete configuration in terms of which input data to put into which task and produce which type of output. This execution plan is just also a graph. Then the last step is to decide how to split up in this graph into different parts so then we can deploy them to different age notes. This will be done by the workers, but to figure out how which task goes to which age note this is done by the master in full flow. There's some optimization objective in terms of how we achieve this service level objective, for example minimize some kind of cost of doing internal data transmission or provide the minimum latency between this sensors to this and actuators. So this optimization objective will be set up by this intent. Yes, then that is some key part of the right. Yeah, so you have the execution plan in that that is actually running in the cloud system. Then that later that when that gets computer and basically gets deployed or, or creating a deployment plan and the deployment plan in the cloud system and then after that's created, and it gets actually deployed in the edge environment. This is an execution plan is calculated in the cloud. Okay, then that will be split up and then deployed. So this deployment plan is actually also calculated by this optimization algorithm in the cloud and then just executed by the worker. So what we just passively receive what to do. Okay, got it. Yeah, so this is a right now this is the open source version. We know that there's a bottleneck in terms of for calculate this execution plan and also figure out how to deploy with this is down in a centralized way right now. So that's why no, also, we have some kind of distributed version to do this authorization decision in kind of for distributed manner. So that is a more advanced version that we haven't really released to this. Yeah, question would be like something like the execution plan and the program plan could be maybe run something like Kubernetes that you could auto scale right like if you need more capacity to create that execution plan you can provision better on demand right. Right, right. So that's, that's correct. Here, it's kind of one layer on top of for Kubernetes, but definitely to deploy this deployment plan, we can leverage to Kubernetes as well like try to deploy this. So right now we just integrate with stocker engine directly. But for the cloud node definitely we can benefit from Kubernetes because we don't flow doesn't have to manage this resource in terms of container so the, the orchestration of container this can be managed by Kubernetes. So, only we do this calculation how to figure out this execution plan once we figure out that we can rely on Kubernetes to, to, to carry out this deployment plan, but the optimization is still done in for flow. Yeah. Thank you. So, on another question about this slide so you have the graphical editor on the left side. Is this part of Fox flow or this is. Yes. Okay, so you can create like your dependency graph and everything using Fox flow. Right. And also we have a graphic user interface to do this. So, right now you have to manually input this data type or so in the next version which I have to introduce a kind of type management system because info flow the data model is standardized. So we, we, we know what are the types of data types we have. So we also manage that so indent and then later this annotation of your task in the graph will be easier to define by using this maintained type data type system. Thank you. Yes, so after talking all of this here's a yes more simple example, we call close child finding. And I know this is a for sure a problem maybe in us because of privacy. It was a use case. Come up with by by business unit in Japan and see is a Japanese company. The scenario is to identify a lost child in big event like Olympic in some area which has many different studios located. If the child is lost and then the parents can ask help from the staff member and the staff member can never this age computing infrastructure to find out the child quickly because many cameras and age gateway will be deployed different location. In this area, and then we constructed a sample application logic. This is a service topology, but has only one task, which is a face matching. The task just take the image of lost child provided by the parents and look at the video stream from each camera and then to match that with the image of the lost child if it's identified from the video that it just reports. And this task will be instantiated. A different location, according to where the camera is located where this age loads have been has been deployed in this area. And to trigger that we need to define an intent object to say. This service has the highest priority. We like to achieve minimal latency for doing this. And then the system will understand even occupied all the resource to do this highly urgent task. And then another question so this, this will happen in real time basically to specify the intent and then you will schedule that to start doing the face matching and then, and then look around. So all the edge notes that have cameras right to try to do that face matching. Yes, it's more less like that. But if you remember, in the previous slides, we have also a scope, which is part of the intent, we can define select a specific area, which is the scope in this intent. Then we exclude this service for that scope first. And in this case, the scope will be what just to just an area in the on the map. Got it. So the normal development process for folk to to implement the full flow service will be like this, because that's basically maybe I can skip this because here is more easy to follow. So there are three main elements in order to program for flow service. First, which is this operate. So in that specific scenario is this face matching data processing unit. This need to be programmed as a docker docker application. And then we register that register that to the system as a reusable operator. And then second step is the application developer basically to use the graphic interface to construct this graph by linking multiple tasks together. This design phase is finished and then come to the operating phase and then whenever we stand with define your intent and then issue that intent to folk flow system, then we will be able to trigger the folk flow system to deploy a survey. This deploy the service for what you have already asked in this intent object. So these are main three step to do. So for implement implementing our operator we provide different temperature for different programming language, but the core part is just to implement this function. For the developer of the operator you don't have to care about the other part only to say you have you will receive this type of for input data, and then perform your internal data processing logic. If you have some data to report back to the system, and you can use the publish and callback function to publish the result back to the system. The other two optional if this input data provided by folk flow system. It's not enough you need to query or subscribe some extra information then you can use the other two functions, otherwise it's not needed. Sorry, questions here so so this pattern can be also be used in maybe several less type of frameworks. Yes, you're definitely right so I didn't mention here because we also have a simplified programming model which is called folk function, but the folk function is a special case so for one service service topology which is very simple contains only one task, plus a default intent this default intent is just to do. Like to do this for the entire system scope, and with always minimal latency. So that is a special case but the idea behind this is like service computing, you just need to implement this function then. Function will be deployed whenever the data unit became available in the system. It's also slightly different from the traditional service funk computing because here the triggering it's only based on the availability of the data we request. In the traditional service computing, you need to have an event this event can be a HTTP request, which provide the input data, or can be some storage system so which is more kind of generic and in folk flow case. We borrowed the idea of service computing but it's a little more specific to data oriented and only trigger that when data you required became available in the system. Okay, so that is her and then the second step is to define this service topology as I mentioned before we have this graphic user interface to compose this graph. With multiple tasks together. And then we also provide this user interface to define a service in this intent, which right now cover this different perspective, this polygon is to specify a scope to trigger this computation logic defined by the surface topology. Yeah, those are main steps three steps to to work out a folk flow application service. And right now this we have a detailed tutorial provided by this link. So if you are interested you can get more information from here. Also, now we are kind of for support the community of the folk flow users. There are some kind of adoption happens in both academia and also industry. For example, there's some provider of gateway provider. And they already designed this hardware, which already have folk flow deployed on the board. Yes, so we got another full request from researchers from different university because they figure out folk flow is easy to extend for different idea, especially some optimization of this orchestration for data oriented applications in this cloud edge environment. So, overall, we are kind of promoting the folk flow in this five year community. I mentioned a very beginning so here, I have a little bit more to say about community of five well it is mainly driven by this European countries for IoT in general, including in different areas next many smart city and now also smart industry. So what we do in this community is to have this ecosystem open source ecosystem to support IoT in general, as you see in this diagram show in this community. There are so many different open source projects. They maintain developer components for different futures like for management for data management interface with devices and for security and for data processing visualization. So for flow is one open source component in this chapter in terms of data processing. We also have kind of promote business together with all the other partners in this community. In terms of research, by looking ahead so we are currently extending this orchestration to have a distributed or we call it autonomous orchestration means this orchestration not just carry out in the clouds in a centralized way but can be carried out distributed by the local age as well, but they are able to collaborate with the other system. And compare with the other existing like each computing framework or for computing framework as for flow is kind of more data oriented because it based on a standardized data model we could end your side. Because of that, it has an opportunity to support kind of data sharing platform. So here we are also exploring using support to support secure data sharing platform. Among different enterprises. For example, they can also enforce how different users can consume the data based on some kind of data usage control policy. It will be a federated setup of workflow, but we also extend this intent to cover the constraint of data usage in different scenario. In the long term we try to as kind of for cover this application level requirements, like machine learning task in terms of accuracy so we can also optimize the pipeline. With regard to this accuracy of machine learning pipeline task. Here's a summary. Yes, I did I mentioned the overall design principle for flow. And also introduce some of the key parts like this intent based programming model and orchestrating the service based on the defined intent and also some way to do this optimization according to this defined service level objective in the intent programming model. As there's a community for workflow we try to support it with our best efforts. Hopefully, we can leverage for flow to support more application in both in 5G area for future application or for AI application in this context of data sharing platform. Yeah, that's all from my side. If you have a question, we can have more discussion. Thanks. Thank you for the presentations. It's very interesting. Yeah, I have a question about the, the future in terms of deployment it. Are there any plans to have some sort of reference architecture around Kubernetes and deploy some of the workloads and I mean at the edge and also in the cloud running on top of the client. It is a in our short term plan. So right now, this integration is only based on Docker engine. One, one of our ongoing task is to replace this patch with a Kubernetes API. So, especially for the cloud node path because then we, we just rely on this Kubernetes setup, then to launch part of the deployment plan. If we'd say this part of the deployment plan is to be carried out on the cloud node on the cloud path, then this will be done automatically by using Kubernetes API. So then we don't have to worry about like reliability or restart the Docker when there's something wrong. So this will be very well supported by Kubernetes. This is the, the cloud node part, cloud part, but the age part we consider to use this lightweight Kubernetes is called K3S. We are just investigating whether that is that provide a similar API as the official Kubernetes. Awesome. Yeah. Yeah. K3S is also a CNCF project. Yeah, I have another question about the secure data sharing platform. Is this going to be a hosted service as a platform or this is going to be more of a software that people could run and basically, you know, set up their own data sharing platform maybe in a federated way. Yes, basically we're being a federated environment. For example, you know, in Europe, people talk about this, this IDSA is international data space. There's a big kind of construction about this. Also, about the, like this guide X, which is this cloud computing vision of Europe, because you know Europe is quite fragmented. So this infrastructure is also need to be federated. So in terms of this data sharing platform, we are thinking that so different company or different countries, they will be able to host their part of this data sharing platform. And then there are some kind of for process data to authenticate who can join this kind of for data sharing platform and how they can communicate with each other. So right now because there's no kind of for agreement about the common data model between different hosted system. So it just, then people decide to go to this up level. So this interoperability between different hosted platform can be based on semantic. This is a much higher level because there's no need to say what Pacific data model you need to have as known as this data is can be represented as a meaningful, meaningful way like at the F or some kind of semantic related technology. So it's a result of form, because it's hard to have a common agreement on the Pacific data model is also competition between different companies. So for flow can play just one role because the other company can also provide kind of data sharing platform as not as they can get certificate from this this conversion. So every company can can provide some kind of implementation for this data sharing platform. You know, I think one of the things I thought about was the data privacy. So they have some, yeah, some kind of regulation. So basically this organization should be able to check which type of security or the usage control you can provide when they start to check your system and give you a certificate they will check whether you can provide this type of privacy guarantee or death level so they have some kind of bring a blueprint but it's still ongoing because carry out this in practice it's actually not easy. Yeah. Cool. Anybody else has more questions ago we got Alina so I wanted to thank Ben for for the awesome presentation and a very interesting use case of all those child and happy to see that the project is considering using Kubernetes and K3S as a back end K3S has exactly the same API as Kubernetes so shouldn't be any compatibility issues. Yes, we are also very happy to really integrate with Kubernetes. Because we see that has really generating big impacts in the community especially for cloud computing. And we see, if we move for flow to a production level, then we have to integrate with Kubernetes. Yeah. So I have a, I have a question here. So what is the, I'm not very familiar with CNCF overall. So, what is the this general interest of different interest group in under this cloud-related computing foundation. So, your question was more about this, the runtime or some other interest groups. It's just for this discussion and to know this latest progress, or do you have some specific targets for each interest group to I think the, the main roles of the six who are part of the TOC sort of like an extension of the TOC. The TOC stands for Technical Oversight Committee and Lena is one of the members of the TOC. So, the TOC makes decisions about projects that want to join the foundation and then also sets a framework for these projects on maturity level, whether this project is entry level, more like sandbox or like incubation or more like there's the level, the highest level is graduated, which means it's widely adopted in the industry and has a certain number of users. So, they set up all this framework for projects and also to work with the communities and how they can grow them and how they can get more adoption. Yeah, and then so the six are an extension of this TOC and so there's a sick runtime, there's a sick observability, there's a sick application delivery, so for different areas. So, this is just sick runtime, and it's mostly about workloads in the cloud, Kubernetes is in the scope and the sick too, but there are some other projects like AI type of projects or container runtimes. So, the goal is to engage in the communities. So, we have these meetings every two months, or every, sorry, every month, twice, so every two weeks. Yeah, and engage the community so they get interested in the CNC projects and start using more of these projects. Some of these projects also joined the foundation too. So, the idea is to engage also other projects where we might have gaps in the cloud native ecosystem. So, they might want to join the foundation too and then so we're happy to help see that aspect. Does that make sense? Yeah, thanks. Thanks. Thanks for the introduction. I'm quite new to this community. But yeah, to be honest, I think this is really very cool community that we see it's growing very fast and moving fast. Yeah, yeah, so we're happy to have you involved. I know you're part of Fireware, so I mean, you're part of the community, but it's open source so anybody's welcome to participate and contribute and get engaged. Okay, great. Thanks. Also, yeah, thank you for the invitation. We were really excited to report for flow here. Yeah, we're glad that you decided to present and happy to learn and hopefully you'll get more, you get more adoption and also the space actually keeps on growing. All right, so yeah, have a great rest of your day and yeah, see you next time. Okay, yeah, thank you very much. Yeah, bye bye. Thank you. Bye.