From monolith to microservice - Kubernetes Tutorial

- [Instructor] I once worked in a large enterprise where we had a large team of developers work on a single monolith application. New hires would take weeks to get up and running. And then be scared to make changes to the large code base. All of us played a role in building one big JAVA web application resource file. Which is commonly known as a WAR file. We would have this deployed to the dev WebLogic server by the operations team. Locally, we developed on WebLogic servers that we ran on our machines and set up our environment to use the developing database via data sources. The purpose of the application was to build the e-commerce catalog which allowed customers to view the companies products and understand their specifications. Customers would save products into a wish list that they could share with others on their team. They could also get a quote for products on the wish list. And go through the purchase process once they're ready. I'll use this e-commerce example for a monolith because it's near and dear to me and it's also a fairly common used case. At it's core, the monolith had three main modules. The user module. Which is responsible for the user management, log-in and profile management. The catalog module. This module will contain a list of all the products that are in the company catalog that customers can purchase. And the wish list module. Which is the API that the customers will use to view and create their wish list. In this case, the monolith is a single WAR file and has one or more JAR files that provide all the core functionality. We would also have a common web tier to handle web requests and responses. This looks like a clean monolith already. In your universe, you could have a clean architecture or you can even have a soup-based architecture where you just have code organized in random folders and packages. Hey, don't laugh. This totally happens and legacy code is really scary. So the question is, how can we break this up? There are many ways to do this. And we'll use the simplest approach. Let's break up the monolith into it's core functionality. This gives us three sub-applications or microservices which are authentication, wish list and the catalog operations. In the real world, each of these will have a REST API that can be used by other services if necessary. This allows you at the initial benefit of being able to reorganize your code in a more logical way. The development team can rally around new architecture and split themselves into smaller feature teams to work on the individual applications or microservices. Similarly, you might be able to convince your business team to rally around the new architecture as well. Because it makes the code and API more visible to the business users. Now that we have our microservices, we'll deploy them as containers. There are a couple advantages to this. First, the individual teams can develop, build, and test their applications locally. This allows the team to be more productive up front. The art team can work on the art features. And the wishes team can develop their wishes components individually. Second, you can setup a continuous integration pipeline for every time you make code commits to your repository, you can also run a CI job to test a code and then finally push your containers. Containers also end up allowing you to use Kubernetes. Which is why you're watching this course anyways. Also, by transitioning from monolith to microservice, we've addressed the microservice building block concerns and applied the basic principles form the 12 factor design. For the purposes of this demo, we'll populate our applications with representative code rather than actual code allowing us to focus on the architecture and infrastructure. I'll warn you in advance. Don't use this code in a production setting. It's purpose is to be simple demo code. So now that we have our microservices running in Docker containers, how do we Kube this up and run the application?