Okay. Now we are going to talk about moving from monoliths to microservices. I call it mono2micro just to kind of make it shorter. And we have a little bit of content in this area, and specifically there are some things that I think you will be very interested in, okay? Now this should be noted that microservices are actually not for everybody. There is a great blog article by DHH, the guy behind Ruby on Rails. They talked about the Majestic Monolith. And his case, his organization can produce to production their monolithic application every week, and they can move in one week increments. And we've seen other organizations that go that fast. They went from three-month deployment cycle, or two months, or six months down to one week and for their business, their organization, one week deployments are fast enough to meet the need. In this specific case, he felt that microservices are not for him. So, I encourage you to read that particular blog article because that is a good way for you to think about it. 

Now also, Martin Fowler talked about the fact that you may not necessarily want to go directly to microservices architecture right out the gate for brand new project. Lot of people is saying that: Oh, if you start Greenfield, just start with microservices right away. And Martin actually wrote a nice article about, talks about well, maybe you want to go monolithic first, because you don’t yet know all your requirements, and you certainly don’t know your bounded context, right? So, there is going to be more on that in a second. 

But think about that, there be dragons down the microservices-first path. So, just keep that in mind. Also, keep in mind that you are on a journey to microservices. If you have not matured along this evolutionary path, and you are still awaiting three weeks to get a virtual machine or your Developers and Operations Team are still in odds with each other, and they don’t work together, deliver the product together, you don’t have developers yet on the pager, if you will. Or maybe you don’t have any kind of automation where they be around the containers or VMs or CI and CD, and you can’t figure how to do Blue/Green to save your life, or Canary to save your life. You probably don’t want to go to microservices yet. Because, think about that for one second. 

You have a hard-enough time deploying your one monolithic application every three months. It is hard to give birth to that baby every three months, and now you are saying I want 30 or 40 or 300 of those babies to give birth to, all the time. Well that all this automation in place, I think you are going to struggle with that, and it is going to actually be very problematic. Now, remember we talked about all these properties, we showed you how to build microservices, discover them, invoke them, how to scale them, make them resilient. We are using circuit breakers and bulkheads, you know, how to run a pipeline, all those kinds of things. We talked about all those things, too. 

These are critical to running your microservices that scale, and happily in production. So, let’s talk about what it means to take a monolith and potentially break it up, okay. And at least talk about that. And if you think about that from the original architectural vision you had, when you actually sat down let’s say five years ago, for this Java EE application, or even if it is a big .Net application, or whatever it might be, Ruby on Rails application. You probably drew on the whiteboard a nice, layered application architecture. With user interface separated from the business logic middle tier, separated from the data access tier, with a nice clean data model that, you know, the schema was super-tight, you modelled it all. 

You spent months agonizing over these diagrams and pictures, and thinking about it, and trying different things, and you had a beautiful architectural vision. Well, it actually didn’t stick that way. Over time, maybe it was perfect the first time around, but over time, as people got in there and maintained the code, change things, or we didn’t know about that business requirement, we didn’t know about this new business partner, or this new regulatory change that's occurred. Things start to kind of creep, right. 

Things start getting outside their boxes, and the user interface starts interacting with more than it should on the middle tier, is a good example, and actually the middle tier starts interacting with other components in the middle tier. And then other people start going after the database, maybe after pieces of the schema that don’t belong to them, and it gets even worse, right? So, we actually have a situation where now our met user interface interacts with maybe a third-party system, in some cases, talking directly to a database by passing the middle tier and it just gets crazier and crazier. 

So, this is actually where our big balls of mud come from, from an architectural standpoint. This is where monolithic architecture -- it's not the fault of monolith architecture, it is the fault of not having good discipline over time. So, just keep that in mind, because if this is what your world looks like, it is going to be fairly hard to adjust, without getting that sorted out, to mircroservices architecture where you're just going to take your mess with you. You don’t want to do that. So, just keep that in mind. Some people love referring to the concept of Evolutionary Architecture. 

That is another ThoughtWorks principle, and I encourage you to read more about that, either by Neil Ford or Martin Fowler, and the folks over at ThoughtWorks. Now there is one pattern people love to apply, and people love to talk about, when it comes to addressing the monolithic applications and it is known as a strangler fig. So, this is a strangler fig, you see here, and you can see -- Martin Fowler also wrote about this, known as a strangler application. 

The idea of the strangler fig is pretty cool, basically a bird flies by and, you know, has a dropping and that little dropping has a seed in it, the seed starts growing at the top of the tree because that is where the bird, you know, did his business. And the strangler fig actually grow down the tree, and over time it will completely compress and destroy the internal tree and all you have left is the strangler fig. It actually strangles it to death is the idea. And the same thing applies to this monolithic architecture that you might decide to turn into microservices. 

Instead of actually going and wholesale changing everything, perhaps just identify a segment of the application that can be turned into a microservice and just simply added on the side, okay. The idea that you had, add this one little microservice, it has its own unique database, its own two pizza team, it is completely independently deployable, its own independent governance model, etc. etc. They have got automation, they have got pipelines, they are taking advantage of Docker and Kubernetes, and OpenShift, as an example. And then you simply have your router, right? 

Or you use interface, interact with it too. So, you basically have duplicated in many cases, some of the functionalities, over here, but that is critical that you would have done that duplication because you want to maintain your independence so you can deploy quickly. And so, you keep adding on to that. Maybe it has yet another microservice it interacts with. And maybe other microservices it interacts with, and over time you surround your monolithic architecture with new clean code bases that are focused on the specific use case, specific business capability, they have to. 

And those business capabilities may also be exposed to business partners so we have another outbound route here, and then over time you actually will shrink that monolithic application to the point where it is actually nothing. That is the idea of the strangler pattern, it is much harder to apply than what you saw here in these slides. These things draw nice pictures, because you got to think about all the culture implications inside your organization. 

The organizational impact that you will have, how do you reorganize the teams, reorganize the code bases, and more importantly you have to decide, how in the world you identify the component that gets peeled off and actually it is part of a strangler. This is where domain driven design comes in and the concept of the bounded context. So, I have mentioned here there is more advanced topics that will be available to us some point in the feature, but do go reading it up on domain driven design and knowing your boundary, and the bounded context. That is how you know how to define your vertical slices in your application that could potentially be their own independent mircroservices. 

That's where those rules come from or those ideas come from. Other things you should consider in your mircroservices journey is how to deal with HTTP/2 vs. HTTP/1, as an example. HTTP/2 is super powerful from the concept of a bi-directional, binary protocol, as an example. gRPC is growing in popularity, but you could also think it terms of AMQP, right? So, maybe gRPC or AMQP instead of HTTP as another network component to your overall system microservice architecture. Other things you should consider is Feature Toggles, the Feature Toggling frameworks that are out there, like ff4j and others are pretty interesting. The idea is that could have software components in production, kind like the Canary idea again, but this case superfine grade. 

The Canary in this case was the whole software build, right, the whole new image running in production. A Feature Toggle says, well let me just change one label, let me just change one piece, one button on the screen and turn that button on or off depending on what I want from a business rule standpoint. A/B Testing of course is related to that, you should definitely check out. A/B Testing is non-trivial by the way and is not Canary deployment. A lot of people confuse the two, and is not Blue/Green deployment. So, as someone says: oh, I am doing A/B deployments. 

Do you mean Blue/Green deployments, or do you mean A/B Testing, you need to understand that one. A/B Testing is really a business metric level capture, I am trying to know if my systems are performing better from a business perspective, are we getting more orders, or getting less orders, customer is happier or less happy, real simple. Sidecars are growing in popularity, you going to hear a lot more about that over the next course, or next several months, next several years. 

The concept of the Sidecar and what is happening in the Service Mesh world is going to be very, very interesting. And we could spend a lot of time talking all these things, but as I said they're more advanced topics. They go beyond the scope of our original presentation and our original demonstration that is out there. There are lots of resources available to you. Again, make sure you understand what these links are. This specifically is a site that we have been walking through throughout all these presentations, and again the demo that we primarily focused on, msa-instructions, that shows you all those capabilities, but also the books. Don’t forget the three books that we mentioned earlier. 

There is also another presentation that I encourage you to look at, and that is how the JVM blows up inside a Docker. So, we actually show you how to kill Java via Docker, via Kubernetes, and it is kind of a fun thing to go explore because you probably don’t realize that your Java Virtual Machine will misbehave if not treated just exactly so. You got to treat it very correctly, otherwise it will just die, as a good example. So, the other demos I showed, goodbye, kube4docker also, and the javadockerfail. So, those three are the other elements that we showed throughout all this presentation. 

So, thank you so much for your time and hopefully you enjoyed this content that you saw here, over these last several videos, these last several segments. And if you have any questions, feel free to reach out to me on Twitter @burrsutter, and also feel free to email me burr@redhat.com. Thank you so much and have a great day.