 We're good to go great Welcome everybody. Thank you for joining us. I see some familiar faces and lots of good people. We want to help Understand some things we're doing and invite some collaborations. I'm really excited that you're all here So my name is Craig Peters. I'm a product manager at Marietta's and I'm Alexander Tevelkoff principal software engineer and Marietta is working for upstream Marietta So we're going to talk today about how you do applications across multiple infrastructures so what that what is hybrid cloud and So I want to address sort of why why do we care at all? What is it all about and If we're doing things across multiple infrastructures You know what choices do we face? There's some really hard choices that we have to make as we figure out the architecture and We figure out the implementation for this We're going to walk through a specific use case to kind of highlight some Some of those choices and the options that we have and and in that use case we've actually gone through some experimentation and we want to talk about that experiment and And then invite you guys to collaborate in that experiment. So we have some pictures here that are kind of fun so this the one on the lower left is us about 25 minutes ago doing slides and the one on the upper right is an illustration of how easy it is to collaborate because You know, even though it's the Russian bear. We're we're friendly. So That's that's really the message there. So let's talk a little bit about why you want to do hybrid cloud. So You know, it's getting a lot of press and a lot of noise and you know, everybody's been talking about this for a very long time and we don't see in reality a lot of Applications running in multiple infrastructures today and and there's a lot of reasons for that and we'll dig into that today But the reason that it's important and why people keep investing in it is that there are a lot of attributes of applications and applications running inside real enterprises that Will benefit greatly if we can do hybrid cloud correctly. So One of those is really about availability. So we all know, you know, the pets versus cattle's metaphor, right? and so the The idea is that that's great in the cloud, but the application itself Can't have those attributes, right? The cloud native application needs to be highly available. Well, how do you do that? If the underlying infrastructure Doesn't have five nines, right? It's got some number less than that So the way you do that is you spread your risk you move your application across multiple infrastructures another is about flexibility right you want to have applications that can take advantage of things that are specific to different kinds of infrastructures and So some infrastructures have, you know Super fast east-west networks and other infrastructures have very specialized load balancers and others have high speed Storage and so you need to be able to take advantage of that infrastructure while also getting this availability and at the same time you want to comply with Regulatory issues right so people want hybrid because they need to have their application that deals with personal human data in the region where that person lives right because the law may say Data for a German resident can't live outside of Germany for example, right? and so these these kinds of regulatory compliance have to be accounted for in your in your hybrid infrastructure and a lot of people are doing this because they want to Essentially outsource The management of their infrastructure and part of that's about driving down cost right so this is one of the reasons for public clouds But all of these reasons are valid, but for me the thing that I like to focus on When thinking about this is that the end goal for all of this kind of Application development is about actually accelerating the rate of the velocity here of delivery of capability to the end user Right and so as we get in the next slide that'll become Become apparent why why I put it that way, but it's really You know the thing I want to emphasize for people is that we need to focus on how fast Applications get to users because that's where the value gets created, right? So What do we mean by hybrid? What is a hybrid right? So you know and applications of all applications have had to have the ability to move from one infrastructure instance to another Basically for disaster recovery, you know forever right so that's kind of the upper left corner of this Quadrant here, so I'm what I'm doing is I'm saying there's a spectrum of different kinds of things that hybrid means So if you go down from there You know one kind of hybrid is why I need to have the ability to move an application from one type of infrastructure To another type of infrastructure, so that's kind of the first stage of hybrid and on the other end of the spectrum is Applications that are running in real time with sesson management across multiple of the same infrastructure or on multiple of different infrastructures with different underlying assumptions and capabilities and When you do that you have all kinds of additional challenges around data replication and data proximity That you have to deal with but this this is such a simplified view in fact what I was tempted to do is make an animation where it was those four and then I pop the The big arrows in the middle because what happens is that every application has a different style so a great example is Internet of things right so Internet of things is really hybrid application But in a different way you may have parts of these patterns, but then you also have edge applications you have services that are a part of your application that have to be deployed closer to the end user, right and Those have to have certain attributes and characteristics that they can conform to You also have I don't want to go into too many examples. I can spend too much time here But the idea is that every application architecture is possible and When you make your choices about how you implement hybrid application management you constrain Which of those architectures that you can effectively manage Right so now that we kind of have laid the groundwork for what do we mean by hybrid? We actually mean a whole spectrum of things You know we have to ask the question. Well, how are we going to manage that right so If you think about the full application stack all the way from bare metal up to the bits and bytes that the user consumes or Inputs or another system inputs or consumes You know we've created these abstraction layers which give us different capabilities at each of those layers And so the logical thing that we all tend to do and if I if you look at all the Hybrid solutions out in the marketplace what they do is they Take advantage of capabilities in one of those layers in order to provide The ability to manage applications across multiple infrastructures And what happens is that each of the at each of those layers, you know different things About what infrastructure is beneath it? What is the state of the application? At that layer and what monitoring data is available In order to take corrective action right because we think about hybrid applications You know it's critically important not only that we have flexibility But that it have the the ability to understand the state of what should be and be able to take Have an understanding of what infrastructure. It's depending on so it can fix what's wrong, right? And so we have to you know, there's a lot of analysis There's tons of research papers around this specific area, but I wanted to raise this because it highlights the need for a certain kind of specificity in What you do when you when you design the system that's going to manage hybrid applications So now what I want to do is I want to walk through a very simple This is you know a very simple kind of use case To just to help you understand The experiment we've done and why we've done this experiment in this way Right, so in this case What we're doing is we're saying well, we want to have an application that we deploy To one of two infrastructures in this case. I mean it's easy to add additional ones to this But for simplicity we said I want to be able to deploy this application to either Open stack or AWS, right? I want that to be a drop-down box And I want to be able to choose either one. Of course, this is needs to be a system that has a API and a CLI so it can be completely automated, but we have a UI here to help It be clear what it is. We're trying to do So I've chosen AWS and then based on that my next step is to choose What load balancers are available in that right and obviously the application has to be able to know Well what capabilities well has to be able to express what capabilities it requires of A load balancer for it to be a valid selection in this context and it has to understand What infrastructure the infrastructure that is the target can possibly provide, right? So we'll you know what what is deployable and manageable in that infrastructure and so if you think about this use case It means that you have to have Not only understanding of that underlying infrastructure, but the ability to deal with different layers of abstraction in the system so we did this experiment in Marano, so Marano is an open-stack project Actually, it's been a part of the open-stack namespace for quite some time And we wanted to take a minute to explain what it is so you can get as Alex is going to explain more details of this experiment and the work we're doing It makes sense. So Marano fundamentally is an integration framework. So It is also a catalog the open-stack catalog is an important attribute of it. It's a way to publish things, but but At its core is the ability to flexibly describe relationships and dependencies Between application components, right? So it provides a class hierarchy where you can describe sort of abstract classes or very specific concrete classes that Represent what capabilities you want to take advantage of in your application management It also provides a very powerful framework for being extremely explicit about the inputs and outputs on those those classes and it's extremely powerful because it matches both You have the power of declarative infrastructure Programming where you say this is the state. I want to be but also it's imperative it can take inputs from other systems or users and then do it then else kind of logic or looping logic, right and and doing those things In other frameworks is often very complex and Marano does this in a very nice way It's very important to state that it Essentially has an API so the whole idea of all of this is that we are automating this from some higher level system like a Business process system or an OSS Has CLI so the developer can interact with it or or it could be automated in your in your continuous deployment framework and It has a catalog and the catalog The reason we chose the Lego motif for the slide is the catalog allows you to publish building blocks and then higher level building blocks So it's a it's a mechanism for enabling your developers to collaborate across Very disparate domains. So you can have developers were focusing on database capabilities and developers were focusing on What does it mean to add or remove a customer from your customer system? And they don't have to You know, this is a place for them to publish the interfaces for how they work and create dependencies between these things So I can compose an application that depends on a bunch of other building blocks So I think that's that a high level. This is the way I like to think about Marano From here Alex will take it So let's dive into details a little bit I'm not going to frighten you with technical implementation details But let's speak about what is Marano under the hood? What is under those flexibilities specificity and power and how it empowers you the application developers? To target your applications to multiple clouds So let's start with the flexibility part with the class hierarchy as an application developers Any application developer probably knows one of the most powerful things in the software development world is the object-oriented paradigm because it provides a very clear and very Very simple idea of going from abstract to the concrete And that's what we have put into core of Marano the very core of Marano Because Marano is actually under the hood below all those cloud-specific and open-stack specific layers is a fully powerful object-oriented language which operates on regular good old classes with properties attributes and methods and Almost a regular slightly different, but you may think it's a regular object-oriented hierarchy of inheritance chains It supports multiple inheritance with a very with some special Special magic, but from the user's point of view it provides you an hierarchy of Classes where on the top there are abstract entities and on the bottom there are concrete implementations of the specific things so when you speak about their orchestration of resources and clouds When you speak when you think of it on the high level you just need to orchestrate resources for example the compute resources like nodes and From the application point of view it often doesn't matter what kind of node that is It may be a virtual machine running on some cloud that may be a bare metal node We just which was pre-deployed by some admins and have the SSH connection on it Or that may be a container everybody speak about container right now so For the application developer. I often don't care as an application developer I just need my software to be installable on whatever node it is and make use of the generic capabilities of it However, if I want to target my node for the specific cloud I may say that okay I want my application to run on Amazon or OpenStack node or Windows Azure node, you know Morano once started as a Windows data center deployment application And so we still have passion for Windows and for developers developers developers all the stuff So but besides Windows besides Amazon besides OpenStack We all operate on abstractions and on different layer of abstractions So what we want our developers to be able to is to choose the abstraction layer They need is to choose a specific set of Requirements they need for a particular goal and here comes our next part the designed by contract paradigm that another corner cornerstone of Morano and another basic paradigm we have Invented when not invented used when we're designing Morano score Morano's engine So designed by contract allows you as an application developer to specify the required inputs or required resources or required objects Which are needed for your applications to run and specify on the very specific level of details you need and The rest of the details will be substituted by their environment by the policy by the exact cloud You have chosen to deploy your application for so this is a very simple example as a user I will just say that I need a powerful database. That's what the user. I just Request so more engineering like approach will be to just reformated that I need a sequel compatible database that runs on a node we which has at least X IOPS like X may be a user input and and This is a engineering requirement which needs to be expressed in Morano So that the Morano application is able to choose between different building blocks those Lego bricks Suitable for that particular application So in our slide here, we have the application on the left and the database which is an input property for that egg required attribute for the application to run and the contract on that input property says that It should be a powerful database and now let's reformulate that in Morano language So at the first part the contract just stayed any object the dollar sign just corresponds to just plain old object So under on the right we have the applications which sued the current contract of course Any object much anything on the right now? Let's just write our contract and say that we need a sequel compatible database We have modified our contract and we have added this Keyword check for the class which means that the object which is being passed to this property should inherit The base class from DB package called sequel compatible There's just a basic interface which comes out with standard standard Morano application library and Any application developer in the world who targets the application for Morano may inherit their Classes in their packages from these base interface so any interface any application which inherits this interface will be filtered by this contract and so you may see that My sequel postgres sequel to the trove Maria DB and Oracle PDB matches this contract, but MongoDB is Unlucky unlucky. Well, Mongo is Not very good at sequel So let's modify the contract slightly. Let's say that we are just speaking about sequel compatible But we want just a my sequel compatible. So I have changed the contract. I have changed the base class for the interface and The filtering got slightly stricter so the postgres and Oracle are out of luck here and now we have just a choice of two Two applications to Morano applications one just provides my sequel which Is is being deployed on a virtual machine by Morano or it may be a container or well anything which is Deploys the my sequel server on demand and the second implementation is trove Maria DB That's the implementation which uses open stack trove to provide databases on demand So database as a service using trove There are two applications in Morano, which inherit the same base interface DB my sequel but have different Implementations of the same thing. However, let me add the third part of the contract. Let me check that the Node which runs database as a flavor and the IOPS attribute of that flavor is greater than X So for the virtual machine base deployments, we can get the flavor can get the node first of all we can get the flavor and we can get the IOPS attribute of that flavor and so we may check that the Particular attributes of the particular object in morano deployment matches that contract So for trove, we do not have nodes since trove is an open stack service It's not it doesn't run on virtual machines and of course, we don't have flavors for them And it's important to notice that this is not just it's a picking of existing objects But this is also a contract which applies on the creation of new objects So when your morano environment does not have the database already deployed Morano will just offer you to create a new database and those when you are Customizing its properties it will not allow you to pick the class which doesn't match the contract or to pick the value of Instance flavor, which does not match the contract. So at this point, you will be just guided by morano to the proper deployment configuration and so when you build that configuration you will have the deployment capable to Bind all the building blocks provided by different application developers to suit your needs so that's designed by contract and Now let's move to the last part of what is morano. So that's a declarative versus imperative Well, that's also the basic programming paradigm. Nothing new invented here And the idea is that morano actually combines both this approaches and that's what brings more power to it So when you're speaking about declarative, you're just defining the final state of your infrastructure or applications What you want to achieve so you just specify that you want your application to run on five nodes and they should be connected to a specific network and have floating IP addresses assigned and The final configuration of your say load balance replication should include round robin balance seen on HTTP 80 That's a declarative definition of what you want and this is actually the input properties validated by the contracts we have just discussed But then how you actually do how you achieve that final state? That's usually a different problem and it has different types of solutions So for example in case of heat we have the declarative part expressed as a heat stack as heat stack template and And the imperative part is usually implemented as heat plugins which now how to properly communicate with Underline open-stack APIs and services to provision VMs to create networks to bind VMs to this networks and to execute the software configuration on those VMs and That's cool. That's powerful. But as application developer I very often do not have the access to the heat plugins since heat plugins require the administrative privileges to be deployed on the particular cloud and We wanted Murano to be a catalog of applications So this Lego bricks could be contributed by different people from around the world who do not have Administrative privileges on the clouds on which these applications will be run And so we have added their imperative capabilities to Murano So the actual workflows actual scenarios the actual sequences of API calls Could be expressed not in Python or some other high-level programming language, which requires, you know hardcore programming skills But to be part of Murano class definitions Murano classes are defined in a very simple plain YAML notation which just Available to pretty much everyone who has access to the cloud and can upload the Murano packages to it And so you are able as a application developer to specify the workflows which will Provide the interaction with external APIs or something internal some data transformation or some user notification schemas or well pretty much everything which is Which is required for your application to properly run at the same time. It's safe From run a PL code, that's how we call our programming language Murano Pell from run a Pell code You cannot execute nothing which will compromise your cloud. You cannot do arbitrary input output You can just call the specific set of cloud APIs You cannot do input output operations on files with on your on your controller nodes on OpenStack hardware because it's it may be unsafe to do that since the code is provided by the end user and so it's a balance of power in terms of programming power and the safety and security in terms of sandboxed environments and So how all of this applies to? Multicloud approach So as I said the base class hierarchy allows us to build their risk to build that abstractions of the cloud resources and have their implementations for different kind of cloud providers So for the node for the compute node instance We have an obstruction for OpenStack VM. We have an obstruction for VMware VM We have instruction for Amazon VM and we have an instruction for Kubernetes pod and Docker container all of them may be considered just a regular compute node and here is the Just sample topology sample architecture of what we have done in Murano So it just stops being just theory it becomes practice and it's even works Which is stretch to me. So we are combining OpenStack cloud with AWS EC2 cloud Orchestrated by Murano So in our private OpenStack cloud we run Murano in a regular deployment way So you just may take regular Dev stack. Don't forget that Murano is just Playing upstream project Available to any OpenStack deployment. You just take the Dev stack deploy Murano Just run the VMs with it But at the same time you are able to communicate from Murano engine with Amazon EC2 APS We are a regular HTTP protocol This will allow Murano to spin up VMs in AWS at the same time Murano needs to configure VMs and Very often it's quite impossible to just SSH to your public cloud nodes because you don't want your public cloud nodes to be Accessible with SSH. So we have suggested the topology which has a dedicated virtual machine in AWS space Which runs a messaging broker. We use RabbitMQ, but there may be plenty of choices and that VM is also deployed by Murano, but It has a capability to configure the other VMs by providing a message bus So Murano just puts the messages in MQP protocol just into this messaging broker And those are VMs which are spawned by AWS communicate with that message broker and receive the commands. So this allows you to establish the connection between Murano and the AWS spawned VMs without Opening them to the world So you just have to secure the single message broker machine or you may have a cluster of them if you need higher performance But that definitely just reduces the surface of attack in case you assume that your public cloud may be compromised At the same time very often when you need the hybrid cloud approach You need to be able to communicate back from the public VMs to the private ones or to Containers running in your private cloud. For example, when you have a hybrid application running the two-tire or three-tire Applications three-tire topology when the front-end for example runs in public cloud and the back-end runs in the private one You need to have a connection between public and private to get the data And for that you may utilize any technology which is accessible in that particular cloud So for example AWS has a VPC which allows you to establish the connection between Amazon's network and your enterprise network And if that cloud doesn't support you have another implementation of that base class We just allows to establish the connection using some other generic VPN technology for example in our example, we have deployed the open VPN on all the nodes and those Established the VPN to our private network. So this gives us the basic understanding of what we can do besides VMs We can we can also have the networks. We have security groups. We have ports. We have volumes All of these are abstracted as a base class in Morano library and have the concrete implementations for both AWS and OpenStack And we'll add more Then this is just a way how to deploy the applications in Morano. This is a very simple and quite naive way to do that Morano environments consist of multiple applications which just provide the deploy logic and own the resources like node the nodes on the nodes or own the VMs and Those owning their states. So when the application deploy the node it calls the underlying Underline class which knows how to communicate with that particular cloud for OpenStack We use heat for AWS. We just use AWS API and then just applications run their deploy procedures concurrently and this just gives us the deployment of complex multi-part application. However, this thing has has issues It's too open. That's the most important and too flexible. Sometimes it's a bad for the application developers The flexibility means that they're on their own when they just have to implement the whole deployment logic. Morano just says, okay, you have an application you have a method called deploy put all your logic there and the application developer has to put the Morano PL imperative logic to Spounder resources, put the scripts on them, run them and so on. That's too too open too Unopinionated. So the developers often say, okay, we just don't want that. We'll just use our old plain puppets for example And often they have the common mistakes when they are following this approach. For example They are storing the state of the things on the VMs and VMs in the clouds are cattle They can be killed at any time and be responded at any given moment So the state should be persisted in their orchestrator, which is Morano in this case So what we are suggesting is to just bring more application lifecycle management to Morano and to Morano applications We are suggesting an even driven workflow model. So the Morano applications written by by the developers just provide the hooks or event handlers for different kind of Events happening during the application lifecycle. For example, when the application let me just switch to the next slide So this is a example of even driven workflow. So the application just to the right It just provides the handlers of different lifecycle events like the reconfigure when you decide on which nodes to install the application the Installing a node when you just upload the particular software configuration script on the node and run it and different handlers like what to do on start what to do on stop what to do on health check and so on and The other set of classes which we call node set group the different kind of resources and orchestrate them Independently of applications and just notifying the application that it needs to do some event handler like when I have spawned a new VM or a new container I just need the application to configure it properly So I just pass this node to the application and the application has access to its base interfaces to call the appropriate methods and As a result we Having some opinionated workflow some reference some reference models of Sequences of events which will happen on the nodes and will happen on applications And here is just a brief list of what we just added for the first prototype For the application developer of course the application developer doesn't have to just specify all of them If you don't want your application to be healable you don't need to implement the health checks or heal up or Like if you are pretty sure that your software will never be upgraded probably you don't need the check for upgrades But you better have but so this is just a base set of application lifecycle events and That's already the QASF. I think I had one more slide So the idea is that we will have the base reference architectures. I think it's like Here, yeah, so we'll have the basic reference implementations for standard Enterprise grade patterns like the stateful stateful applications like databases the stateless applications like web farms and Combinations of these into two three and entire sets. We will have this reference implementations be cloud diagnostic So they will operate on the base node class base network class base port class security group and so on So you will not depend on the particular cloud implementation when you are defining your application But if other application developers need more specific functionality of some cloud They may always narrow down the contract by applying the extra checks and extra type typecasts at the particular implementations they're writing So that's how we are going to That's how we are going to work with With morano I think yeah, this is a call to action slide So this was just a description of the prototype We have done with morano and we are going to turn this prototype into a full-fledged Application framework which will be released with a new turn release of OpenStack or maybe even somewhere before that So we want you the developers or Consumers of the cloud applications to join this effort to frame the set of requirements you need for the multi-cloud Use cases you may have and join the collaborative effort of morano OpenStack community and Just make sure that you are heard your voice is heard and your use cases are reflected in the framework Which we are going to build so join the morano development team and Try joining us on Thursday when we are going to have the designs design summit sessions To decide what we are going to do in Newton with morano as one guy once said Developers developers developers developers we need you guys. Thank you Thanks Questions it was that clear Yeah, come on up to the mic The lifecycle management does it include like the evacuate is the one that deletes the VM that gets created in the AWS or something How does you know morano controls like you know once a VM is created in the AWS because I saw Morano is now controlling actively actually Acting as a control plane for the VMs that is getting spinned up in the AWS Not the OpenStack control plane if I understand correctly. Yeah, so There are two questions one how do how do we delete the VM that is getting created in the AWS number one? And if morano is not, you know, if the OpenStack control plane is not Controlling the VMs that are spawned in the other cloud environments. Would it put it? You know risk in morano because morano is additional plug-in for now actually Well, this thanks for the question So there are several parts here So how we manage the resources so the idea is that morano owns the state of the application at runs and the state includes the reference to the particular resource which Just runs the VM or network or whatever. So morano always aware where where some resources run and so when the Resources they are located morano knows how to not morano the application developer who Defined that resource may provide a code to free up the resources in the particular in the particular particular cloud so to just Remove the VM from any cloud where you have created it. You just need to remove the resource from morano Object graph which just represents the current state of the environment and morano will take care of calling the appropriate event handlers to Free up the resource. Of course, this requires a morano control plane to be available at that time So if the morano itself dies as a service, then of course, this will not happen However, morano as a service is high available So it just has a multiple workers that has its own load balancers And it's actually quite independent from the rest of open stack Infrastructure in terms of when it when it comes to orchestrating other clouds, you don't need keystone You don't need nova. You don't need heat. You just need morano services to run and because of that morano being able to keep track on the state always is able to just free up the resources whenever they are in open stack or in AWS or whatever So I think that this should answer a question, but please let me know if it doesn't other questions As an application developer Could you explain? What all things that I'll have to write to so let's say if I am developing a multi-tier Java web app and I want to deploy it to Let's say AWS or some just one particular infrastructure So if I understand correctly, I need to be able to write not only the actual Java stuff, but also the morano language Understand that and write event handlers. What happens when a node gets Deallocated and things like that. So what's the power of the morano language and Do you think that now that is complicating the life of application developers to have to actually write two different things? Okay, yes, the question is good and the thing is that You may define the application life cycles handlers if you need to but you don't have to Because the base classes on the hierarchy are already there So if you're just running just yet another Java application and you don't want to redefine the topology Most probably you'll have a base class for Java application Which is already present in the library and written either by morano team or by someone else so what you just have to do is to instantiate that object with providing say your git repository where it Takes the sources of your Java application and everything else including like provisioning VMs checking out the source code it Running like maven to build up your jars and then deploying the jars on your Tomcat container Will be just done for you But the power is that you're able to customize the deployment by combining different LEGO bricks So the default applications may use Tomcat to host a job application What happens if you want to use web sphere or J boss? Probably there is another morano application run a package which knows how to deploy J boss but what happens if it Exists but does a thing not in the right way in the thing in a way that you would like to redefine some part of that workflow like Do some post configuration of your J boss after it's installed. So you just take the existing applications subclass it just create the derived class override the particular like on post configure method and Just run some script on the VM which will be running the J boss container and after that this newly modified J boss application will be able to work with all other Java applications We just require a server container because it implements the standard J boss interface Which is which on its own implements the base So that container interface so that's just a regular object rented approach Which allows you to combine things into a single Meta application and you are able to substitute smaller bricks with the ones on your own and Speaking about the language complexity. Well, yes, it's always hard when you have to learn the new language however morano PL was Designed so it's easy to learn and it has its It's form its container format as YAML. So it's just a regular YAML YAML like thing. So I Think yeah, so this is just an example of the declaration of the slide the slides already gone So yeah, if you want I you make just come come by to my laptop And I'll just show you how the YAMLs look like it's yeah, here it is. So that's just a definition of the Application we have it's Apache HTTP server it extends the standard application class and it adds the two properties on it So you have the contracts you have default values. So it's reasonably simple And it does not add complexity when you don't need it But when you need it, it's on the on the way to help you to just define the needed parts Or redefine the needed parts of the workflow other questions I Have a question How different is morano than other past solutions like cloud foundry and you know open shift looks like there's a lot of Duplication here. So I'm trying to understand that Great question So first of all, we don't want to duplicate anything which we can Reuse the idea is that morano is an integration framework. It's not an opinionated orchestration tool or I don't know wondering to rule them all it's a thing which just can help you abstract the different things into some base standard baseline standard and Delegate the actual implementation to the particular Particular implementation so it may deploy the applications with cloud foundry and at the same time It may provide the interfaces for cloud foundry to deploy its Application via morano and we actually have this implementation already present in morano upstream We have the service broker API of cloud foundry and so morano may act as cloud foundry service broker and at the same time morano is Not commercial or proprietary product it's part of the open stack big 10 and the idea is that for people are targeting their applications for Open stack and so first of all for open stack and then for other clouds they want to have like the minimum common denominator which will provide the Universal capabilities for all open-stack clouds and that's going to be morano and then if they want to have the specific implementation which will utilize the maximum powerful of the particular tool be it a cloud foundry be it any other software configuration or Infrastructure orchestration tool they may have the morano package which does it for them by implementing the same base interface Well, thank you guys very much appreciate it. Do you have any questions? We'll be up here