 Hello folks Happy to see you. This is one of the small angles of this big huge conference center. So it was really hard Forcoming and today I would like to talk about deploying cloud applications Hold one of the talks this post speaker gersen To join me a little bit later Today we are going to cover a short overview of those languages compare them by several Criterias and how we'll talk about Cloud bands journey in selecting languages for they platform today application How's a platform support cloud applications like and NFE use cases and we will have time for talking for questions And we'll try to answer them So once again our objective for today is give you Enough knowledge and help to help you make an informed decision to which of each language and which tool to use for your next Apply cloud application regardless you are going to use it for NFE use cases or some ITSS service or just regular WordPress So let's go quickly through these languages But before that, I would like to clarify. What is DSL most of these three languages hot Murano PL and Tosca Explained it as DSL. So DSL is a domain specific languages which is specific of Applied specifically in some specific use case and in our case use case is deploying and managing application on top of the cloud So three languages hot Murano PL and Tosca we selected this with languages because they are available natively in OpenStack and Here when we are talking about these languages. We're also talking about the implementations in OpenStack for hot is obviously heat for Murano PL is Murana and Tosca Slightly different. Tosca has project which called heat translator, which is responsible for translating Tosca definition to the heat template and deploy it through heat. So basically You take your Tosca template and deploying it using heat so you can use only Compabilities available in Tosca, which are also available in heat But regardless of that We also will talk about language most oldest language in From this three is Tosca. It started the development of Tosca started five years ago and Initially, it was XML based language for defining Defining application definitions laterly around two years ago two years and months ago first public draft of Tosca simple profile in YAML was published which is available by the link You can see on the slide So all the ideas of Tosca was started developing five years ago But implemented in YAML as what we see in heat translator two years ago Murano PL was started also three years two years ago one year and 11 months and Heat is three year ago and first public release was Gawanna with hot templates Probably also interesting point is how huge is community around this language given that hot and Murano PL available only on OpenStack Given that the implementations are also only available in OpenStack for now is 130 developers in metaka for heat templates and hot 9 history development developers in metaka from run appeal For Tosca we count slightly differently This is OpenStandard not yet published. It's still in draft. I'm talking specifically about Tosca simple profile in YAML Original Tosca, which is XML based already in Oasis standard. So this language is developed in Oasis and it's Community where any company can join and join this working group working on this language So they have 135 members who working on developing and extending this language I truly believe that one of the important thing about language is Which is Is it imperative or declarative? So this language two of them are declarative Heat templates and Tosca are declarative languages So essentially you declaratively describe what you want to achieve as a result of the execution of this definition and Morana PL is imperative so you specifically say what morana engine needs to do in order to Give you a needed result Also, you have them are based on the YAML though Hot and Tosca can be natively translated can be parsed as YAML per se Morana is slightly different. We use some extensions of YAML language. So we have constructions which are not really Maybe parsed with like this bear YAML parser But still it's YAML based and completely confirms YAML standard So with our extensions which are allowed by the standard morana PL can be parsed as YAML each of these three language are Here following that like I described it described it as resource-oriented or object-oriented I Will explain a little bit later in more details. What do I mean by that? But specifically for heat resource-oriented means that most of the constructs constructs in your language are Resource and in specifically for heat. It's your cloud resource your VM your Network your port which you attach this VM to this network or any other cloud resource in one appeal in Tosca they are Both of them are object-oriented slide but slightly in different ways, obviously, but still Object oriented it means that in case of morana PL you operate it by objects and object can be anything you can have an object of Your application which defines different scale up scale down methods of your application deploy remove for anything Or it can be a class which provides you AVM or it can be class which provides some specific functionality or set of utilities anything object-oriented language in Tosca, it's also object-oriented by slightly in different ways in Tosca you can define Interface and have implementation for this interface and you can hide and behind this resource quite anything and It can be also another application. It can be some resource. It can be some something But not we are not specifically cloud resource So this is like several Metrics which I think it's important to know about language even like before everything before going through details of which Hot was inspired by Amazon cloud formation. So heat as a open stick itself started as a clone of AWS and For a long time about a year, I believe he'd only supported cloud formations in place Which are literally were compatible and one-on-one matching to AWS cloud formation language but slowly slowly to Reuse capabilities which are provided by open stack Getting more and more different from AWS He needed something to accommodate it and they had two ways extend cloud formation and make it not compatible with AWS AWS cloud formation like templates or Make something else on top of that like as a language, which will accommodate all these capabilities immersed in open stack. So in 2013 first heat hot based templates began Was available with how I'm on release in open stack heat is This really languages and given that we have implementation in in a heat translator for Tosca holds the latest contributors community and It means that most probably you'll be more quickly addressed if you have a question about language Or you have a bug in this language using heat then run appeal or Tosca as a former PDL from running it said to say but it's true and and one really thing which heat is really good and this is why we use heat in Murana To do resource allocation is explicitly declaring resource topology, which you need to stand up your VMs your networks your drives everything which you need to Spin up and make sure that each one of this resource will be Allocated and especially with new convergence feature, which he team is delivering with Mitaka as a first place and probably Newton as a second phase given even fuser in Making sure that what you requested will be truly allocated for you and delivered not maybe of exactly like In this second, but eventually your store your state which requested the state of the this stack will be Converged to stack that you requested even if it diverts at some point of time few things about Murana PL so Muran appeal is imperative object-oriented language everything is an object everything and Imperative obviously means workflows. So in Murana, you natively have a workflow and you can Specifically say please go here bring up this cluster Configure this endpoint on this node and go to this node do this thing and pass to this node before this node will complete the deployment Muran appeal syntax is appealing for Java and Python developers because it's really close to any Simple object-oriented programming language Java, Pine and C sharp you name it and we intentionally did that because one was a Really important thing for any language regardless is a DSL or not. Is it programming general programming language or whatever is? How is it easy to pick up it? How is it to start developing in it? Is it intuitively understandable how to write for cycle or if in this language and one of the things which I would like to attribute to Muran appeal as advantage and highlight more than highlight is ease of composition and Ability to heavily reuse different components giving that you're writing as in traditional languages different classes and interfaces and can do inheritance All the object-oriented stuff it gives you a truly remarkable way to obstruct your pieces of your court your stuff that you implemented in Different classes and upload them to the Cadillac, which is also one of the things which stands Murna and one appeal from other two is built in Cadillac capabilities So we basically have a place in the cloud where you can publish your applications your libraries You choose which you developed your small pieces which can be used by any member of your team and And talking about Muran appeal I can't stop talking not to mention yackle yet another query language This is embeddable and extendable query language, which is used by Murana, Mistral, Fuel and hopefully heated some point of time in heat There's initiative to replace the Intristic functions which used in heat to extract some value from different resources By query by yackle you can see a few examples of how Yackle works and how looks like this query This is a rappel so you can run do people install yackle run yackle, load some JSON file and do queries on it Yackle doesn't work on JSON. It works on any arbitrary object structure Python object structure and it's important because Comparing to like JSON can can have circle the circle circles in the graph and so on source. Yackle can handle that a lot But we are not talking about yackle specifically today a Tosca Which is really good about Tosca its open standard and at some point it will be accepted as an open public standard and It's already in industry standard in NFE kind of given how young is NFE overall Tosca have a lots of implementation. We have one in open stack through means of heat translator We have Cloudify, which is also open source a project meaning to implement Tosca and Cloudify now trying to adapt the engine to be publicly available to anyone to Develop the own orchestrator on top of this language and they call this project I believe area and they're going with Apache foundation just in case your career curious guys so and most most Famous companies like Nokia with a cloud band product obviously and others. Yeah, I know that HP kind of have that have their own implementations which is good and I believe that Tosca is best suited for development of applications which One side are close to infrastructure, but at the same time they all subtracted for me and I will explain it a little bit later more So I would like to compare this language in three Criteria first of all learning curve so hot Has a good documentation really good? Honestly, I admire it because we use it almost every day when we develop more on applications in order to stand up different allocation strategy Was designed after AWS confirmation meaning if you have some DevOps experience with IWS You probably know how to develop using heat. At least you can quickly adopt More appeal moderate set for the admitted but true Docs are scarce We will be working on that. I hope you have complete reference for the language and core library at some point of time It's really hard But it's a good side of it. It's looks like Java and Python so if you don't really Scary to get your hands dirty and you know how to program you'll have no troubles Tosca I would also say moderate because Essentially have a specification which tells about language but problem with this specification is different among patients and different implementations are Truly can be different. So basically most of the time you can't run same Tosca template on two different engines They will not run and this brings it to the fact that if you want to develop something need to learn and Remember if you're developing for this engine, you have this is in this and don't have this. That's why moderate On a good side is really close to how hot looks like so also pretty easily to adapt Second criteria is how to how easy is to create reusable components in the language X? I Would say how it is moderate because applications can be defined and super positions of other resources and templates essentially if you want to abstract some part of your template basically several resources together you create another template and can reference one from another by URL and by and You provide input parameters Good side that even most complex imaginable topology of resources can be stand up like this super easy and and All logic behind each resource is written on Python. So essentially if you want to extend Capabilities available in hot you need to write on the Python your resource implementations and at the same time most of the heat resource Hot team plates are written for specific. Oh, sorry a written for specific clouds meaning that You use internal stuff internal knowledge about your cloud inside your template More appeal is as I already mentioned quite easy to implement reusable components because you have object-oriented design for your pieces And you can upload them in turn in a way of library to the catalogue like with literally library like dynamic DLLs and so files But not obviously DLLs And you have building catalogue so you can charge them publicly with anyone in community or inside your cloud Tosca is close to heat But at the same time slightly different. So in Tosca you have interfaces so you can abstract Different pieces behind the interface and have completely different implementations That sort of that each implementation is most probably something written on Python tell something Rarely, it's the same time Tosca. So in run appeal All business logic is Tosca. Oh, sorry is more on appeal in Tosca business logic The other sources are some other language probably Python if you're talking about Python back the implementations of Tosca Good side you have a way to create reusable component Czar. It's archive of your application. Oh a few more beats infrastructure abstraction How application developers abstracted for me structure infrastructure how deeply I Need to know on which cloud you are going to run my application What does cloud have which projects and which capabilities? So in how this limited you need to know which resources you have in this cloud or you end up like so huge list of different Parameters which you need to pass idea of the network idea of this idea of that or whatever In one appeal is limited because of one huge thing Huge mistake which we did we didn't pay so much attention in developing this core library in developing these abstractions We have them you can write them, but we don't have built in many of those We have networks. We have VMs, but Not so much other stuff you can do directly going to heat and in Tosca is easy because you have interfaces you can make implementation of like interface of these interface of that and first of those and Don't think about underlying cloud implementation Downside hard to use in different different engines, but if you're talking about same engine, but different clouds It's works well On this note, I would like to pass This presentation to how she will explain and talk about how cloud band was using heat and using Tosca in the product Hello everyone So I would like to share our journey with you First of all, what is cloud man cloud man is a portfolio of NFV solutions The three main ones that we have is cloud band infrastructure software cloud band application manager and cloud man network director a Little bit louder. I don't know if it's possible. Can I move the mic up? Go ahead? Okay. Is this okay? Yeah, you hear me Good. Oh a lot of people. Okay. And so the last two that I mentioned are the ones that are relevant for choosing Technology to develop and deploy your cloud applications so I Want to talk to you about the journey that we've made from 2012 that was mostly a proprietary Solution to a community-based solutions that we have today as you see here in the headline see VN FM Virtual network function manager. This is the way that we deploy our application so What we have in 2012 is the VN FM that was a proprietary solution that we made with our partners on old partner a Past life of Cloudify giga spaces together. We had a full comprehensive complete solution that enabled us to deploy scale Heal monitor and upgrades applications This is how it worked They parsed DSL it was a groovy based DSL and Requested the resources and then installed them our job was to take care of all their customers policies and Making sure that application was placed optimally in the best possible distribution they can do So why did we need to evolve if we had a working solution? well at the time The customer started a wanted open openness and talking about it Vendor locking was something that everyone wanted to avoid and our partners realized this as well They declared that the product has reached end of life and started working on a new product completely different also managing application, but Different and with the same name So we found ourselves at 2013 with a decision to make what's DSL? Should we go with in order to develop and deploy cloud applications? So our design drivers were these first of all after our experience with a proprietary language We wanted standard DSL now This was obvious for us Secondly, we wanted our VNF manager to be generic We didn't want to limit ourselves to a specific set of application or even to a specific application in specific company We wanted everyone to be able to work with our solution Next thing we wanted to support multi-cloud from a very similar reason for why we wanted the generic VNFM We didn't want to limit ourselves to a specific cloud or specific cloud vendor and Lastly being a part of the telco world that we wanted their product to be at a high level of service ability The two main options that were on the table at the time were either Tosca DSL with our own engine implemented inside cloud band or Hot using the heat engine that's written in the community We went with the Tosca option first of all was it was in a very early stages then and was little immature actually So we preferred to rely on an engine written at home that we know will work and we can use it another reason is that We looked at their design drivers and we saw okay, so we wanted the multi-cloud multi-cloud vendor and hot was focused on open Stock, so we didn't really fit our needs Didn't feel this design driver Another thing is that Tosca had been developed inside the Oasis and all the right companies were there so it really looked like it's going to be a standard and That is why we chose it So what we did is we implemented our own Java based Tosca engine Inside cloud band we relied on the latest working draft that was published at the time and All our objectives were met, but we still needed to keep evolving Why is that and The time that it took us to develop Tosca a lot of things change in heats More and more people joined more and more company joined and features were added all the time Making hot very popular amongst different VNFs and VNF vendor a lot of VNFs were implemented in hot and Customers came to us and asked for features that were already available in hot This led to a situation that we were kind of always one step behind which are Tosca implementation because at the time it took us to add a feature implemented in hot it wasn't available for customers to use and New features were added in the meantime and requested later Also Believe that's a side some of the requirements that came by for feature didn't really fit Tosca Tosca is a solution that is built that you can Create an application that could move from cloud to cloud You can't really have feature that are specific to only one cloud because then your application Can't be deployed another one and some of the features request Were relevant only for OpenStack So it really didn't fit So these are the reason so We had to make another decision or it wasn't really a decision because it's pretty clear that we needed to add hot support In our our product. We still wanted a generic VNFM like before and of course still co-grade service ability But this time we understood that OpenStack is very popular and it's only going to be more popular Which was right as you know each summit there are more and more people here so we focused on OpenStack and we wanted to expose all of the Veeam all of the OpenStack if we're talking about OpenStack all of the OpenStack capabilities that are specific for OpenStack so odd decision was that we needed to adapt to our customer needs and also, we didn't want to go in that direction and Lose ignore hot and lose all of the VNF that are already implemented. We didn't want to make it hard for people To use our products So what we did is we started promoting and recommended our customers to use the hot DSL and the heat engine and Also, we exposed it in our product and leveraged heat the main thing was that you could use our product to Access as an access point bring your own hot templates and From our interface you can choose what OpenStack version you would like So we still had the possibility to support multiple OpenStack distributions so you can have a redder distribution or our own distribution that is based on reddit or Any other maybe even vanilla OpenStack so you can plug it into our system bring your hot templates choose which OpenStack node you would like and deploy it there and I'll let you write it in my notes We as We changed our focus a little bit and included it to allow VNFs to be deployed in OpenStack some of you might know that VNFs were built very closely to the hardware and and Sometimes they needed very specific things and sometimes they weren't available on OpenStack yet So because we decided to focus it on OpenStack Then we filled all the gaps that we can find in all of the VNFs that were Deployed on cloud band or wanted to partner up with club and even VNFs that weren't developed in-house Then we feel all the gaps needed to be filled in OpenStack So definitely our recommendation when it comes to VNFs is hot Sorry so all of this is relevant also to Alcatelusent before the merger with Nokia and I want to talk about another product as well. So all this journey Was we talked about the VNF manager VNF manager is responsible for deploying a single VNF There is another product that we are working on in a cloud band network director Which is an NFVO Network function virtualization orchestrator. It allows you to take multiple VNFs and connect them together and It's two needs a DSL So we needed to make a decision for that one as well. So this is the NFVO We wanted a generic NFVO from the same reason that we wanted a generic VNFM for the VNFM product and This time we wanted a standard DSL and we wanted Multicloud and Multicloud vendor and we wanted a telecom greater visibility as before so This time around Very different from the the decision we made before for our combination of hot we chose Tosca Heat and hot are only for OpenStack and Tosca is a solution that can be a Very universal compared to it and the problems that we had with it originally That VNF vendors wanted Specific capabilities from OpenStack isn't relevant here NFVO is a layer above it You use the VNFM in the NFVO when you want to deploy your VNF you the NFVO sends a request to the manager and the manager is responsible for all of the headache of talking to a specific cloud This is a higher level version So if you remember when you said before that Tosca was too high level here It's an advantage because it's a high level in the right amount so for NFVO that deploys network service our recommendation is definitely Tosca and I think it's time for questions, so please join me Thank you folks It's it's not clear for me why we should have a YAML based language In Murano, why not use plain white language? it's Pretty difficult to pitch you now Maybe you can clarify. Yeah, sure. So why Murano started using their own language DSL invented on DSL comparing to using already existing Python, Lua, anything which can be embedded actually so To make Python embeddable and secure to in order to be able to run on controller nodes You need to be Google with the App Engine or have a team of 100 people so we didn't have that so we went with our own language Which is sandboxed but built on top of Python So Murano PL doesn't have compiler doesn't have translator doesn't have anything which is almost direct mapping to Python So actually you when you're writing for cycle you're writing for cycle on Python But at the same time you're only able to use so much which is exposed in Murano PL in YAML So we gave sandboxed language to the users Instead of use giving ability to use anything and run Unsecurely on cloud as you remember any of our users application developers can develop their own piece of code and Uploaded the catalogue which some other user will execute on controller node in order to deploy application So you have no check like you need to use a hundred percent trust to this code and run it super securely Or use something else which will guarantee security for your code. That's why we invented our YAML language at that time Murano started in 2012 in 2013 we changed language from XML to YAML There was not so much container stuff so probably now We will we would consider Running some existing Python language in some container spawn container run something then destroy it But at that time we didn't have this choice So I have my answer to your question. Yeah You mentioned about G when a generic vnfm Will that satisfy the requirements of vendor specific vnfm. Can I deploy a G vnfm and take it off? majority of my vnfm needs Now can you repeat the question, please? So This is about generic vnfm Will it satisfy the need because some of the vendors come with their own vnfm manager And if we have to go with the generic vnfm How feasible it is? model I'm a software engineer at Nokia so First of all it will have to be implemented in a language that's the Engine knows how to work with it should be over a specific cloud. That's fit it and secondly a Specific vnfm is also an application. We are never talking on a hardware So even a specific vnfm can be deployed as part of the application if there is a specific monitor needs you needs to fulfill Are you talking about something that needs to run? vnfm with a generic vnfm Instead of deploying specific vnfms. Can I have one single generic vnfm? Yes, and one is targeting this Market we would like to be generic vnfm But for now everyone talking about toscar as general as orchestrator as a manager and So far we going can you expand a bit on What you called a network service in your last slide I believe it was and you chose toscar for that versus for a vnf you chose but What's the difference network service versus vnfm and The other question was how does tacker? fit in with or cloudify Fitting with With your cloud band problem Okay, so first of all the difference between a vnfm and NFVO is that a vnfm is a generic manager for a specific vnf It knows how to manage it knows how to deploy it out to scale the real everything around the life cycle On the other end NFVO allows you to take on a high level the vnf and Connect them together, but it doesn't do all the Dirty work itself what it does is it talks Using a restful API it talks to with the vnfm and request it. Please deploy a vnf with such and such details for instance With the name x and vendor y and then the vnfm does it. He knows how to deal with it so right now And cloudify aren't part of the solution offered in cloud band, but everything that we are doing we are trying to do It's as generically as possible So if we will need to integrate with other solution, we are open to that. I Believe tacker is the NFM and the catalog as well. It's the open stock project tackler right any more questions Thank you so much. We'll be here in other Few minutes by 10. So if you have more questions come to us, we'll be happy to answer. Thank you guys