 Okay. Okay. So we will start another session. The topic of this session is develop and deploy Java application as a resilient microservices architectures. In this session, we will see how we can combine a lot of different technologies and tools in a live demo that will open our eyes for a huge possibilities that microservices can enable to achieve. This talk is presented by Raphael Benavides, director of developer experience at Red Hat. So good afternoon. Oh, thank you. I'd like to thank you all for being here. These slides that I'm using here are available for free. It's an open source slide. So if you like this talk and you want to reproduce it in your company, to your friends, in your local jugs, anywhere, you can just grab these slides, modify. It's totally open source. Well, my name is Raphael Benavides, and I've been working for Red Hat for seven years. I started as a consultant. I've been an enterprise software engineer for the developer materials. And now I'm working with the Red Hat developers initiative. Something that I like to do when I have a free time is to build my own drone. This is a picture of my drone. It's a TBS discovery. And some people ask me, why don't you buy a ready one, a drone that's already completed, that comes with everything and you just fly. And it's more or less like a PC versus a Mac, right? With a PC, you can choose the graphics card, you can choose the memory, the hard drive. And when I'm building my own drone, I can have the same freedom to choose the motor, to choose the flight controller, to choose the receiver, the size and the capacity of the battery. And somehow this is related to microservice. Because with microservice, we have the freedom to choice. Unfortunately, in a drone, we can change these pieces when you are flying. But with microservice, we kind of can replace one piece by another when you are doing microservice architecture. Well, before I start this presentation, I'd like to invite everyone here to visit the microprofile.io website. I don't know how many of you are Java developers. But there is this initiative that the idea is to bring a specification focused on existing Java APIs for microservices. Something that I really like about the microprofile initiative is the logo. Because if you notice, the logo is just small dukes, just like microservice, you know? And also, I'd like to invite everyone here to join the Red Hat Developers Portal. How many of you are not a Red Hat employee? Please raise your hand. Oh, that's great. That's really great. So let me tell you about the Red Hat Developers Portal. The idea of this portal is to help developers to build better software and how you can achieve that. In this portal, you can have free access to all Red Hat products. You can have access to blog posts, articles, free eBooks, everything that can help you. We are giving you for free. You just need to register and you are done. That's it. So since you are not a Red Hat employee, it's good that you know about this initiative, about this Red Hat Developers Program. So we will be a little bit fast in this introduction because we have a lot of things to talk. And I want also to show you a demo. I'm running this demo in the cloud, so hopefully you can access the demo using your laptop or your mobile phone and interact with the microservice that are already running. So let's think about the main point about microservice. Microservice is all about agility. It's nothing more than that. It will not make your process of deployment easier. In fact, it will be harder to deploy microservice because you have different moving pieces. It will be more complex to develop because you need to locate a service, handle failures if the service is not available, be very strict related with the API. So microservice will not make your life easier, but it will make the process of deploying software, it will make the process of being more agile for you. So what's the point? Even being so hard to deploy microservice, to develop microservice, it's a serious thing that everyone is talking about and we need to understand why. And of course there are two realities for microservice. There is the reality of Greenfield where a new company is starting a brand new software, like I start up with two guys and they need to release their software fast. They need to be agile. They need the agility. So they are one kind of company that are adopting microservice. And there are the reality of the Brownfield where the companies already have big monoliths that are being developed for maybe 10 years of software development and they want to go to the microservice and how they can do that. There are two realities, but in common both of them need to evolve, they need a kind of evolution to adopt microservice. The first step of this evolution is to have an elastic infrastructure, like something that can shrink and grow like in the cloud for example. The next step is to reorganize your company using and adopt DevOps practices. Because with DevOps practices you can start to have automation and using tools like Ansible, Puppet, Chef, ok? With automation finally you can start to have continuous integration and continuous delivery of your software. And finally with all these pieces you can have your one microservice. With your first microservice who knows you can become the next Silicon Valley unicorn. So even Martin Fowler said in his article in his website that there are several steps, several requirements that you should have before adopting microservice. It's not just a desire, I want to do microservice. You have to have all those pieces, you have to have continuous integration and continuous delivery, deployment pipelines and all those things that we said. Because when you are developing a software you have to think with me everyone that is building a piece of software in the company no matter what team you are in you all have to agree to run the same operational system in the production. You have to use the same virtual machine, you have to use the same application server, the same enterprise archive and then you will have your one or two more files. Of course to avoid the application of code you start to create libraries and everyone in the team in your company has to agree about the version of this library. So you can keep growing your software and of course as it grows your number of libraries keep growing. And everyone has to agree that this is the environment that we will use in the company. But what happens is to maintain these wild beasts, these big monoliths there will be a team of several people to maintain. There will be programmers, business analysts, credit assurance, DDAs, operators, developers. But what happens in reality is that the software is divided logically in pieces. There are teams or cells, a group of developers that take part of each part of software. Some groups, some teams take care about the security, about the authentication mechanism. Other teams take care about the sales, other teams take care about the warehouse, other teams take care about the finance. This is largely how it's organized. And if you think all of them have to agree to send all those pieces together to the production. And no matter if you have the latest and coolest technology on your laptop suppose that you do a POC with the latest version, that's awesome. You go to your manager and say, manager, look here, I have something that will help our life. If everybody else doesn't agree, your software will not have any value until it reaches the production. And sometimes when you receive a requirement, it takes like 24 weeks to that requirement be implemented, tested and homologated and release it in the production. Sometimes some companies adopt practices like agile practices, and then that can reduce to 12 weeks to release a software. Others can adopt containers, automation and orchestration can reduce even more. Using continuous delivery pipeline can reduce, but sometimes you will find a barrier, which is the barrier of, for example, if you are adopting agile, you have a sprint, for example, in the scrum of three weeks. Usually you will do the development and at the end of the sprint you will have a software ready to production. And this is the barrier, how you can deploy faster than a sprint cycle. There is a novel, a book called The Phoenix Project, that talks about like 10 deploys a day. How is that possible? So the only answer to that is to break your big monolith in small pieces. So for example, in the week one you can just deploy the piece A, C and D. On the week two you found a bug in the part A, so you release A1 plus the H and G and so on. Each week you can deploy your software because one part is not attached to another one. So that's the point about microservice. It's the independence that helps the agility. If you are not dependent among each part, you can, for example, this team here, suppose this is the finance team, it can implement the service using Java. For example, it can use wall-class form. This one can implement using Node.js. This one can implement using Golang. This one can use Postgres. This one can use Oracle. That one can use MySQL, for example, because they are not attached. They can use the better tools at that moment for that specific use case and deploy their software. But we have to be really careful about the Cone's law. Every microservice talk will talk about this law. That means, that says, if the communication structure of your company is a mess, very likely you will have a business microservice that will be a mess as well. Because what you produce as a software is a cop of the organization's communication structure. That's the point. Sometimes when we see this kind of scenario, when we see this kind of feature, we tend to think, I have seen that before. I know how we can integrate these different pieces. It's easy. It's just use an enterprise service buzz in the middle and we are done. We heard about SOA, right? But SOA is not microservice and microservice is not SOA. What's the difference? The difference is that in SOA, the enterprise service buzz was the smart guy. It needed to be smart enough to route the message, to find the endpoint, to reach the message, to transform the message. The buzz, the pipeline was smart and the endpoints were dumb. In the microservice land, it's the opposite. The pipeline is dumb and the endpoints should be smart. I will talk why they should be smart when we are talking about one microservice talking to another microservice. But the question still remains. Where is the role of SOA in this world that we are living at this moment? SOA has its role to integrate different monoliths. It's more like to integrate business to business or sometimes business to Cosmer, but to integrate different monoliths, different systems. And when we think about a pipeline endpoint being smart, one microservice invoking another microservice, we kind of think that that can become like a spaghetti. A spaghetti code, something that invokes this and invokes that. But that comes with a price. With great power, there comes also a great responsibility. By the way, this is also in the comic book. It's not only in the movies. What about microservice? What are the main microservice points? The microservice should be focused on independence, like I've said before. It should be focused on the API because we can change the implementation, but we cannot change the contract that we established with our clients. Of course, there are some patterns to evolve your architecture. For example, you can, in your message, say, I'm invoking, I'm a client v1, I'm a client v1, and this is the payload of my message. When the server identifies that the client is expecting a v1, it can, okay, this is the version one, so I will respond that way. Suppose that your server now talks version two. It should be backward compatible. So we should all be really focused on the API. Another great point is to decentralize the governance, decentralize the data-made management, because that's one point that's very tricky and people like to ask a lot. It's about the data. In a microservice word, as I said, one microservice can use MySQL, another one can use MariaDB, another one can use Postgres, another one can use any other NoSQL database. What does that mean? It means that each microservice will have their own database. Because imagine, suppose that I have the customer table. It's famous, the customer table. And we need to change something to improve our software. We need to create a column. We need to rename a column. We need to add any other attributes to the customer. And that breaks every other part of my system. And I have to wait that part to be available, to be updated as well so I can release that monolith. So that's a problem. In a microservice word, you should never depend on a main database. Each microservice will have its own. You should also think about the failure. And as I said, you should think about the evolution. How can I have the server responding to version one clients and to version two clients? And as I said, this is a very question that appeared very often. How do I decentralize my data? And what I like to suggest to you is to give this book for your DBAs and in your company. Take him to lunch and say, hey, I like you. So that's why I'm giving this book to you. So maybe he can help you to accept to break the database in small pieces. Of course, ideally you should have one database per microservice. But if you cannot do that, at least have separated schemas for each one. So this book talks a lot about that. Now it's a part that's interesting, which is related to the patterns to the invocation. Because we need to find different parts of our software and invoke it. The most common pattern for the invocation for the microservice invocation is to have the browser as a client. So the browser will be responsible to locate the microservice, do the invocation, and in the case of failure, to handle that failure. For example, this is a screen from a company in the US that uses microservice. This is just like Amazon, but it's not copied from Amazon. You can see the title of the product, you can see the price, the evaluation of the product, the description. You can even find where is the nearest store and the recommendations for similar products. What happens is that each part of the screen comes from different microservice. So you have the reviews, microservice, you have the location-basic availability, microservice, you have the details and the specification microservice. But let's think, what happens if one microservice is not available? Suppose that the location-basic availability is not available, what will happen? Should I show a screen? We are offline, sorry for that, we'll come back later and lose the sale. This is not what we should expect. We should be prepared to the failure. So in this case of failure, you should provide a fallback. And the fallback is if you can't find where this product can be found, you should also, at least for example, you are in the mobile, you have the GPS, you can show him what's the closest to store and if the customer is really interested in that product, he can go by himself and find if that store has this product available. But you are never showing a never message to him. You are prepared for the failure. Another common pattern for the invocation is to use an API gateway. An API gateway is another microservice because sometimes people ask me, is that a product, is that an open source project called the API gateway, is that something that I can buy from a company and that will do the microservice invocation to me? No, this is another microservice. You will invoke that microservice and that microservice will be responsible to locate, invoke, and handle any failure in the microservice. But the fact is, one microservice because it's micro, it will not have all the answers. It needs to invoke another microservice to find the answer that probably will need to invoke another and another in a chain invocation. But the problem is, what happens if the chain is broken? If something in the middle of the chain is offline? Well, this is why I said that the endpoints should be smart in a microservice architecture because this guy here has to take the decision and think, okay, the next guy is not available. Should I ignore the rest of the chain? Should I invoke the next one? So this guy knows what he needs from the business perspective and take the decision how he will handle the failure, how he will handle the fallback. Of course, we can have mixed patterns. We can have an API gateway that will invoke a microservice, that will invoke another. That's totally common. Once more, just remember about great power comes with great responsibility. And since each microservice has to have its own concern, because, for example, when we are developing a monolithic, we are developing a Java EE application, the Java EE server provides us with monitoring security, thread pools, with logging, and everything else. But with microservice, each microservice, if you have 200 microservices, each one of them has to concern about how I will build and deploy this small piece in the production. How I will manage the container? How I will do the invocation? I should use rest. Should I use messaging? How I will trace my invocation to know that these requests invoke this micro-service that invoke that one, not this one. We should care about tracing. We should care about how I will discover the service, how we will handle the authentication to allow just authorized users to use that microservice, how I will handle logging. And for each one of these microservice, Red Hat provides a specific answer for that. And as you can see, OpenShift fabricate containers are the answer for the most of these concerns. But I'd like to ask you to take a look here about tracing using Zipkin and also about resilience using history and Kubernetes because we'll talk about that at this moment. What happens in a thread environment? When a service A is calling a service B. Suppose that the service B is low. What the user usually do when he tries to open something in the browser and it's low to respond. It clicks and more and more and more. Ah, this is not responding. And you keep bombing and you keep sending requests for the service B. So you should have a kind of mechanism that avoids sending more requests to the service B and yet say, respond fast to the service A. Look, the service B is not available and here is the fallback for that service. This is made by a Netflix OSS library called Histrix. It provides a circuit breaker implementation and it can be also integrated with the thing that is a rest A guy client. So you can see that it's very simple. You just have the service interface. You say, where is your server? And you provide the implementation of the fallback which is the implementation of this interface. Of course, this implementation will take the decision. Is it another service? Should I ignore? Should I provide just a fallback message? And something that's interesting about the Histrix library is that each service, each client knows the status of the service that is being loaded. And since it knows the service there is a service called Turbine that collects the statistics from each Histrix and provides that information in the Histrix dashboard. And this is the Histrix dashboard. This is what you will see if you use Histrix dashboard. You will notice the name the status of each microservice that you have in your company. You can find the number of invocations how many invocations were rejected by the trade pool how many. If the circuit is opened or closed because the service doesn't respond in one second it will open the circuit and avoid sending more requests. So we can have all those information, the average response time for the invocation. So that helps us to monitor our microservice. For tracing we can use Zipkin because with Zipkin we can find where our requests went through and see how long it took for each invocation. This is really nice and I will demo that in a live demo. And people when see this kind of architecture also ask how should I adopt microservice? And the better answer to that is use the Strangler feed pattern. The Strangler feed pattern is just like the tree where it grows outside and involves everything that it strangles everything that is in the middle. This is what we usually have in a monolith scenario. So to start is strangling this monolith we can extract one part of the system. Remember with its own database at this moment these three microservice there are tied together but later I can refactor that and then keep extracting extracting and then I will reduce the monolith. So what I will do now is show you a microservice demo that's called Hello Road MSA and what I like about this demo is that you can run this demo on your machine. You can run it using for a virtualized environment called CDK container development kit that you can get in the developers.redhat.com you can just download it will be a vagrant file that when you run that vagrant file you will have the hypervisor with a rail and open shift Kubernetes and Docker inside. So this playground here is in GitHub. You will see this peanut repository that contains the instructions to install all these microservice. And you have also here the source code of each one of them. It's a Hello Road in different languages. Ola is implemented using Spring Boot which will respond Hello Road in Portuguese. There is another service called Hola that uses WorldFly Swarm and returns Hello Road in Spanish. We have French for Node.js We have an API gateway, we have Vertex, we have several talks about reactive programming today and yesterday and we have the documentation. Okay, so I installed that in open shift. So each one of them are here. Aloha which is from Hawaii right? The API gateway and I have here the front end. So this is the URL that I want to try. Front end, if you are connected to the Wi-Fi, you can open frontend-HelloRoad-MSA from microservicearchitecture.app.RafaBene.com What we will see hopefully with my internet connection is the three patterns of invocation. I have here the browser as a client. My browser is invoking each one of these microservice. I can invoke it here nothing special, right? And it will return for example, hola and the name of the host. I can have the API gateway so I can do the invocation the API gateway, you invoke and return the consolidated answer and I have the service chaining where the hola invokes hola and invokes Aloha nothing special one answer for each one of them but what happens if the bonjour for example is not available? So let's shut down the bonjour application I have one replica here I will shut down it now that's not available I don't have how to answer this question, this microservice, you will notice that each click here takes some seconds to reply and you can see that in the history dashboard the number of failures are increasing but the circuit let me increase the font size in this one the circuit is half open and half closed because it has not detected yet that the circuit is totally closed so when I do several invocations here it close the circuit you can see that the this short circuit here is the blue one so I have 11 invocations that were circuited and I can fail fast so no matter how fast I can click here my service B is not receiving the request to scale that, to scale a microservice application using containers using OpenShift is easy as just select how many replicas of this application I want to have and once that the application becomes available let's wait for that we can return here and we don't have the failure anymore now we can see that all invocations of bonjour are now being shown in green every invocation of bonjour for example from API gateway you can see that it replies from different hosts it uses here 7Y let me take another RV, keyf so it's doing a load balancing and that's important also to have a stateless service in a microservice architecture here you can have Zipkin for example suppose that I want to see what are the dependencies of my microservice every request sends a token between the service so that's why Zipkin knows that API gateway invokes each one of them it knows that OLA invokes OLA directly and I can even find a trace for example I want to find every invocation in the hola microservice for the method get between that time and that time and I can find a trace and I have here for example seven requests in this invocation so the OLA invoked hola that invoked aloha and the response time for each one of them it's something that it's good to have in a microservice architecture something that you can also do and you can find that instruction here in that documentation on how to install the hello world MSA is to change the behavior of a microservice so for example suppose that I want to change the message that's being printed by the hola microservice I can set an environment variable because this is what the 12 factor says to us that we should store configuration in the environment that will cause another deployment for let me see will cause another deployment when this version here is available it will change the route between this pod to this pod and I will start to receive the to see the request of the new service for the service hola so let's try yeah I've changed the behavior just changing a configuration of the microservice that's placed externally something that I can also do is perform a blue green deployment blue green deployment is when I have two environments and I want to create a new version called blue and I just can switch to that version if I'm wrong I just switch back to the green one for example I have here the api gateway blue it's a modified version that I've deployed before this session and we can invoke the api gateway and what I will do now is change my route and you can see that for example here you can see that my route points to this service and when I click say I want to change my route to api gateway blue it will change my route from here to here so let's wait because the internet is a little bit slow it changes so I can come here return to api gateway click refresh button and I have now using the I'm now using the blue version but I didn't like that about that version I want to return so that it's simple for example I can also show here in that visualization I like a lot about this visualization because I can show just api gateway blue and the normal one I have my route pointing to this version here and I can change back to my previous version so you will see that changing from here to here yep it changed changed and now I can refresh and now I made the blue green deployment easily something that I can also do is for example have the worry about the security if you click login for example if I try to use this micro service here these end points they are unauthorized because I'm not logged in I can log in and when I log in I will be redirected to another service it's a single sign on service called key cloak I can manage key cloak I don't know how many of you have opened this page but you can try yourself and for example I can open the key cloak console here the administration console and for examples I'm logging in with my administrative credentials and I can say for world MSA I can for example enable user registration ok if I enable user registration when you try to log in you will be able to register yourself I just changed that in the single sign on you can for example try to register yourself when you register yourself I will see your credentials here I can grant you permission or not for example I will log in with my existing credentials I will log in as user user that I previously created now that I have a token the key cloak will return a token and when I involve the microservice it will send that token to the microservice the microservice will check with the key cloak if the token is valid it will return for me the credentials and also my username and my role and I can check if my role is allowed or not to to access that microservice of course I can also do a continuous integration and a continuous delivery but using Jenkins pipeline so I have Jenkins running here but we are running out of time to show that demo so I encourage you to try the microservice Hello World in your home you have all the all the use cases here you can configure you can do the deployment patterns you can use the continuous integration and continuous pipeline since we are out of time I'd like to open this moment for questions and answers and don't forget before going through microservice please go to monolith first this is what Martin Fowler said if you try to go straight from nothing to microservice you will find dragons and snakes and problems do a monolith split it in in one microservice first until you reach the microservice land don't forget also to register and I'm open to questions and please people don't be shy because if you are shy it means that you understand nothing or you understand everything and you don't have any questions good question I believe that the main problem is that you don't know you don't have the culture you don't have the environment tested because you need to be agile right so how do you know that your continuous integration is working how do you know that the tests are good enough because one of the points of the pipeline is to prove that your software is not read in the production but if you have a poor testing you will release trash to the production so that's why you should have you have to be this tall to play with microservice you have to be that requirements you have to test and have everything in place before embrace microservice you will not know how to to do tracing, to do monitoring to aggregate the logs it's more cultural than technical you can know what I mean I feel that someone wants to ask when it comes to user interfaces what's your suggestion every microservice should expose its own piece of UI or we should have a UI which integrates good question, what I like to do is for each microservice provide a swagger I don't know if you heard about swagger but let me open here for example the Aloha microservice with swagger I can browse the existing microservices and it's automatically generated I have an annotation in Java that I just said the description and it will automatically generate this swagger JSON file and I like to use as a UI for the microservice this swagger this swagger console so I can for example browse the existing services I can try it it will do the invocation on the microservice to me, show the response show the response code, it provides me a call this is what I like to do for each microservice was that your question? that's another great question I've tried and if you notice here in the instructions one of them is to deploy Hockler APM instead of Zipking by the way I have some stickers here I don't know how many of you like stickers but I've brought a bunch of them so at the end you are free to get it you don't need to have something to get it but I have here wildfire swarm vertex, open shift micro profile with the small doogs I'm just giving you time to think about the next question ok? any more questions? so I'd like to thank you all for being here don't forget my Twitter handle is RafaBeni you are free to add if you have any questions that you think that you thought about asking it here and you're a little bit shy you can just send me by Twitter I'll be very pleased to help you and answer thank you and I actually brought some new ones I have newly designed private gift stickers these are the new newest stickers but last yeah our new project wait that's right that's my third one I'll be right there you made the movement it has been announced two or three months ago but now it's been shown it's a big trend fabricate was so empty it's just naked I just had the fabricate was designed brought something fabricate I'm coming from the middle I'm vertex they joined our tooling team they know that not not Andrea you guys we got on this big guilt basically we can have one dev tools now we have a recovery kit it's kind of different because obviously the presentation where So it's kind of... But the people are the same? Who is going to be the next project? That's sweet bit weird. I think it's highly politic between Rob Davis and John Straken and so on. Oh, it would have. I have no idea right now. It's going to be interesting. Will you need anything else? Maybe the reduction if you have PGA or HDMR directly. I would... Thank you. This is the same screen. Live cutting, pure mirror, no slides. Great. It's just up to you. Right. That's good. I think I've lost it, but I can really know it's back. Okay, great.