 All right, so microservices Can't hear me It's on it's just I have a huge head. Okay, so microservices wildflice swarm and how we can play a part in it So first of all I'm Bob McQuarter. I'm one of the co-leads for wildflice swarm and I'm a founder of the code house drools groovy torque box So microservices they're hot obviously we're talking about a lot of microservices here and the promises of microservices are kind of trifold We're looking at how to help define your architecture Great things can have independent release cycles and all of this leads to accelerating business velocity So your business can do the work of your business faster But all of this requires discipline One of the big things that you got to be disciplined about is bounded context And what this means is that each service does one thing it does it really well And in the old school way of doing things we used to call this a library, but it was a library It's probably now a service I like this picture because the service is a black box it has well-defined inputs and well-defined output And you just wire all these things together sounds simple, but Another thing that to be disciplined about is loose coupling And that means your implementations are loosely coupled You can't worry about the details of each implementation because you have your well-defined inputs and outputs That's your API now probably over the network and loosely coupled in terms of location You never know where your service is going to be running You don't know how many you're going to have you don't know where to find them. So we have to make this more dynamic But all this leads us to Conway's law Conway's law states that organizations which design systems are constrained to produce systems which are copies of their own organization Basically a monolithic organization produces monolithic software Okay, so we take that how do we solve that? We use the two-pizza rule The two-pizza rule says that any team Should be feedable with two pizzas. So that means I'm on a team by myself because I'm a large guy But most teams should be less than eight people And that includes the product manager So we're not talking about eight engineers plus another four QE and two PMs and a couple of marketing guys You got to have small focused teams And when we have to be this small and focused We can look at the example from the micro profile. We've all been talking about this week And these are the the services that we have created Within micro profile to demonstrate the whole thing. We have a service for sessions. We have a service for speakers We have a service for schedules. We have a service for votes. So these are abounded contexts But also when you're doing micro services, you got to worry about more than that Things like security and logging discovery monitoring But before we dive too far into micro services, we have some caveats If you failed at SOA, you're probably going to fail at the end of the week If you failed at SOA, you're probably going to fail at micro services If you failed at SOA, you're probably going to fail at micro services If you failed at SOA, you're probably going to fail at micro services It takes a lot of discipline and you can't just magically apply micro services and make it work Because really monthly weekly hourly releases. They're not easy Not if you're doing 200 of them every hour or every week or every month But there are things that can help you when you're attacking micro services Containers, I stick it in quotes because containers are things like Linux containers such as Docker and even uber jars Which is kind of a Java version of a container everything all together And we like containers because whatever is tested is exactly what you go into production Because if it's not you're building up entropy as you go from development to test to production And entropy is where things can fall apart But okay, how do I move this stuff from what I've built to being in production? We recommend CI, CD pipelines continuous integration continuous deployment Because if you're deploying continuously you should be building continuously everything should be non-stop and cloud Doesn't have to be public cloud. It could be private cloud Could be open shift on-premise could be hosted open shift could be host open shift anywhere It could be not open shift, but we recommend open shift Because if you're deploying a lot of things continuously Automated provisioning is very very useful. You don't want to have to email the IT staff to go set up a machine 40 times a day Plus things like open shift provide cross-cutting Cross-cutting functionality such as service discovery failover logging monitoring and the provisioning we just mentioned So you hook all this up on your CI CD pipeline and these are like layers of an onion or layers of your cloud You move things from your CI server, which is where your developers pushed to to see did you break stuff? Moving on into QE to staging into prod and what's moving through here are containers could be docker containers It could be uber jars, but some single artifact so that you know what's in stage one is the same thing That's in stage four. So that's one of hand-waving. I actually want to ride a microservice So how do I do that? Well first you do not have to move to Node.js just because you're doing microservices You don't even have to move to something. That's reactive like vertex, but it might be useful depends on the problem. You're solving and Let's say your Java double e developer as old as me 40 some odd years old, you know, I'm not going to go learn rust and go this week. I'm just not going to do it So that's where we bring in wild fly swarm Wild fly swarm. It's just like wild fly but swarm here So what does that actually mean? Wild fly swarm allows us to take the bits of the application server that you need Wrap them up with your application and treat it as a single artifact that can be deployed So you don't have to bring all the extra bits of the app server. You don't need you can still use all the Java double e APIs and more that you want to use and we stick it all together in a single jar that you copy around So if you're building something with a JSON API Really, do you need EJB? Do you need JSF? No, you don't So like I said, it allows us to wrap the app server around your app and chop off the pieces you don't need. I Love my black boxes. So here you have a war file. You wrote a war file a year ago, right? Simple service those JSON Jax RS You run it through wild fly swarm. You get your same app back, but a dash swarm dot jar Which you can now just execute it's your artifact and then if you want to drop that on a Linux container such as Docker All right, so that that's hand waving in black boxes. So here's a warning. We're gonna show a little me even may wish to cover your eyes We have a plug-in You add this to your existing war project You know it's already building a war file. You add our plug into it You run this package goal and you get a swarm jar out of that That's all you have to do in the simplest case because we will actually analyze your application We will notice you're using Jax RS and you're using JMS and that you're doing some EJB So we grab those bits and pieces and stick them around your application for you. We figure it out So I said Jax RS a lot But we actually support quite a few things, you know plain servlets Jax RS JMS CDI batch JPA Security transactions naming beam validation resource adapters Java FX Jam X And we can detect most of these things for you and just stick it into your application But if we can't do that or you wish to have more control and be explicit about what you're bringing into your apps So you know for sure what's going in You can also just start using Dependencies well that we hope are well-named so we have our org wildlife swarm group ID and the artifact IDs pretty much max The spec spec that we support Jax RS Jam X whatever Notice we don't specify a version Because we ship bombs bombs are our way of bringing in all these pieces to you and making them easy for you to consume But we realize we're always building stuff and some of our stuff is stable Some of our stuff is not stable. Some of our stuff might be deprecated some day So instead of just importing bomb, which is all of our recommended stable things We provide other bombs you can choose to import if you like to live on the edge You can start bringing in bomb-experimental and that makes a whole lot more artifacts visible to your build But if you only bring in bomb if we've marked it as experimental, it's not available to you your build will fail You know, I can't find the artifact. They don't have a version for it So we've talked about wrapping the app server around your app But then how do I configure that because my app server has a lot of configuration, you know I don't just use the app server and put my app in there I like to tweak it and tune it So if you've already used to wild fly like I said, we're wild fly but swarmier that means we can still eat your standalone XML You have you have handcrafted this this perfect standalone XML that defines your data sources your your JMS endpoints Your infinispan configuration for your caches You don't have to rethink that just give us that standalone XML. We will eat that when we Run your app and you can stick it on your inside your app on your class path Wherever you want to stick it the reference it by a file URL and we'll configure the app server of wild fly just like that Even though we've swarmified your whole app. I don't like XML because it's pointy and pokes me in the eye So we've also created a Java API that mirrors everything you can do in standalone XML So if you want to programmatically configure the app server through your own main you can Here's an example This is how you if you have your own main and you really want to own the app server you create a new swarm We've put every little bit of functionality in what we call a fraction you can configure those however you like We have helper methods like to create debug logging fraction gives you debug enabled for every logging category possible And then we use jacks or we use shrink wrap which allows you to programmatically also create deployments So you can deploy multiple things plinking and choosing classes from your app to create a different deployment Using shrink wrap and deploy it You can deploy multiple things here Okay, maybe I don't want to go so far as to write Java code boss. I don't want to write XML Well, we support properties and YAML to do a lot of this configuration because a lot of things You know configuring a data source is a stands of XML or a stands of Java. They're really it's a URL It's a host name. Maybe it's a username and a password. We can set all that through properties We can set all of that through YAML files So we support this file called project stages that YAML we auto located on your class path inside your app You can sell tell us what stage you're running in you can say I'm running in QE or production or any arbitrary name The first half is all the defaults If you otherwise not specified you get the top ones if I say I'm running in stage of production These override down here changes my JDBC connection URL Okay, so so far. I've basically talked about Java double e that gives you an app server wrapped around it What about the actually microservicey stuff? All right, I'm running it in the cloud. I'm running it on OpenShift I have it dockerized, but I have 200 of these things. I need a log Okay, we make it easy. All you have to do is include our log stash dependency Set two properties or two entries in your YAML file And now anytime you launch this thing it will reach out and connect the log stash and start dropping your log messages on it Then you can use cabana or whatever and view those things All right, I have my microservices. I I want them secure, you know So we like key cloak. It's our single sign-on server. It uses OAuth2 from Red Hat SSO is the product that we sell based on that You can include this dependency Get the key cloak.json from your server put it in there And then you can very easily secure every deployment every microservice and say, you know I want to protect this microservice I require that you're authenticated and have certain roles and This thing will double-check all the Cryptographic signatures of the JSON web tokens that might be flowing in from your UI And we make it easy one dependency bring one file over and now your services is secure We also deal with discovery because that was one of the things you have to worry about with these things You have 200 of them. How do I find them? We have this concept of topology Which is how do my services find all the other services running in the constellation? We support J groups, which is the normal wildfly way of finding its neighbors We support OpenShift using Kubernetes to find where my neighbors there, you know where these things running We don't have to know we can ask Kubernetes We support hashi-corp's console registry, which is when a service comes up It goes to a simple registry Registrates itself says I'm over here port 9090 or whatever and other folks can go look it up And then we integrate this stuff with Netflix ribbon So if you're using ribbon to do client-side load balancing It's topology aware and you say I just want to call the service named Bob And our topology comes up with the ordered list of these things that you can round robin through or whatever load balancing strategy You want to use using normal ribbon mechanisms So the bottom line from my point of view Being a 40 year old Java developer is that Java double E is a perfectly acceptable way to write microservices And given the things we've done with wildfly swarm. I think it's an awesomely fantastic way to write microservices And from the announcements that we've seen here this week I think micro profile is going to make this really easy and make it portable So you're not locking your way itself into any particular vendor if you turn around don't do it right now There's my VM and they have their micro profile sign And there are a couple of other vendors here Tommy tried and we're all pitching in trying to make Java Enterprise Java worked well for microservices and wildfly swarm is our way of doing that and if you just want to use micro profile and you You just say I want to use micro profile add this dependency and you now get this version of swarm that supports CDI Jaxrs JSONP Or just auto-detect just write it an app that is compliant to micro profile only use those APIs that are in micro profile Like I showed in the very beginning add our plug-in and we'll build a micro profile app for you Right now micro profile 1.0 includes this We had a meeting two days ago where we're trying to define what micro profile 1.1 or 2.0 might look like as This list is going to grow and it's going to go not just bringing in more of Java double e It's going to go beyond that it's going to solve problems that Java double e has not solved that we face in the microservices world So that's 70 slides of 15 minutes my personal best I believe but here the resources we have wildfly swarm We are open source Apache licensed. We're on github We have a whole repository full of examples that show you how to do all sorts of things using auto-detection or writing your main file Or using YAML files and standalone XML We have a website we hang out in IRC because as mentioned, I'm 40. I like IRC. I don't know what slack is Apparently the new hipster IRC Maintain issues on JIRA and we have a Google group So if you have any questions find the tall guy, that's me or the Australian guy That's the one over there who sounds Australian We'll be glad to talk to you and if you'd like to hear the same talk again slightly slower I'm doing it tomorrow. I think at 11 30. Thank you