 So, ladies and gentlemen, please take seats, please mute your mobile phones, if possible. Don't forget to send some feedback, there's a feedback form here and the last slash is important. The next talk is going to be about wetfly swarm, that's another exciting technology coming from J-Bos Middleware. The presenters are Bruno, Sebastian and George. Can you hear me? Okay, if you don't understand my French accent, you tell me, you wave or... So first, thank you to Sebastian and George. I stole them this morning because the swarm and forge are things that are moving at the fast pace and we've been doing lots of work and George will tell you actually the work he's been doing, actually just been merged two days ago so it's the right time to talk about it. It wasn't planned initially but he managed to get in and same for Sebastian who's been working actively on the project. So thanks for you guys and I think you introduced yourself this morning. So like Sebastian, I used to be French as well. So I'm living abroad, I've worked for Red Hat since 2007, I used to be a customer and now I joined the engineering team and I'm very happy there. We have fantastic guys, fantastic technology and fantastic projects so it's very exciting. We have lots of passion. I don't know if you joined Tim Burke presentation this morning about rock stars and I think I can say a lot of the people in my team and people who are here that work for JBos really fit in that profile, actually check most of the boxes. So it's great to be surrounded by these profiles and these people. Maybe you can talk a little bit about yourself. Yeah, for those who weren't at my talk previously. So I'm Sebastian. I'm half French and half Dutch and I joined Red Hat three years ago and I'm on the Red Hat mobile platform team and but today I will talk about Fortune's Forum because I love to talk about other technologies and I talk about these technologies as a passionate user so it's really cool. Hello everybody. My name is George. I am the project lead of the JBos Fortune project and I work in Red Hat since 2012, three, four years and well, this is going to be great. So today the presentation will be a mix of slides and code. And also we'll have a few little questions towards the ends but I'll keep the surprise. But feel free to ask any, I don't know if we'll have enough time with 40 minutes but if you feel like asking a question, raise your hand. So there's a few sessions about microservices today, about containers, about evolution, about lots of things that, you know, moving into that direction but for us it's an evolution. Microservices is something that existed. If you've seen the second session this morning with Mr. Miller, it started actually with microkernel in the 80s really at the low end of the stack on the Linux side but we're looking more at the higher end of the stack today, so more really at the web frameworks level, at the application level. And one of the purpose of that talk today is how we've transitioned from traditional, we call it sometimes monolith applications, and where are we today with microservices. We're not going to spend too much time on SOAR type applications but we're focusing more on immutable infrastructure, microservices and containers. This morning, Sébastien presented the author and bookstore applications. We'll use that as a traditional application, something you deploy as a single artefacts in an application server. And we'll take you through what it takes to actually to swap my app. So we'll take you through these steps. And we also explained you actually a little bit of the notions behind microservices and also what are the constituents behind SWARM, what is SWARM exactly. A little bit on the characteristics of microservices, definitely about decoupling, independent release cycles. What do we mean by that is actually very often in agile groups actually, we will see more and more of fit with the microservices characteristic there because two PISA teams will work on maybe an accounting service, another one will work on billing or OSS, BSS, stop. And these things actually have a different release cycles and very often there is actually a release train that's blocked because in the monolithic world because these things have to wait or they have dependencies. But microservices allow you to break that. It's not about the amount of line of code, it's more about the functionality that's encapsulated that do one thing and do it well. And it's something, as I mentioned before, that has been existing for a long time. I don't know if you've done some credit checking when you write applications. There is Don and Brass Street, there is a lot of credit checking providers. They used to do that, I remember when I was doing an e-commerce app in 2000s, you could access them through XMLRPC or web services already. So that's a microservice. You could sell also the what-if scenario that you have running on the DLL. You can export it to Schwab and other brokers through web protocols. So that's the notion of web service is not tied to your language but is definitely something that is self-contained and that executes one function. It's not about the amount of code you have behind it. And scale independently, of course. So again, about size, a lot of people say, okay, it shouldn't be longer than 100 lines of code. I'm not going to use the word but that's BS basically. So you'll see here actually in some of the microservices will be showing later is actually very small but doesn't mean that it has to stay that way. Sometimes you have lots of functionality, sometimes you bring lots of dependencies, also libraries. So it doesn't mean microservice means microsize. Containers are becoming very popular. We've done and we have lots of documentation online. We have done some microservices architecture based on EAP6. So primarily deploying using containers as a deployment mechanism to deploy those kind of capabilities. Today we'll show you actually that not only you can run with the de facto container solution today, Docker, but also you can run it without Docker. Swarm actually is a perfect fit for that and swarm actually encapsulates things like and we'll show you in a demo capabilities that typical like SSO, IDM, it's not just providing an app, it could be backend services. So we'll take you through that. So not everyone wants to use Node.js either, so it does but and the reason is there's a lot of investments in Java. So today is actually a great window of opportunities for a number of companies that want to modernize their Java applications. So and again, if I take the first slides, how do you, what is the journey to take your existing E applications to actually move them to a modern infrastructure to decompose? So we'll take through the notion of decompositions and also run them into single executable jobs. So that's one of the the advantage of what flies swarm here. So stripping down EAP Wi-Fi is quite common. So very often you see applications and I don't know, many of you probably, you write an app, you'll probably just need JPA, JAXIS, and sometimes JSF of course for presentations. But those sets of capabilities are not the entire E stack. So you really want to have the ability to run in a higher density environment, especially when you run on clouds or different environments, you need to actually deploy just what you need. Okay, good. So we've seen actually evolution around the deployment mechanism. So we want to run our application, not just as a monolith application. We want to be able to decompose them. We talk about different release cycles. We talk also about different deployment model. Sometimes on Docker, maybe on OpenStack, on OpenShift. But from a developer perspective, you shouldn't be affected with that. Okay, so swarm allow you also to deploy artifacts in any environment you think of. You can actually deploy them whether as a war, you can still deploy on our Java E, co-located with all the services, or you can run them separately in a Docker instance or on OpenShift or anywhere else and invoke them. So that's one of the constituents that we've been looking into. That's a slide that Mark Little presented in 2010. I don't know if you remember. If you look at the follow-up, our keynote at Red Hat Summit. And at that time in 2010 is when we actually re-architected AS5 and AS6 to AS7. And one of the bigger change was around the module service container, especially around the dependency resolution mechanism, but also the modularity. So we started already to do that work. Yes, so you can actually just have EGB as a dependency and you just package that and run it as an executable job. So you're talking about the interaction. How do you have inter-process communications or inter-macro services? Yeah. So we preserved that level of isolation. So actually, white flight swarm is a subset of... We keep the white flight core and we bring those dependencies and we wire those dependencies on demand. And you'll see in the demo actually, we call them fractions. Actually. So you bring those capabilities that you need. You don't need to bring... So we've done that work. Actually, what you just said, we actually started to have that demand. We wanted actually with the evolution of... We're not just deploying on servers. We're deploying on different environments. And with the cloud, with the OpenShift, we had to rethink our footprint. We had to change the way we assembled those capabilities and give choice to developers to bring what they need. So white flight swarm, we call it also just enough app server. As you mentioned, maybe you just need... I remember when I was a customer, we used to do end-of-day processing for all our bookings or all our trades. And for each of them, we actually had a kind of a worker, farmer situation. And we will spin an instance with... We just need messaging and JPA, basically. So we get orders and we book them and we diagrate and database. We were starting a weblogic, a full weblogic server every time. Here, you just... You don't need that anymore. Now we're talking about a few tens of megabytes versus 1.5 gigabytes every time. Okay? So when you look at, especially when you do end-of-day processing in a trading environment, it's a huge amount of... You're churning lots of data. And when you look at how many instance you want to spin, the difference between a few megabytes and a gigabyte is... You'll see it quickly. It can change from ours and one data center cost. You can reduce that by a fraction of 10-fold, at least. So we use a lot of the existing Wi-Fi and the AAP in terms of self-contained services without wrapping it all in Docker. We also have, as I mentioned earlier, that's something we've done in 2009 with AS7. So we've re-architected it to make it possible. As Sebastien mentioned this morning, we follow the principle of convention of our configurations. We'll see, actually, later how we bring those dependencies in POM.xml from Maven. And again, we're trying to lower the barrier of entry. So how do you want to be productive? If you want to create a microservices, it shouldn't be more effort. Actually, it's a very simple exercise. It's not just JavaE also. It's not just JavaE also. So how do you cluster those services? So we bring also other works, other contributions from Netflix or SS, so like Reborn districts, and also LogStash. So how do you monitor all those services together? Other aspect where it could be useful, building E-application with limited capabilities. I gave the example where you just need messaging and JPA or JackSize and JPA or JSF. You need also a number of mechanisms like class-loading handling. We brought the notions that are close to HDI in AS7, so class-loading, isolation, modularity, et cetera. I'm not going to go into the flat path discussion, but I'll leave that for later. But basically, the goals are definitely around multi-tenancy and higher density and shared services. So that's one of the foundation of the work we've done. Again, as a representation, so white fly, when you create your jar, basically you bring only what you need, as opposed to a normal container, where if you just need JackSize, you still bring a number of unused parts, even if they're not wired at runtime, because since AS7, we do those resolutions at runtime, but they're still there. So by default, we provide a main, but you can override it. So I'll show you a simple example. And you don't have to touch the standard load XML, although some people have requested it, and I think that's something we can do. So how does it work? So typically when you do a JackSize resource, it's a very simple construct. That's in a normal E6 container. That's with white fly swarm. Same person. So spot the difference. So here there's actually no difference. With swarm, you actually don't change your code. As what I mentioned before, that's, we've made sure that actually the code you've already wrote, you want to decompose that application and modernize it. You're not gonna, we don't want you to touch that code. So those changes will revolve mostly around Maven. So Maven will bring a new plugin. So it's just with a package, a goal. So you can build as a wall or the jar. We also bring the fractions. So before you add the JPA dependency, you just have to call white fly, bring the dependency or white fly swarm. So we have actually, we name them fractions. So you bring those capabilities that you add on white fly and other project like OSS, a Netflix OSS, you bring them. You can also bring a full server, which will show you, actually I need to accelerate, but you can bring SSO IDM server as a fraction, as a capabilities. And Sebastian will demonstrate that. So we have fractions are white fly subsystem, white fly. Everyone knows white flies. I've been talking about white fly, I assume everyone. So it's our app server. So all these subsystems are brought as fractions. So they're defined as a module for jars and they're defined. And they also bring all the transitive dependencies. So it's much cleaner for the developer. So if you bring a Jack size CDI, then they'll bring, of course, Jack size and same for the rest. So that's a list of the currents. And I think it's even, it's growing. So it's probably even bigger now. But even, it's not just about the typical E subsystem and you find in white fly, but it's non-white fly also around. Just, as I said before, the Netflix OSS contribution, but also reactive Java and reactive NetE. So NetE is a project also we've been contributing heavily with Trostin and Norman. I mentioned you can also override your main. So by default, when you build a swarm application, it will bootstrap through a main. 99% of the case, that's enough for you. But you can also override it. So bring all the capabilities, maybe your own fractions. That's an example, for example. I think that's something you've done to secure and to protect the rest endpoint here. Maybe you can talk about this. Oh, yeah, that was just, I was showing in, how in six lines of code you can deploy your microservice with swarm and secure it. So basically we start a new container. We say we want to have JacksRS. We add our rest class that I don't show here. And then we say we deploy it and we secure it and we protect this path with the get method. You have to get the whole admin container start. Okay, we just double click. It will deploy this microservice and it will be protected. That's just small example. And oh, that's perfect timing. So it didn't mean to you. Yeah, perfect timing. It was for me actually to stop talking. But so I'm going to hand over for the code because we actually don't have much time but I think the bigger value is actually when you see it in action. So I'll... Yeah, so George, we have 18 minutes to build an old school app. From that, we will extract microservice. We will swarmify it and we will secure it. Do you think we can do it? Okay, let me grab my sheet sheet. Okay, of course, we will be using Forge. And then let's start by creating a bookstore app for those who were here this morning. It's a pretty simple app. You have a book, you have an author, and you have also an offer class to provide special offers. To do that, we just run a script, a Forge script that will just create the old app for us because it's not really in the scope of Swarm. So it's just to show you our nice Forges. And by the way, at the end of the talk, we will treat a gist containing all the scripts so tonight you can play with it. So here it's creating the app for us. Okay, here it is. Classic Java EE application. We can deploy it. It has been, it's just even a UI. It has been scaffolded. So let's deploy that to the classic way to a raw fly server that is running. It's deployed. Okay, let's just take a quick look at the app. Bookstore, awesome. We got authors, books, and we create offers. It took you 40 minutes to do that this morning. Yeah, I didn't have a script. And had to explain each step. So that's it. We have our app classic app. Now it's the thing. We have the offer. We want to extract that as a microservice because other applications need to consume that. And we want to be able to extract that as a microservice. And since offer is quite simple, it's maybe you can show it. We just have two fields, description and a name. Let's start from scratch. Let's start creating the microservice from scratch. So yeah, we're moving away from a traditional monolith app to actually start decomposing it. So with Forge, creating a new project is easy as project new. We call it offer. And first thing we will do is add the swarm addon. That will mean we're telling Forge that we want to use swarm. So the first change that it will do is change our pun.xml to add the swarm plugin. And everything, Forge will be listening to any changes that we are making to the code. And what we're going to do now is add a new entity. So you see the added fraction automatically. It detected actually the EAPIs and created fractions for it. So let's add a new entity and we call it offer. Okay, here we go. And here you can see that the swarm fraction JPA has been installed. So we have nothing. Maybe you can show the bum just to show that the fraction has been added on the fly. So you don't have to care about that. We, the Forge plugin, do that for you. Do we have, we need to add some fields to our offer class? So a name and a description. Okay, there you are. Now we have to generate the rest endpoint for this offer. So that's just one command as generate endpoint from entity. And here we point to our offer class. So, and here we go. We got our JAXA rest endpoint. Since web apps will be consuming it, we have to add course support. But I'm sure Forge has something for that. Yeah, cool. And we are done with our microservice. And we can build, yeah, we can run it. Build the jar first. So this will build a jar and we'll execute the jar. The wildflower jar. And the wildflower swarm plugin has been added when you did the wildflower setup. But at any time, if you do a maven clean install, it will create the jar for you. But it will also create a classic war file. So if you still want to deploy that in your wildflower server, you can also use the war artifact. But here we are running the jar. It's like we could double click the jar on Windows now. Okay, let's take a look if our microservice is deployed. It's an empty response since we didn't have any data. Oh yeah, and you prepared a small SQL script just to create some offers. So we have some content. So this one. You just have to run it again. Maybe you can show with Java jar or just to show the difference. So here is, you can see that he's making the war file. But under the hood, he's also made the jar file. So if you go in the target, we can see if maybe you can increase a bit the funds. So we got our offer swarm jar. And we can just execute that as a jar. So it's just Java jar target. Of course we can run many of them. We can do pass the port offset like in the wild fly. We can also run them with Netflix ribbon in a closer environment. We don't have time to demonstrate that. So if we refresh, we should have a list of... Look, okay, that's been injected by the SQL script. So our microservice is running. Now we have to change our old app so that instead of consuming his own service, it will take the offers from the microservice. It'll be really hard. So I'm not sure we're going to do it. Okay, so that's an Angular app that has been scaffolded. And here you could see before he was just... Local. Calling his relative pass because it was in the same war. Now we say, okay, you have to take the offers from this pass, the microservice that we just deployed. So if we deploy that again, though, here we do an old school redeploy. Okay, and let's make sure... And if we go to the offers... Here we have the offers. So we have decoupled our app. We could do the same with Boox, with other, with anything. We could create all mini microservices. There it is. Wow, the XXX offer. I don't want to know what it is. So remember someone asked you this morning if we could secure that? If we can secure that, let me think. Shall we do that? And we are going to secure that on the cool way by using Keycloak. For those who don't... As a swarm... As a swarm. Just for those who don't know what Keycloak is, Keycloak is a security server, authentication server that you can delegate all your security to that. Deserve a whole presentation. We don't have time to talk about that. But anyway, you should check that out. Swarm as support for Keycloak in two ways. It has a fraction called Keycloak server. And you just create an empty project and you just add the Keycloak server fraction and then it creates a jar containing a full Keycloak server. So we got one here running already. And what we are going to do is to update our microservice. And we are going to tell them you will be secured by Keycloak. So first step is to add the fraction Keycloak. So we have a command. If any time you have to add a fraction manually, we have a command here that lists all the existing fractions. Here we get Keycloak. We just click that. Okay, now we have two more things, two more steps before it's totally secured. The first one we have to provide a web.xml that contains security constraints and that's specified as a login method to be used will be Keycloak. Since we are running a bit short of time, we have that prepared for you. But as you can see, nothing really exciting. So we just copy paste that here. Maybe you can open it again so we can see. So basically what we say here is that it's a security constraint. We say we want to protect this URL. And only users with the role user can access it. And that's the other important part. We say the login method will be Keycloak. The second step is to provide a descriptor file, a JSON file, that tells our microservice where the Keycloak server is running, what the public key is, all kind of information. Again, it's not the scope of this demo, so we prepare that for you. But as you can see, nothing really exciting there. Just it's pointing to our Keycloak server, which is running as a Swarm app, as we call you. And that's all we have to do. I think you can build the app again. Yeah, this one. Yeah. Keycloak server is running. Okay. And if we go back to here, and if we refresh the page, and do we have a demo effect, it's fine. It's good we have five minutes. Should be okay. Where have you put the Keycloak.json? It's okay. Yeah, yeah. But it's so easy to just redeploy. Oh, here we go. Okay, we're almost there. And normally, now if we will refresh the page, it will say that we are not allowed. No, no, no, it's not. Our microservice is secured. You have to, you can only talk with this microservice if you're authenticated on your, through the Angular app. So now if we go back to the Angular app and we ask for the offers, it will probably not work. I hope so. Let's, oh, but we just see it was responsive. So it's not working. If we open the console, we will see it's not right. Oh, that's also out of scope of this demo. Now you have to enable Keycloak on the Angular side. And that's, so who could do that? Who could do that? I can propose something. I can, we will treat at the end the script to create these apps. And your session tomorrow, maybe we can. And tomorrow there's a JBLSForge lab. And there, if someone comes there and provides us the solution to enable Keycloak integration in Angular app, he will get a Raspberry 2, a really cool one. And I swear to you, it's really easy. If you're a bit curious, if you check the documentation, the Keycloak examples, you look for Angular, you should be able to do that. So if someone comes with his laptop and says, hey, I managed to secure that. Well, you will get that. That's the end of the demo. I think we are still one minute or two left for any questions, two minutes left for questions. I just summarized also. So that's the slides will be available. So also in addition to the gist, you'll have information. That's what we just did, to move from monolith to application, to full microservice. And if you really want to go deeper dive, if you're interested to look at those fractions like Netflix OSS projects, you have fully clustered environment, then you look at that Booker demo. So that's a really full blown demo, scalable, et cetera. Okay. So as a conclusion, of course, it's a fast iteration. We had Alpha 8 today. I think it's been released two days ago. You're very welcome to bring also your ideas. You can communicate with us. Wifi is a community. As Tim Burke this morning said, the team is better than the individual. So you're welcome to contribute through either Twitter, Wifi, Swarm, IRC, or look at the code and also share ideas with us. And if you want to participate to the little things we have, you can look at the gist, which is... Everyone can play except abstract J. You didn't hear me. So here's the gist, like... Hashtag, so people can find it back. I'll tweet it. Yeah? So you will tweet it right after. Actually, your project doesn't have to be forged. Enable any project, any Java project you can use while flying Swarm. We demonstrated the forge for the amazing productivity you get out of it. And you have all the add-ons. It brings all the fractions automatically. The same jars that it's using in the wild flight are also used in the wild flight Swarm. If you look at the jar that is generated with Swarm, you will see the wild flight jars inside of it. So it's like if the application server is put inside the jar, with all the modules that you need. And together with your application. Thank you. Okay, thank you. Thank you.