 Γεια σας, ευχαριστώ για να είμαι εδώ. Είναι η τελευταία πράγματα της συνεργασίας. Ευχαριστώ πολύ για εσένας, για όλα τα δυνατότητα που έχετε κάνει, και ευχαριστώ για Δευγκόνφ. Έχει been really amazing. Είμαι στον Σατερδέ, δεν ξέρω για εσένας ότι έχετε been here from Friday, you know, you are heroes, that's, I mean, it's great. Ok, so, I'll try to present to you some things that we have been doing in an open source wide project, in a European project that we have been working on. So, we are going to talk about Edge Cloud Continuum, we are going to talk about Serverless, and we are going to talk about how to design fast applications in visual programming flows. Ok, so my name is Jens Georgiou, this is a presentation that we have done with colleagues from Harokopio University, George and from Red Hat Louise. And this is an agenda for an initial agenda, so we are going to start from a high level view of the physics project. We are going to talk a little bit about the details on the design environment, how this is done, and then we are going to dig a little bit deeper into how the infrastructure services take place. We'll see some performance aspects and then we are going to discuss some optimizations we have been doing in terms of placement and scheduling. Ok, so a physics project is the acronym, so the real name of the project is Optimized Hybrid Space Time Service Continuum in FAS, FAS as Function as a Service. Some of the main challenges that we have tried to target with this European project, so we want to abstract the usage of service offerings, ok, service offerings and clusters across the continuum. So when we talk about continuum we talk about ads, cloud and premise clusters, and when we talk about service offerings we are talking about how to design applications in this type of environments, ok. And now the users are not always experts, ok, so that's why we are talking about abstractions here. So there could be data scientists that have a specific expertise on how to create artificial intelligence applications, but they might not know how to actually deploy them, and even more how to deploy them in a complex scenario with edge cloud clusters. We are talking about one of the challenges is the adaptation of code in serverless computing paradigms, ok, so I'm sure you have heard of there are open source serverless platforms, there are also service offered in the cloud. Here we have taken a particular open source approach. One other challenge is the investigation of space and time, ok, space in terms of location of execution and time in terms of duration of execution. These are things that we try to tackle and again taking into account the whole continuum, things are much more complex. Optimization of resource selection and operation, so we do have different levels, the global level taking into consideration the whole continuum, the different clusters in parallel, and the local level when we go and execute directly upon a specific cluster. And finally how to reuse new artifacts, how to reuse the particular channels and artifacts that we are going to create. Ok, the goals of the project visual programming environment to create workflows with patterns that can be reused with semantics that can be increased and how we can facilitate the developers, how we can enhance the development experience with this type of environments. Platform level functionalities that will allow us to orchestrate in a clouded interplay and more provided local resource management in order to be able to offer specific optimization while we execute the services. Ok, for those of you that aren't aware, Europe provides funding for projects and this Horizon H2020 project, it is a research and innovation action with a project budget funded completely for all the partners that have been participating to it. We are 14 partners with large companies such as GFT, ATOS, HPE, Red Hat, Fujitsu and smaller startups like Bytrex Technologies and finally universities like Harocopio and UPM from Spain. GFT is the project coordinator and the end of the project is actually end of this year. Ok, so we have passed all those phases and we are now in the final implementation phase of the second iteration. Ok, this is a high level technical architecture of the project and actually for those of you that don't know, we separate it into different work packages and as you can see we have these are the technical work packages. There are some others that are more related with how the project is managed or how the exploitation is done. On the technical side we have the user layer, the design environment and function DevOps phase, it's the higher level of the schema here. Then we have the global continuum layer where we have all the platform services. You can see here that the T represents the different tasks so within the work packages we have specific tasks that will come and tackle particular functionalities or services. Once we have the different services on the platform layer along with the semantics, the way to optimize the placement across the different clusters, data services and the orchestration. We reach on the lower level, the local level of the infrastructure where we do research about the ways to do resource management, placement optimization in the level of a particular cluster, either edge or cloud. We have different pilots, different applications, large applications with real conditions. The first one is related to smart manufacturing for increased resilience and interplay. We are talking about industry for the whole scenarios with edge and cloud trying to be as resilient as possible. Each health scenario with artificial intelligence and predictive scenarios where particular data coming from specific patients can give results and predictions on how they can be treated. Finally smart precision agriculture where we take into account digital twin scenarios and how we can take into consideration different characteristics coming from smart farms such as how we can better control and take into account the resources. For example, the water, the pesticides that are used and how this can be optimally deployed within the smart farm. Now if we go a little deeper into the physics environment, first of all what we wanted to do with the design environment is to enhance, abstract and then reach the way someone will create its fast application. How we can customize the function environment, we gave the ability to the user since this is initially something that will be installed on their PC to customize it as much as possible through docker files and stuff like that. We simplified the creation of complex functions workflows and this is for people that already have used serverless or fast, you may have noticed that for example in lambda you will need to go through a big YAML file in order to provide the different characteristics of the functions that you need to implement. In particular we have cases where you may have applications composed by more than five functions so things start to be complicated and imagine even more if you need to do some joints. With a visual environment this is something that we tackle here. You can see in the right here that it's much simpler to actually do the programming like this rather than that. We exploit reusable patterns, these are things that I'm going to discuss afterwards, increase semantics and also we abstract completely the packaging, the testing and the deployment. Imagine for users that do not have these capabilities, that are more experts in coding, if they need this to be abstracted this is a feature to use here. These are the baseline technologies that we have been using so no dread, I don't know if you are aware of it, it's an open source programming environment for event driven applications. We have taken these assets and we have enhanced it with a specific palette of annotations and particular extensions that can actually facilitate the user in execution upon the continuum. I'm going to talk a little bit afterwards about specific extensions. No dread can be used in this context as a workflow orchestration but also with function execution abilities. It can also be used as a choreographer for specific functions. You can either create your flow and build it as an image which will be then deployed or you can enable the execution of different functions, physics functions directly from no dread. In parallel we use OpenWisk, the open source fast platform which allows us to actually deploy upon Kubernetes clusters the images that we will prepare directly through no dread. This is the design of the local and the cloud environment in terms of the life cycle of the artifacts. Initially what you get is three containers that are deployed within your local environment and as I said the no dread comes as it is and then we have specific patterns and annotations that have been enhanced by physics but we do not break the compatibility with just add those within the palette. We have the control user interface and the serverless function generator which actually provides us the bridge towards the cloud environment where we have the backend which enables us to take the code from the repository, upload the flow to a bucket and eventually trigger a Jenkins job with the flow which will in the end prepare the artifacts to be deployed by OpenWisk. This is the user interface that we can get from physics so through that you can have the function creation, the build management, the testing, logging etc. There is a video if we have time we can check it afterwards but I will go through some of the characteristics here so we have the view of no dread directly with all the different annotations and patterns that we can use. By default the language where the different patterns are programmed in no dread is JavaScript but in particular since there is the support of docker images we can actually have different types of languages directly there. Afterwards once you have built your flow within the no dread environment you can come and check the build that has been done directly from the admin panel of the physics application. Here you can come and invoke a particular execution which will then send it in the according cluster to be executed. There is also logging information taking place directly within the environment of the physics application and you also have the ability to connect different flows within specific applications. For example if you may want a particular part of an application to be executed on the same cluster this is something that you can do. What is interesting with physics is that we managed to enhance the different capabilities of no dread with specific patterns that are usually used and demanded in the case of more complex applications. Applications related to machine learning or applications related that need to be executed in a parallel mode in a multi-cluster environment. So these are things that by default were not treated within the no dread but we have enhanced it for reusability, manageability and abstracted functionality. So as you can see here there are things such as parallelization, I'm going to talk a little bit afterwards about that with a split joint scenario. Things such as context management you may need to have a specific action, a specific container that will share the context with another container being in the same. Being in the same flow. So this has been created in advance or things such as how you can create a retry scenario when you want to save data within an object store. Stuff such as request management or branch join these are things that have been introduced within the physics palette and because are used and demanded in a more complex scenario. So in the case of the fourth joint parallelization this is quite interesting because as I said we start from a concept, the concept of how we can start, let's say we can have an array of inputs. Then we split this function into multiple functions, we have the fast invoker that will come and will deploy a number of containers based on this split and in the end we have functions that will join with aggregate all those results. And this concept here is implemented by this complex flow which is then created as a single function. So in the end when you want to use it you just need to drag and drop this particular box and the user just needs to parameterize it in order to have the result we implemented here. And this is something that is actually quite used especially in complex cases such as machine learning or where you want to improve the performance of a particular execution. And we have also different capabilities here such as you create different functions or you may create different threads within the same functions or different processes within the same container depending on where you are executing. Okay, other semantic nodes that are interesting to mention here is things such as affinity and the affinity. These are things that you may use quite often in scenarios where you have sharing of functions within the same nodes or you prefer not to put them in the same nodes. Locality of functions you may prefer that a particular part of your application is executed at the edge if you have data privacy issues for example or that a particular part needs the cloud if it needs high performance for example. The importance, high, medium, low for prioritization, optimization goal, you may have different demands in terms of performance energy, function sizing, demanding particular resources, these are things that are treated, the requirements of the architecture and things such as how to link particular data services. Okay, now if we go a little bit into detail on how things function internally in the infrastructure layer, we do use Kubernetes. Okay, D open shift, we use Submariner for the connection of the clusters, we use Open Cluster Management for the multi-cluster setup, we have evaluated and using MicroShift for lower footprint Kubernetes devices. Of course Prometheus for monitoring, we use OpenWisk and we have started evaluating also Knative for function as a service but mainly OpenWisk at this time, at this moment. And then we take into account, we use Kubernetes operators and webhooks in order to manage how the components will run on top of Kubernetes. Okay, so yeah, this schema on how these are set up, let's say in our multi-cluster environment, you see different clusters here, the hub cluster has the OGM, Submariner allows the connection and then we have the semantics coming, you know, giving the description of the resources, of particular nodes and now if we check how the functional registration takes place, we start from workflow CRD, okay, which gets the first demand of what we need to execute and then we get the object directly from a managed cluster. We trigger the reconciliation loop in a workflow CRD operator and this will allow us to register the function within OpenWisk, okay, and eventually store it within ATCD on the local cluster and on the OGM so that we can be able to track it afterwards. Yeah, and now once this is done then in terms of a function execution, we have the execution of function which is triggered within OpenWisk. If there is already a hot container, there are a hot pod, then we can actually use it or else a new pod is needed and hence we go through the webhook and the webhook is going to allow us to enable us specific annotations for a particular scheduler and this is something that we will talk also afterwards on how, on specific schedulers that we have implemented that would allow us to make some optimizations going beyond the image layer that is implemented within Kubernetes and taking into account the layers of containers. And so once this is done then we have the particular annotations related to the particular scheduler, we have also collocation annotations such as we want to prefer to have collocation between a specific function or not, and then the particular pod is created on, the particular function is created upon a particular pod deployed on a specific node, yeah. Okay, so if we take a little bit some performance aspects, we have done some experiments and some that were interesting to show here, we have triggered workflows related to OpenWisk sequences of functions. Okay, we have also triggered workflows with full primitives and intracontainer parallelization, so in this case we have within the local environment of Node-RED, we have the different functions which are triggered directly by Node-RED in the local environment. And finally we have the full parallelization directly by the OpenWisk interface which can deploy different containers directly on the different clusters, yeah. Okay, in these scenarios we have measured how, what are the delays that we get in those three scenarios and as a matter of fact it's interesting to see that of course if we are in a Node-RED environment this delay is minimal. Okay, so if we want to test something very fast but with limited parallelization only within the same container then this will be quite fast to deploy whereas in the case of the other two, the OpenWisk cases then we are talking about 100 milliseconds of delay to deploy the actual containers. Yeah, and some other interesting measurements here related to the space time continuum, okay, where we have checked things such as the network latency, okay, we have three different clusters, one that we consider as heads, a small machine located in Greece, another one, and two others that are more like cloud machines, the one is on AWS and the other one on Azure and through the experiments we have started to get answers about what are the configurations that we have done and if they were correct or not. So for example in terms of latency we can see here that the execution of the particular functions in here it was related with artificial intelligence cases of our eHealth application. We can see here that it was much faster of course since it was the AIDS case, it was executed in Greece and then we have since the call was done from Greece it was the latency was much smaller to reach the Netherlands on the Azure cluster and a bigger to reach Sweden which is the other cluster. Other interesting things were the fact that in the waiting time we had a long waiting time for Azure cluster here and this was because we haven't configured well the memory of OpenWisk even if we had 32 gigabytes of RAM available. We had only configured two gigabytes of RAM to be dealt by OpenWisk and this was the difference we had between AWS and Azure there. Okay, let's talk about some specific extensions that we have done in terms of scheduling so we have been using two different levels of schedulers, one in the global continuum and another one in the local continuum and the local level. And so these both were implemented in the two different layers, we have the first one was actually related to how we can have multi-objective scheduling taking into account performance and energy whereas the second one is more related on how we can improve and minimize the cold start. Taking into account the layers locality, not only the image locality. And this implementation is currently ongoing and we are in contact with the upstream Kubernetes community in order to push these changes in the mainstream version. Okay, so last thing, one of the things that is interesting with this type of project is that we have implemented reusable artifacts in the marketplace, there is a marketplace that people can use and there you can find a catalog of available artifacts, operators, no dreadflows, data sets, semantic models and stuff like that and people can actually test directly. Okay, so thank you very much and if you have any questions I would be happy to answer. No questions? Okay.