 Hello fellow developers, my name is Matt Ravel, and I'm a developer advocate at Okta. Today I'd like to build an application with you and show you how to create a microservices architecture with Spring Boot and Spring Cloud, and we'll be building a service that allows you to filter out good beers from bad beers. It's a personal passion of mine. I always like the good beers and from Colorado. So let's get started. The script I'm going to use for this tutorial is already in a blog post on the Okta developer blog. You search for micro brews. You'll find it here. You'll see it's from June 15th, 2017. And so you might think that's old, but good news, I recently updated this for Spring Boot 2 and everything should be up to date. The blog post starts about going through the history of microservices, why or why you shouldn't use them, and I'm gonna basically skip over that and just show you the code. But it is important for you to consider whether you really need microservices because a lot of times it's about scaling teams, not about actually scaling technology. So it says to create a Eureka service. Eureka service is basically a discovery mechanism that your microservices can register with. And so you need to have that up and running so they can basically talk to each other. So it says here to create a Spring Boot microservices example directory. I'm just gonna go ahead and call it apps since that's a little easier to do. And then you'll notice here, it says go to start.spring.io and to Eureka service as an artifact name and select Eureka service as a dependency. So I can do that, but at the same time, what I like is that they have an API. So if you went HTTP start.spring.io, you'll see what that API looks like. So you can see all the different dependencies that are available. And of course you could say, okay, what's JPA called? And I'll show you that's called data JPA, right? So then if you want to actually download and extract from the dot zip endpoint, then you can basically create an application very easily using the REST API. So I've created aliases to do that. If I show you my Eureka server as alias, you can see this is what it looks like. It goes and grabs a Eureka service app with that dependency of cloud Eureka server and extracts it to a Eureka dash service base directory and then untars it and so everything just works. So we can see the end apps and then Eureka service and I'll go ahead and create all that for us. The next app we need to create is a beer catalog service. So the beer catalog service is going to be a microservice backend that has a list of beers and it's very dumb and it just has those beers in it and that's about it. So that alias has a number of more dependencies. It's got actuator, cloud Eureka for discovery, JPA, H2, DataRest, Web, DevTools and Lombok and we'll put it in a beer catalog service directory. So go ahead and create that one. And then the last one we're going to create is an edge service and you might think of this as like a gateway which basically is the front end for all your backend microservices and this will delegate to those backend microservices and in a later tutorial I'll show how to actually lock those down with OAuth and JWTs but in this example I'm not going to add any security and this edge service is merely going to talk to the beer catalog service, get the list of beers that it provides and then filter out the ones that aren't so great so you get a good beer service. So this has a similar alias, edge service and you can see in this one we're going to use Cloud Eureka for discovery, Cloud Fane, what that allows us to do is actually talk to the downstream microservices. Zool will allow us to route to microservices if we actually don't want to do anything fancy and we just want to proxy some URLs down to other URLs. DataRest, Web, Cloud Histrix, Histrix will allow us to do fallback methods and make our architecture a little more robust and then Lombok and we'll put that on an edge service directory. So run that one and then I'll open up IntelliJ to do all the work to basically add the code and make all these talk to each other. So while that's opening up you can see that the first thing we need to do in the Eureka service is modify the application up properties to set a server port, Spring Boot uses 8080 by default so we want to change that to the recommended de facto standard for Eureka which is 87.61 and then we'll set Eureka not to register with itself since the default is true when that's found in the class path. So if we look for application.properties you'll see here that we do have one. Put those in there, let me make sure I'm using the right font size for this. Search for font, I'm gonna change this to screencast so it's a little bigger, a little easier to see. So now you can see that a little better. We'll put this on the left, put this guy on the right. All right, now here we go. So once you've done that the other thing you need to do is just say hey enable Eureka server. So this is gonna be in, wrong one. Eureka, set up our SDK, Java 8, and then the Spring people like tabs, I like spaces. So there we are. And then we could start up the registry right now and be able to see everything. So if we do that in terminal, CD Eureka and Spring boot run. So now if we go to 87.61, you'll see what the UI looks like and there's no applications registered. So now we'll create a beer catalog service. We already created that. These are the dependencies like I said earlier. And we're gonna start with a beer entity. So we'll find the beer catalog service application.java. And we'll go ahead and add an entity. So the reason why nothing's resolving and it actually doesn't say right here that this is a Java classes because I haven't added these as Maven projects. So I can go in here and add the Eureka service. Go and add the beer catalog service and then add the edge service. You might remember when I opened this project in IntelliJ I used idea space. That's from IntelliJ's command line runner or launcher that you can install using tools command line launcher. And so now that I've configured everything it recognizes as a Java project. I can go ahead and delete the beer entity and recreate it. To create it, I'm using live templates. So you'll notice all I have to do is type in boot dash entity Lombok and then it fills in the class. And that's because I pre-recorded these. So all I'd have to do is type in like the entity name. And so under preferences live templates is where you can find live templates that IntelliJ provides as well as add your own. So it's under the user area and you'll see I have boot entity Lombok. So I put those variables in there and that's how you can create your own. It's pretty handy feature. So now that we have the beer we can go ahead and create a beer repository. And that extends JPA repository which allows you to do crud on the entity, create read update and delete. And I'll also add a repository rest resource annotation that takes the end points and exposes them so you could do crud from a HTTP client. And lastly I'll create a beer initializer or command line runner that will populate the database with a sample list of beers. So these are the top beers I found on beeradvocate.com. Of course you could plug in some different ones if you want to see some different names. I will run this application and you can see the beer names are printed out just as we suspected. So put them in a database and we were able to use our repository to fetch them and print them out. So now you'll want to give your application a name for Eureka. So it's a report 8080 you could remove that if you wanted since it's default and spring application name. And that's just so it shows up in Eureka with that name. See right now it's got the unknown name. So after restarting this then we'll see your catalog service as the name. So that's all working as expected. Exposing those endpoints with repository rest resource allows you to hit the endpoints with something like HTTP which is similar to curl. I used to be IE so you can go to 8080 slash beers and you'll see that whole list of how to use URLs and all the various beer names. So the last thing you'll want to do with this service is enable discovery client. Now you'll notice it did register with Eureka without this command and or without the sanitation. So from the research I've done online it just appears to be a best practice to enable it and everything will work together better if you have that on there. So prevents bad things from happening. The last thing you'll want to do is create an edge service or modify the existing edge service that you created. First of all to run it on 8081 and to have an application name of edge service. So find the application.properties for the edge service and copy those values in there or type them in there however you like. And then you'll want to enable feign, histricks and registration with Eureka server. So there's a bunch of annotations that Spring Boot provides for that in Spring Cloud. So add these to your edge service application and then you'll create a beer DTO just to basically hold the name that we're gonna bring back. So you can do that with a data object from Lombok. Basically provides those getters and setters and two string and all that for you. Then you'll create a beer client interface that basically leverages feign to talk to that downstream beer catalog service. And then you'll create a good beer API adapter risk controller because we like long class names. And this one will basically use that beer client to read the beers, get the content, stream them and filter out the ones that aren't great and then collect and return that list of just the good beers. And the get name is highlighted in red there just because I don't have the Lombok plugin installed for IntelJ. So as long as you're running the application from the command line with Maven shouldn't be an issue. If you do want to adjust your ID you can install Lombok or the Lombok plugin and refresh Eureka. And now you can see it's registered with Eureka. And so we should be able to hit the 8081 good beers endpoint in a browser. If I can type it right. And there we are, a nice easy consumable list of plain old good beers. So one of the things that Spring Cloud provides with Histrix is the ability to actually, have data that doesn't return a 500 error. So if we shut down the beer catalog server and try to get to it after it's shut down you'll notice we get a 500 error. So with Histrix what we can do is we can define a fallback method. And that fallback method will allow you to return default data instead of a 500 error. So 200's always better than 500. So to do that you can go into the good beer API adapter rest controller and add a Histrix command fallback and point to the fallback method. So in this case we're just gonna return an empty array list. You could obviously can a few good beer names in here as well and your clients wouldn't die. They wouldn't get a 500 error. They'd get a 200 error which is obviously a lot better. So restart the edge service application since that's where we made the change. Now when I refresh my browser it's just an empty array list. And so we could restart the beer catalog service and once that's up and running again then we'll actually get that list of beers returned. So this takes anywhere from 20 to 30 seconds in my experience. Doesn't work very well for demos because you're just continually, continually refreshing and refreshing and refreshing browser until you get the actual list of names. So you've built a microservices architecture now that has built in resiliency and failover but there's no client. So I always like to add a client. I prefer Angular but I also dabble interact. And with these instructions here you can see that you can basically clone the client from previous tutorial and go ahead and import that or copy the client directory into your project. So the easiest way to do that is actually not using GitHub it's using SVN, there's a command. GitHub actually supports SVN so you can use SVN export and export a single directory onto your or into your actual project. So I'm gonna grab this link here and figure out the right URL. Basically leave it, you put trunk on the end and then client and so I can take that and do SVN check out just for that client directory and it'll put that right into my apps directory and into my project. So the first thing when you clone an Angular project or any project that uses NPM is you have to run NPM install. While that's running in the background we can look at the changes that you'll want to make or the changes that I'll make in this project. Basically I'm changing from using port 8080 to 8081 since that's where our edge service is and the first time I try that it's actually gonna fail because it's making a cross origin request. So in edge service application you can allow cross origin request from any client by adding this cross origin annotation then restart the edge service and I'll change the beer service to talk to 8081, save that file and I can run NPM start to actually start the client that will talk to the edge service and once that's done compiling you can open up localhost 4200 and you should see the list of beers in there. There we go. If you followed along congratulations and creating a robust microservices architecture you can deploy this to Cloud Foundry if you want you just have to add some application dash cloud.properties files that basically use Cloud Foundry's Eureka registry instead of the one you created and so to make that easy I actually went ahead and created a deploy.sh script that automates everything so I had some help from this or help creating this from Josh Long and it basically just builds all the different projects and pushes them to Cloud Foundry and configures them to talk to each other. So if you wanna see a video where Josh actually live coded all of this from DevOps France in 2017 you can and the source code for this is all on GitHub under spring boot microservices example under the octa developer org. I hope you enjoyed yourself watching this video and learned a great deal about how to create microservices with spring boot and spring cloud.