 I'm not going to use the microphone. If I'm not a lot enough, just let me know. So if you're here, you're here to hear about cloud-native application development with Spring. So we're going to be talking about that today in a little bit of cloud foundry as well. A little bit about myself. I'm Kenny Bostani. I am a Spring developer advocate at the Hiddle on the Spring team. I joined back in September. Before that, I was at Neo4j, their graph database company as well as digital insight. I choose to be into it. I'm writing a book right now with developer advocate, John Schwann. It's called Cloud-native Java from O'Reilly. You can get an early release of it today. This book is all about building cloud-native JVM applications and microservices using Spring boots, Spring cloud and cloud foundry. Also, I am from Silicon Valley. So I live in San Mateo, California. I'm doing a trip through APJ. I went to Tokyo, SEAL, and now Singapore, I go to Las Vegas tomorrow. Alright, let's do that all again now for the... I'm kidding. Okay, so yeah, I'm headed to Las Vegas tomorrow to go to EMC World to give a talk. It's a busy schedule. Today, for our agenda, I'm going to talk about microservices primarily, talk about cloud-native applications, talk about Spring boots. Who's using Spring boot today? Wow, who's using classic Spring framework? Who doesn't use Spring? Okay, so we'll talk about Spring boot. We'll talk about Spring cloud. Spring cloud is a tool set that we provide in the Spring ecosystem for tying together your distributed applications. So if you have a lot of microservices and they're Spring boot applications, you can use Spring cloud. So we're primarily focused on Spring cloud today because that's how you build cloud-native applications. We'll talk a little bit about REST. I'll show you an example architecture of 10 microservices I put together. This is a cloud-native application, which is an online store. So I'll show you that. Okay, so let's start with microservices. So when we talk about building microservices, we have to really look back and see what our application architecture looked like before we embarked on that journey. Who here today is working on microservices or looking to adopt microservices? One, two, three. Okay. Well, it's going to be a very boring presentation. Okay, so we started with a monolithic application pattern. And with a monolithic application, we have our users coming in and they're accessing our application as a web application that's deployed to an Apache Tomcat server or a Java application server like IBM WebSphere or Apache Tomcat. There's a few different ones. So with this model, we're going to have our development teams organize and work on modules in a single deployment. So here we have a war file deployment. In a war file deployment, we might have different components. So we have modularity. Here we have the storefront UI, the accounting service, the inventory service, the shipping service. And if we have a large engineering team and they're all working on the same application, the problem is there are going to be a lot of conflicts. So the velocity of getting into production is going to slow down, right? Another problem is that when we have an application server deployment, we have to set up provision virtual machines, install the application server to those machines. It takes a lot of time. So that's something that we want to prevent if possible. Also we have a bottleneck here, which is our relational database. So typically what we'll have in organizations is we'll have DBAs who are managing the database schema. If we have any requests or any features to modify the application and it requires to change the database, we have to make a request, we have to go through gatekeepers, we have to go through reviews. And it's two months before you get anything done. And so this is a very inflexible model so we can do better. So we decided to move to a different kind of architecture, which is a service oriented architecture. So now instead of one monolithic application deployment where everybody's working on the same code base, we have more services that we're deploying. So we have independent deployments. Here I have the accounting service. I have the inventory service. I have the shipping service. And I have a set of domain resources where I'm sharing between the services. We have a single service team typically working on each service, but you can have individual service teams work on these applications. So we've removed one bottleneck, which is that we have one application deployment. We actually can scale these applications independently as well. But the problem becomes now that instead of one large application deployment, we have a few different application deployments that we have to coordinate at the same time. Because we have these resources here at the bottom that we're sharing, if I make a change to the customer or account or address record, if the accounting service owns those records, then the inventory service has to account for that change. So now with the complexity of this architecture, if I make a change anywhere in the resources that we're sharing or the shared libraries, I have to deploy multiple services at the same time. So I have to coordinate multiple releases instead of one large release that takes a lot of time. And so this is still an inflexible model, so we can do better. So we've arrived at microservices, which is this application pattern where we kind of analyze the monolithic application deployment. We've analyzed the service-oriented architecture, the shortfalls of these application architectures, and we've come up with a better model. So here we have, as a rule, each team and organization is going to get one service, one application, and one database. And the idea here is that it's more flexible. So when we have a team of developers working at a company, and they're organizing around business capabilities, that is, they're organizing around certain features of the business that they want to have implemented, for instance, here we have a movie application where I have a user service, I have a movie service, a rating service, a recommendation service, and an analysis service. And so each one of these represents a team, and we can deploy these applications independently of one another. So I don't have to coordinate my deployments anymore, because I'm going to use integration tests across all of my applications to make sure things are correct before they go to a production environment. I'm going to have my consumers drive those tests. So if I'm a movie service here and there's a dependency from the rating service, the movie service is going to have a set of tests that are implemented by the rating service. They're defined by the consumer, and those tests are going to run when this application goes through its deployment pipeline. So before this application gets to production, it needs to pass a series of tests that were defined by the rating service. This is called consumer-driven testing. And so what happens here is that the movie service wants to move at their own pace. They want to implement breaking changes and screwing one's life up. But what's going to happen here is they can't actually get into production unless they pass the consumer-driven tests. So the rating service is going to be the one that the movie service contacts and says, hey, we have a problem. So culturally, things change where instead of moving at your own pace where everybody comes to you and says there's a breaking change, your consumers are going to drive that. So you're going to have to go and talk to the rating service and say, hey, there was this problem with your consumer test. We need to fix that. And so there's a lot more work here for this application and work with other teams that depend on it. A big difference here is, too, is that I'm going to choose the database that I want for my use case. This is called polyglot persistence. And so if I want to use, for instance, for the rating service, I have a very connected data model. If I want to use a graph database which is a connected data model, it's going to use a graph model in the database, I can go ahead and choose that application, the database, and deploy it myself. As a team, I'm going to operate my own software. So I'll deploy the rating service. I'll deploy the database. I'll manage that myself. So we don't have a central DBA who's managing these changes anymore. I can choose a different database for any one of my services. So at the bottom here, we have the recommendation service, and I'm using MongoDB. So I can choose the database that I want. Another thing about microservice architecture is that I can also have shared resources. So we have a couch-based document database in the center. And I'm using that as a centralized cache. So I can also share resources. One of the problems that we have with a microservice architecture is that we move away from a monolithic application transaction model, where if I have a database transaction, something fails, I can roll back to a consistent state within the scope of that transaction. So now my transactions are spanning multiple applications, where I have to keep track. Let's say that a user rates a movie. Well, I might be touching data in each database. So I need to worry about how I roll back my transactions that are now distributed. So I can use another shared resource in the middle. I can add something like Apache Kafka. And I can store an event log. So every application change that requires to change the state can be recorded in an Apache Kafka instance. I can have an event log where I can roll back across multiple services if I give my application into an inconsistent state. So typically people ask, how do I understand conceptualizing this migration to microservices from a monolithic application? So in the book, I describe a method where you can actually take your monolithic application, turn it into a series of microservices. So here in this example diagram, we have a budding microservice architecture. And in this architecture, I have my customer service, which represents my backend application. So this is the data service. You can see that it's connected to a MySQL database. We can see what the schema looks like. We have an account record, a customer record, and a user record. And what we'd like to do is to transform this customer service into multiple applications that we can deploy independently. So we've already started that process. We've created this is an online banking application. We have our front end here. Now, we've extracted out the front end, which used to exist in the customer service. And we've created a new application. So this is just going to have the front end components. And it's going to integrate with the customer service over REST. So maybe I have an AngularJS application here. It's going to use a REST API that's exposed by the customer service to display data to the user. I've also added in some cloud-native application components. I can see at the top that I have the discovery service. This is going to allow these applications to find each other when they get to an environment. So if I deploy the online banking application, when it starts up in an environment, it's going to contact the discovery service. It's going to provide information of where it can be contact on the network. And the discovery service is going to maintain a registry of all the applications in an environment. So we provide this with Spring Cloud. Also, I've added a configuration server. This is going to allow me to centralize my configurations. I can use a Git repository to do so. I can store a file for each one of these services, an application properties file. So when it gets deployed to an environment, it'll contact the configuration server. It'll grab its configuration, attach it, and start running. Also, with a configuration server, I can go ahead. I need to make a configuration change with applications that are running. Let's say I have 10 instances of the online banking application. I need to make a config change. I can go ahead and check that into the Git repository. The configuration server will notify all the applications in the architecture that depend on that configuration. And they'll take that new configuration in and reload. You don't have to restart the application. So the next step here, if we want to split this customer service into more microservices, we might want to choose one of these tables from the database and create a new application out of it. So what I've done here is I've migrated the user table that used to exist in the customer DB, which had all feature functionality related to user-level authentication. I've refactored that out of the customer service, and I've created a new application called the user service. Now for any functionality related to users, the user service inside of this application, I've now rerouted it to the user service. And I don't need to go and edit manual configurations or add new host names. Because these applications are able to use the discovery service, I can add as many as I want, and the discovery service is going to take care of how these applications find each other. As long as I give an ID to one of these services, they'll be able to find each other if they depend on each other in an environment. So with cloud-native applications, there's really one set of methodologies today that a lot of people use when they build applications, and that's called 12-factor application methodology. Who's heard of 12-factor apps? Don't be shy. Right, I have. Okay, so I'm going to go over all 12 of those now. I'm kidding. I'm just going to go over two. And the first one I'm going to talk about is configuration. So the main thing that changes here is that we have a single code base, and we're separating out our configurations. We're going to store those in the environment. So we're not going to store any configurations related to the environment inside the code base. We're going to take those and store them in the environment. And here, with Spring Cloud, we can use the configuration server to do that. So what a 12-factor application really is, is it's really a set of methodologies that allow us to deploy, build an application and deploy it to any cloud platform, such as Cloud Foundry, for instance. So this is the first step that we're going to do. We're going to take our monolithic application. We're going to separate out all the configuration and store it in the environment. The other one is that we're going to have that we produce, one code base that we build, and that artifact is going to be deployed to each of the environments. So I'm only going to build once. When I build once, I'm going to have that same artifact. When it goes into Dev, I can promote that to QA, staging and production. But I'm not going to rebuild that application in each environment. There's only one build that happens, and we promote that to the other environments. So when we're building cloud-native applications, there's really only one great framework that I recommend, and that's Spring Boot. And Spring Boot really is a JVM framework for building microservices. I really need to get a clicker. Okay, so what is Spring Boot? So raise your hand if you've seen this famous diagram. It's famous. Promise. Okay, so Phil Webb, he's the co-lead of the Spring Boot project. He helped found the project itself and explained the difference between classic Spring Framework and Spring Boot in one simple diagram. And he said that, well, Spring Framework really is just a set of ingredients that when you compose together, you get a finished baked cake. But the problem is that we have to bake our cakes ourselves with the classic Spring Framework. And what ends up happening is that developers spend all their day in XML rather than in Java. So Java developers pick up a competency of being an expert in XML, which is not very fun. And so with each one of these ingredients, for flour, for instance, might represent Spring Security, or eggs might represent Spring Data. So we have all these projects in the Spring ecosystem that Spring Boot, simply what it does is it composes them all together into a finished baked cake. So instead of having to configure your own beans in your Spring container, Spring Boot is going to do that for you with default configurations. And you're going to use annotations now instead of actually jumping in XML and making a lot of changes there. You'll use Java-based configuration. So when it comes to actually baking these cakes, we provide something called the Spring Initializer. And the Spring Initializer is really an open-source project we have as a website. You can go to start.spring.io where we host an instance of it. And you can specify what your ingredients are. These are called starter projects. So if I want to build a web service, I can use web, JPA, security, actuator, rest repositories. I'm actually going to build that now so you can see. And you can download this application and start it immediately. So if we go to start.spring.io, so here's the Spring Initializer. This is just an open-source project that we provide, meaning that if you want to deploy your own instance of it at your company and customize it, you're more than welcome. So the basic gist of this is that I can put in my dependencies here. Let's say that I want this to be a web application. I can embed an Apache Tomcat server inside my jar artifacts. So I'll choose web. Let's say we want to use Spring Data JPA because we'll connect to a MySQL database. We need a MySQL database driver so I can use H2 here. I can also use MySQL, but the idea here of using H2 is that if I'm going to do unit testing or integration testing, I can embed an in-memory instance of VH2 database, and then I can run execute my test against that database. I'll also choose rest repositories because I want to have a rest API be exposed for my data model. I'm going to choose Spring Boot Actuator. This is going to map a series of endpoints to my rest service, which is going to expose operational metrics from my application. Also, I want this to use the discovery service, so I'll go ahead and specify Eureka discovery. I'll just rename this to user service. And up top here, you can choose if you want a Gradle project or a Maven project. I'm going to choose Maven, and then I'm going to use the current version of Spring Boot 1.3.3. So I can go ahead and generate that project, create a compressed file here, which I can open up. You can extract it, and I'm going to show you the finished version of this. So you're going to get a series of files here. So this is just basically a Java project. We see here the source directory. We have a target directory, because I've already built this. We also get a Maven wrapper, so I can actually, instead of having to install the version of Maven that I specify with my Spring Boot application, I'll get a wrapper, instead. And so I'm going to go ahead and run this application. So I will use Maven Spring Boot Run. This is going to compile the application and start it. And so if I go to that application, it's going to be localhost80. Actually, it's going to be dynamic. Let's try that again. One second. This is how many times I've done the demo this week. Quite a bit. All right, so let's go to eight. Okay, let's try that again. Okay, so we can see that the application started up on port8080. So I'll go ahead and go to localhost8080. And we can see that I have a hypermedia response here from that application. So this is just a default response. So we use hypermedia. This is HadiOS. It's going to provide a series of links of how you can work with this application as a REST API. I have actuator on here. So if I go to forward slash actuator, I can see all those operational end points. So I can see I have environment. There's a lot of them. But I'll go over just a few. If I go to ENV, I get a list of properties and environment variables for the application environment where this application is running. And I can see all those system properties of my machine. So here we can see my AWS secret key somewhere in here. But it's obscured. So I see that automatically Spring Boot will detect. It'll look at the name of the environment variable and it'll obscure anything that's sensitive. So this is very useful in a production environment. So you can see information about the application running an environment. One of the other really helpful end points is the metrics endpoint. So here I can see information about my application, how it relates to the JVM, the heap size, how much memory is free. I can see my thread count and my thread pool. I can actually do a thread dump as well. I can see the amount of classes that are loaded. I can also see how many times a user's access of a specific endpoint. So we can see here that I have actuator the amount of times that it responded. That doesn't seem right. I've run this application a few times. So let's go back to actuator. There's also health. I can look at health, basic health end points. So here I see information about this service running. We can see that I've added Eureka Discovery as a client but it's not connected. So you can also see the database. See here. I'm using H2. So this is the basic idea behind Spring Boot. It's very easy to generate these applications using our spring initializer project as a finished application and run it and start to configure it. So it's very popular today. Back in January 2015 we had just under a million downloads a month. Today actually we're well over 3 million. This was in December which was 2.25 million. So that's a tremendous amount of growth in the application framework. And the reason for that is that microservices have become a very popular pattern for a lot of companies and they're adopting Spring Boot mostly because they have Spring competency but it's designed for microservices. So you can rapidly build these applications at an increased velocity and you don't have to spend all day in manual configuration. So the other thing we're talking about today is Spring Cloud. So Spring Cloud is another ecosystem project that we have and so this solves the problem of building distributed applications. So with Spring Cloud we really provide a set of integrations. So most of all we have the Netflix open source project. So we bring in a lot of the Spring Boot based applications or Spring applications that are in the Netflix open source ecosystem like Zool or like Eureka Discovery. And we create integrations for those with Spring Boot. We also provide a lot of integrations with Amazon Web Services with Cloud Foundry and we also provide discovery options with Apache Zookeeper and Console. So this is very popular as well because it provides a lot of these patterns, these operational patterns that you need when you build distributed applications and so some of the patterns that we provide service discovery which I'm going to go over in a second. This allows applications to find each other in an environment. So when you have a lot of these backend microservices you're going to need a way to expose a seamless REST API to your front-end application developers and so we have an API gateway that you can use to string them together. We provide a configuration server so you can centralize your configurations in an environment. You can run this service. It can serve your configurations to each of your services in the architecture. We also provide circuit breakers which is an operational resiliency pattern. With circuit breakers let's say that you have a large microservice architecture, 500 plus microservices and you have one of those microservices is a critical dependency meaning a lot of your applications are going to have that as a dependency. When that becomes the case, if that service goes down then you're kind of screwed, right? All of your applications are going to go down. So we provide circuit breakers which is a way for you to specify a default fallback functionality. So if the circuit is tripped and there's a high velocity of errors it's going to fall back to this default functionality. So your applications can still function. It's just going to have some default fallback functionality. We also provide distributed tracing integration with Zipkin so you can visualize how your microservices are communicating with each other which becomes a very simple way to debug these applications. So when you have all this complexity it's good to have something like a Chrome developer tools to actually visualize how these things are communicating. So I'm going to go over each one of those patterns in a second but going back to Phil Webb's wisdom on the difference between Spring Framework and Spring Boot, he had another tweet which said, well, if this is my Spring Boot application, Spring Cloud is just a lot of cupcakes with different flavors. And so what that looks like here, let's say we have our three cupcakes. We have the recommendation service, the movie service, a configuration service, and a discovery service. So I'm going to go over how the discovery service is used in this scenario. So let's assume there's a dependency between the recommendation service and the movie service. So with service discovery these applications, the recommendation service and movie service, they're going to find each other in the environment because they're going to use the discovery service which is going to centralize information about these applications. And so here we have our service registry. So when an application starts up, it's going to contact Discovery Service. It's going to provide information of where it's located on the network. And the discovery service's sole responsibility is to maintain the service registry. And this is kind of like a phone book. So this phone book is going to have the IP address, the phone number of where these applications can be contacted. Also it's going to serve a list of instances. So I can actually do something called client-side load balancing which is that if I want to load balance between applications from the client side because I have information related to each instance. So I'm actually going to demo this. So using that user service let's go ahead and add in another application. So what we're going to do here is we're going to add a Discovery Service. We're going to add a client application that's going to contact the user service and we're going to scale multiple instances of the user service. And we're going to see the user client application automatically load balance between these services. So what I'll do is I'll go to start.spring.io I'm going to specify that I want Eureka. So I'll choose Eureka server and I'll go ahead and generate. So I have the finished application here. So if we look at the POM XML we'll see that the configuration that was generated will have a Spring Cloud Starter Eureka server. I also have a Spring Boot Starter test. We have unit testing built in. My parent dependency here, my parent build dependency, this is a bomb and this pulls in all the Spring Cloud Starter projects. We also have a Spring Boot Starter parent which does the same just for Spring Boot Starter projects. If I go to the application class here I can see there's not much going on. There's just one Java application class and here we have enable Eureka server. This is going to enable this application as Eureka server. It's all I need to do. I'm also going to go into the application properties. I'll name this discovery-service and I'll set it to a default port of 8.7.6.1. Now I'm going to go and start that application. We can see that it's started up. So I'm just going to go to the browser now. If I go to local host 8.7.6.1 we can see the Spring Eureka UI. So this is started at Netflix and we create the integration for it and so this is just one of the three discovery services that we provide. So what you'll see here in this user interface is just some information related to our application instances that are registered. So you can see here there's no instances that are available or registered. So what we want to do here is we want to add in a user service and a user client application. So we downloaded the user service earlier and I've since gone ahead and while you weren't looking I added up some code in there and what I want to demonstrate here is that we had that Eureka starter project. So I'm going to add an annotation here at the top which is enable discovery client. That's going to automatically enable this application to contact Eureka and register with it. I've also added in a basic REST controller here and why I've done this is I just want to show how this application is going to load balance and so what I've done here is I've mapped out port to property of field here which I'm going to return at the default endpoint. So we can see the application port that this service is running on. So if I go ahead and start that up so we can see that it started up I got to restart sorry my bad this is I'm going to sign it a port of 1111 just to make things simple. So we can see that it started up on port 1111 and we see that it also contacted discovery service and registered. So we see a 204 success. So if I go back to Eureka I had it up didn't I? If I refresh it now we can see the instances that are registered. So discovery service went ahead and registered itself and then we see the user service which is registered and here's how I contact it. So I have a link here where I can open up that application and it's going to give me an error which is fine. So if I go to the root endpoint here now I see 1111. So what we would like to do here is to add another instance to Eureka. So I'll go ahead and run another application. I'm going to sign the port 1112 now if I reload Eureka I can see that now I have two instances that are running up the user service 1112 and 1111. And now what I'd like to do is to create another application that also connects to Eureka that I'm going to use a REST client from that application to contact the user service and it's going to automatically load balance. All I've done is add an annotation to the default port very good question by the way the default port for Eureka is 8761. So I don't need to specify a URL or a port number if it's local host 8761. So that's just a little bit of magic. I can actually show you what that looks like in a production application. So now I'll create a user client so I've gone ahead and generated this so we can see here that I have my spring cloud starter Eureka dependency and I've also added a starter web so I'm going to run the API from this. If I go to the application class I can see here that I have I've added that annotation at the top which is enable discovery client and I've also created a bean here which is called the REST template. Now the REST template is a very common bean that we use to contact other services. It's just a REST client. Now the big difference here is that I can add another annotation called load balance which is going to create a load balance REST client which means that it's going to take advantage of the service registry and it's going to load balance between instances of services. I've created a REST controller here as well so here we have basically two fields which is we have our load balance REST template and we have a discovery client so I have a client for the discovery service and I can use that to get information about the services that are registered with Eureka and map that to the root endpoint here so we can actually get all instances of the user service and return that back as JSON. So the magic here is actually in this forward slash user dash service. What I'm illustrating here is something called reverse proxy which is that I'm going to call the user service from this endpoint that we're accessing on the client application and it's going to forward the request to the user service and we can see here that I'm using HTTP user dash service so we know that this is actually not a valid domain but the REST template is going to automatically translate that key to an IP address which is stored in the service registry. So if I go ahead and run this application so we see that it started up and if I refresh Eureka we can see now that I have a user client and if I navigate and go to the root endpoint we can see here's the information for that first mapping we have information about all of the user service instances so here I see instance one which is at this address and we have instance two now I'm going to demonstrate the reverse proxy if I go to forward slash user dash service we can see that if I reload it's going to load balance between those applications so I can add as many instances as I want and it's automatically going to load balance so that's the core idea behind spring cloud is that it really provides you a set of features for managing distributed systems I think client side load balancing is an excellent example of that so we also provide a configuration service I won't demo this but the idea here is that I can have a service that I deploy to an environment that's going to map to a Git repository where I've stored centralized journal configurations so I can actually go to a Git repository make a change to a file check it in the configuration service will pick up that change and broadcast it out to the applications that depend on that config so I have two environments here I have one for staging and I have one for production the API gateways one of the most important features that we have in spring cloud the idea here is that I can go ahead and add a service which is going to download the routes from my microservices my REST API here and here and expose that as a single gateway so it's going to automatically download those routes and it's going to embed that inside of itself which I can then reverse proxy in the same way that I showed you in the controller so let's talk about REST a little bit as a part of spring data we provide audio s which is hyper media as the engine of application state which is really just REST APIs that self-described and it's pronounced hot TOS like honey oat cereal not hate OS so this is based off of Leonard Richardson's maturity model so the expressiveness of our APIs this pyramid here shows that we started at level 0 which was single URI single verb and we moved up to become more expressive until we reach level 3 which is the top of the pyramid which is that our REST APIs are going to fully describe every single function that is provided with a part of that service and so we have this as a built-in feature with spring so now going back to the REST API gateway tying this all together the API gateway is going to reveal a series of links to our back end microservices as reverse proxy when we communicate with those services it's going to forward on the request to the back end service and return back a response and so what this looks like is that here's my root endpoint for the edge service or API gateway we have three microservices here we have the rating service the product service and the user service so this is hyper media it's returning just a set of links that I can browse and it's very similar who's used swagger swagger so it's similar to swagger so we actually have in the spring ecosystem a browser for this because it provides all the information of what you can do in the API you can build a browser on top of this very similar to swagger so if I traverse let's say I traverse the user's endpoint I will go to it'll route the request to the user service and return back the response so here I have a spring data repository we can see that this is paging and sorting repository so I have a list of functional links see here first next and search we have a search method and it's going to return back that page of results so I can page through this and return back different results okay so now I'm going to take questions before I get into the reference architecture but I'm going to put this up so that we can talk about it so if you have a question go ahead I'm not going to proceed until we get the question I need one question so I've added in this reference architecture here I have a online store I've added in a spring cloud I have my user service and these are backing services so I have a user service an edge service, a discovery service and configuration server and my front end I have my online store web then I have my backend microservices so we can see here that the online store is going to be redirected to these backend microservices it's going to communicate with them through this edge service but the user service is going to act as our gateway for any protected resources so the user service is going to try and sorry the online store web is trying to access the edge service it's going to be redirected to the user service if it's unauthenticated and it's going to have a token that's in its headers for its authentication state I'll go over it more how does the backend service validate the session so it's going to be stored in the headers so if we contact the online store web it's going to have that in the header so it's going to contact the user service automatically and it's going to pass that to the user service and validate that session state so it'll return back a response that it's okay and we'll have our session state available in our application the backend services do this as well it preserves and forwards on that authentication header to all of the other services so each one of these services can also call back to the user service to authenticate that session it's going to for any request even when the edge service forwards downstream requests to the microservices it's still going to forward the header through the user application the online store web so it's just going to pass that along in the header and these services are going to have to re-authenticate basically just call the user service to authenticate that session yeah so this is mapped in memory so it's in memory and we're going to scale it also can contact the database you can also use cache you can have a like couch based cluster so there's a lot of ways to optimize how fast this is but yeah that's a very secure model yeah I mean absolutely right there's going to be a trade off here with this architecture now that's a very secure way to be assured that they're only accessing the resources that they're supposed to but you also can just use the edge service as the gateway to say I trust that that user is correct and these services don't need to reauthenticate any other questions what is the edge service here I think I saw a answer there's another variance of microservices sub-contain system sorry sub-contain system self-contain I haven't heard of okay because for those architecture they have their own UI as a service from database to the business to the UI as a service so I'm way between the self-contain system and this architecture it's a 3-tier architecture no no no it's a microservice which where did you hear about it's from the day I came here well show me that later it was stated that there's another variance of microservices it's quite popular because I'm looking at the Euronka it's a self-contain system because they provide the UI together with the as a service so to me it's like a self-contain system I've heard that he called a back-end for front-end a BFF Sam Newman talks about it in his book on building microservices but I haven't heard the term self-contain system you'll have to show me the point any other questions the edge service is going to act as a gateway which is just going to send all the REST APIs that are exposed from these microservice here in the back-end so the online store web isn't going to communicate directly with those back-end services it's going to use the edge service and we have an AngularJS application here so it's actually going to embed the URL into its own application so that we can access that as part of our own host I'll show you that in a second I'm sorry edge service is going to act as API gateway the edge service is the API gateway in this case here My question is something like when you go with the microservices you can scale it like that but if you go in reporting like if you have to generate a report there's no relation now because users have different database records both the online store and different database so how we actually create a report we'll go with the data warehousing where you put all your data otherwise because it's hard to query like if you have to check there's no foreign constant or anything which I can see from now So one architecture I've seen that creates a data warehouse from the different microservices uses a transaction log so you'll have maybe a patchy Kafka and anything that touches the database is going to be added as an event to a patchy Kafka and these are going to have an exact order so I can use any database I want to replicate the exact domain of all of the applications in a single database and I can use that as my data warehouse that's one way to solve it otherwise you can either contact directly if you're just doing reporting it's fine to contact the databases and read so you can do that as well so I just wanted to maybe give them a question maybe I mean we used to have modular application a long time ago and now we have split the database to make the microservices so what technology has made it a neighborly in a way to come to this architecture and why it was not like so many years ago because there was some fashion earlier I mean this question was that to this point because people were centralizing the database for other purposes so what is the downside of this architecture there are certainly downsides right this isn't just green fields and what is the neighborly technology that brought you to this architecture the second one is what is the downside so to answer the first question it's all about velocity going into production that is to scale an engineering organization I can have independent units of deployment for each application I don't have to have one monolithic application where I increase that's the objective which was not possible before go ahead so I think the enabler was the cloud so if you think about let's say 5 years ago for you to actually build a service on the internet you had to build a data center which was capital expensive so you basically had to build a facility put service into it, rocket put electricity cables then secure it now you can actually pay compute with a credit card so the barrier to entry has decreased exponentially like it's really now I can go to run the Pivotal IO and I can run my application within seconds I don't need to go to approval I don't need to talk to security guys I don't need to talk to the finance facilities so this is a lower the barrier the second is I think the technology so if you look at the microservices part one of the advantages is that you want to deploy it more often and as needed so in order for you to actually adopt a microservice architecture you need to learn how to do continuous delivery that means that as a company you need to be able to do 20 releases per day so if you look back five years or ten years ago doing these sort of releases was also very expensive because you have to connect to the load balancer to the global traffic controller to the local global traffic controller to the DNS now everything is being API driven so I can do an Amazon call or a vSphere call which is software basically the fact that we now can pay compute power and buy any resources from the cloud via a card as a utility bill and then the second one because we have APIs to talk to the hardware and to the computer to all the resources so these are the two enablers to the microservice architecture like if you were to do you have to pay millions or even billions to be competitive now it's just the barrier very low and you can see examples of this at Netflix at Amazon they're using microservice architectures for a reason which is that they want to move faster be more flexible and use the cloud now what was the downside the downside is that now you don't have the safety net so for you to actually deploy a new change in a monolith it's much easier because it's a matter of adding an easy statement if you want to deploy a new microservice then you're basically building from that my operating system, my middleware my rest endpoint because it's a full stack the whole microservice that you have user service it's a replica of a catalog service so you need to invest in all the infrastructure top down but because you're using let's say Linux kernel, you're using containers framework that was built in the open source community you're leveraging all that intellectual property so it's no longer an investment from your company it's basically you are sitting on the shoulders of giants and you just implement the business logic the disadvantage is that you don't add an easy statement you're creating another deployable unit which needs to be managed which needs to have a product manager so you have a product road map now troubleshooting becomes an issue because you have cross-cutting consents that cause multiple services so if you're thinking about the transaction it will go not to a single monolith and then you are able to troubleshoot very easily but it goes through 3, 4, 5 as many as needed so you have to have a culture of test-driven development so that you make sure that the quality that you build into each individual service is a priority and it's not a by-product then the second is you need to invest in DevOps culture so that the team that develops is also creating it and then you need to have buy-in from the business that they need to have velocity if there's no need from the business to make changes then you should not invest into having releases that are it's a prerequisite of your business if you are working into a well-defined manner where releasing once in a month it's fine you don't need all these benefits but if you are deploying a mobile application that changes every day it has the application where you are working with wearables then you need that power that's very good answer any other questions? any dependencies like the order service depends on the card service the order service if I have a dependency between these two micro-surface because your architecture sounds like all these are different with the service-oriented architecture because the service-oriented each other also can depend on each other yeah absolutely so let's take a look at that so I have this application the source code here and we'll go ahead and look at the order service so I have a REST API here that's exposed for the order service which it's going to the basic idea here is that you can use this to create an order so if I go to the order service class here I can see that I'm using a go off to REST template that's going to be load balance similar to what I showed you earlier and if we go to the create order actually I'll show you different ones so here I'm validating the account number so I'm calling the account service similar to what I showed you earlier I just specify account-service and I call that at the end point here and I'm going to provide this is already about that decay it's just going to give me the state of that user what I can do here is that I can just map this to a local pojo so I've just defined exactly the fields I need for the account objects so I have this pojo in the account service itself so from the order service all I can do is have this pojo in this class and see the libraries between these services I'm just going to create a basic pojo here which I can use to basically deserialize the response and map it to my object so it's a very simple model I don't need to take the full object that's defined I want to change the API so you use versioned APIs and you just have to remember we have that consumer driven testing module so if there are any changes to that pojo that break this model they won't be able to deploy it into production feature for us to see which service is using my service so that I can know that when I need a testing of which other service I need to take care of it we provide distributed tracing so you can use Zipkin which will visualize that but if you really just wanted to get an idea of who's requesting your service you can use actuator I had that running earlier and used the trace feature so let's see if I have this running I think I bit away with it localhost8080 oh here it is so I have a trace endpoint here which is going to show me this is going to show me every request to my service so I can see here exactly how it's being used and that might be one way that's how I would do it yeah you can also pass along an ID you can onboard certain applications who should be using this app and you can validate them against a set of resources with the edge service here if I go to that configuration I can see that in this edge service remember this is the API gateway I can specify that I'm only going to contact the account service, payment service inventory service, order service certainly make sure that my applications are only communicating with who they should be communicating with any other questions? I haven't rebooted any I had running from before cool that's a good question I can actually show you that with cloud foundry so I have if you go to run.pivotal.io we provide a hosted instance of cloud foundry and I've created a manifest for each one of these services this is the edge service I can push this to that production environment so here I have my manifest yaml which is going to specify the name of the service the memory, some other information also the services that it depends on I'm just going to show you to push this production I'm going to go to that directory so here's all of the services and I'll go to the edge service and we can see here that if I do CF apps I have a command line client for cloud foundry you can see all the running applications this is pretty ugly I have the UI up here I don't know what that's all about I've been tethering a Sergio's phone all day and throwing up all of his usage so here I have the Pivotal web services UI and I can actually just visualize those applications so here are all my apps and I can see the instance count of each application so these are all of the services in that diagram now what I like to do is just push the edge service so I'll go ahead and actually I'm going to scale this down real quick and I can just do CF push here from the command line now that's going to look at that manifest file and it's going to go through the process of creating a container for that application uploading the jar and deploying it to that environment now I can actually stream logs from this if I can do CF logs edge service so now it's uploading sorry? there's a template provided you can also use CF command line to generate it but it's in the documentation it's very basic it's kind of a little bit like Docker compose and any second so we see that it's binding to the discovery service to the config service to the user service now it's restarting the application and we should be able to see some log output here so this is the application starting up it looks like it failed it just shut it down so now it's creating a container for it it's calculating the memory and now it's going to start the application so now we see the log output from the application starting up just like if it was local and we can see it's now started and registering with the discovery service so if I go to the discovery service which I have running I can go ahead and see information about the edge service that I just deployed I can see that I deprovisioned that one instance and we have the new instance here so actually I can open this up it should be unprotected I can't actually look at it because it's protected I have to actually assert my authentication credentials but I'm going to show you the finished application if I go to online store web and just to go through the diagram the top we have our online store that's what we're looking at here I'm calling from the front end I'm calling the catalog service I'm returning back a set of products from the catalog we can see that I'm not authenticated if I go to one of the products in the catalog I can see information about that so that's contacting the catalog service which is contacting the inventory service I can go ahead and log in here this is going to redirect me to the user service where I have a authentication gateway I can log in not admin user so now I can approve that grant so I'm redirected back to the application and we can see I'm now authenticated as user John Doe and now I have some more options here so I can actually go to settings this is going to contact the account service it's going to get information about that user's account I can look at their orders which we'll call the order service I can also start adding products to the cart so I'll go ahead and add a few of these now if I go to the cart I can see the products that I've added I'm going to have to decrease these because I can't afford I really can't so if I try to check out I get an error so now I'm going to check out here so all this is done it's contacted the cart service I can go ahead and check out now an order has been created for that user for those items so that's the basic idea I do provide this as a tutorial and an open source project so you can run it yourself you can deploy it to PWS or run it locally I have the tutorial on my blog it's just myname.com and you can walk through this it's going to explain about eventual consistency in microservices and event sourcing which I haven't gone over today but it does provide a working tutorial of this application that you can go and run on your own so I recommend taking a look at it it walks through step by step so if I spoke too fast tonight I apologize this is the 12th time I've done the talk in the last week and so working on the other cart platform yeah I have it working it will work on another cloud platform actually I'm supposed to tell you it won't just Pivotal Web Services so take a look at it it's a pretty comprehensive tutorial and you can run it locally if you want to as well here's the get repository on github so you can see each of those services here and yeah that's about it so I'm going to put up my contact information I'm going to stick around I have more slides I'll just put up my contact information if you want to get in contact with me please go ahead and email me and if you have any questions if you're up late at night wondering about microservices need someone to talk to just email me it's fine and then follow me on Twitter of course so thank you very much for having me it's great to be here so thank you