Good day, everyone. I am Jubin Thomas. I work as a technical architect at Signet Jewelers, having 14 plus years of experience in supply chain and retail. I'm also a senior member of IEEE. Before I move on to my topic, I would like to thank Mark and all the organizers of CubeNative Conference 2024 to invite me as a speaker. Today, I would like to discuss about architecting order management systems with scalable microservices with the help of Kubernetes. So as you all know, microservices has taken the world by storm and order management system is one of the systems where microservices has actually helped to scale in a very some of the companies who already have the implementation of microservices are Netflix, Spotify, eBay, Amazon Web Services, Airbnb, Uber, Nike, Twitter, Walmart, and Verizon. The agenda today is basically to go over the overview and infrastructure architecture of microservices. What are microservices? When should we use them? What is the right size for a microservice? Why is microservice better than monoliths? Infrastructure architecture. Then we will go over the software architecture and design capability centric design, understanding the route and a small example of a shopping menu or a shopping cart. The microservice scalability, the disadvantages with the CRUD. And then we will also discuss about the testing strategies with microservices like microservice testing tools. And finally, we will discuss about what is docker and kubernetes and we will go through the kubernetes architecture and the kubernetes concepts. So what is a microservice? Microservice is an approach to a Engineer focus on building single function modules with well defined interface and operations and It basically minimizes the risk and scope of change. It is easy to deploy easy to understand across the business And the diagram which over here is something which gives us a good comparison between a monolith architecture versus the microservice architecture. So if you see the image on the left hand side, it says that there is a user interface which connects to the business logic and which connects to the data layer and data layer is actually connected to the database. So there is a monolithic structure in place, which gives a very hard dependency of deploying any particular new feature. But at the same time, if you look into the microservice architecture, The same user interface is actually divided into multiple microservices and these microservices are actually connected to the respective database. So this gives us a flexibility to deploy these individual components separately. So that is basically a great advantage which microservices provides to us. Now what is the right size for a microservice? Now this question comes that, what kind of size we should have for a microservice or how can we define the business logic of a particular microservice. So the answer to that question is the business function or domain of the service determines more important than its scale. So you know, for example, I was talking about the order management system. So like payments is the one of the module of order management. And then we have. checkout as one of the different module of the auto management system. These module itself is actually playing a more important role comparatively than the scale of these individual modules. So one microservice might have dozen of entities and the other the dozen of entities, more importantly, it is a part of the microservice play. And emphasizing user stories will enable us to precisely outline the limits of the business domain. Now, why is Microsoft is better than monoliths? So as we discussed in one of the previous slides, this monolith architecture is built as a large single unit. It has RDBMS, which we call it as database. Then it has the backend code. It could be in Java or any other language. And then we have the front end code like HTML, JSP and ASP. And these features additionally requires the entire unit to be deployed. See, this is the dependency which you were talking about. Okay. When we need to scale, we have to have multiple copies of the entire application. And on the other hand, the microservices is small. autonomous services that work together. It is loosely coupled with bounded context, and it is a natural consequence of applying SRP at the architecture level. And this is a typical flow diagram of how the monolithic app is in picture versus the microservice architecture. So on the left hand side, the image what we see is. Basically for a monolith app wherein we see that there's a UI layer and then the, business layer, database layer, and the front end, everything is all together as a single application. And as I was talking about the order management system, so these four functionality, like the shopping cart, or basically the checkout functionality, then the order system, which basically places the order. Then we have the customer system, which basically maintains a track of different customers for that particular brand. And then we have the inventory system. So all of these four systems is all together binded in a single monolith application. But at the same time, if you look into the right hand side, these four different applications like the shopping cart, order, customer, and inventory, it The dependency is actually broken here and all these four are four separate entities altogether. So customer is a separate entity, order is a separate entity, shopping cart is a separate entity, inventory is actually a separate entity. And this is the greatest advantage which microservice provides that it also helps to dependency of the database. So if you see customer is actually having a radius and order is basically in MongoDB and shopping cart is in SQL server and inventory is actually the oracle database. So it gives us the flexibility to have multiple entities, multiple databases, but at the same time it can talk to each other. Now I will actually go through the the capability centric design, which is one of the design technique in microservices. Basically the business centric development focuses on business capabilities. So the microservices is actually built based on capabilities. So as we saw the example, which I was previously telling the example of order being a separate entity inventory being a separate entity. So these are different capabilities. which this monolith system, which is order management system can provide. And the responsibility what we have right now is to break this monolith system into multiple microservices. And each of these individual systems. functionalities like the inventory or payments or checkout, all these are different capabilities. So here in this case, we see that each capability is having the front end back end in the database. And then there is a product team which basically operates these Now understanding the root. So An aggregate will have one of its components objects be the aggregate root. Any references from outside the aggregate should only go to the aggregate root. The root can thus ensure the integrity of the aggregate as a whole. And if you look into this, the order is actually connected to all these different microservices like the payment strategy and the payment is actually having credit card, cash, bank transfer. At the same time, order is actually connected to the customer because the customer is the one who places the order and then the order can have multiple line items and it has a shipping address. So this gives us a better picture of how this is actually divided but at the same time connected to each other. Now this is a typical shopping menu or a shopping cart. So we have the order being the primary microservice, and then we have the do domain layers wherein we have different entities like order or item, shipping, address and payment. And then we have the service port. Which is Order Repository, Order Service, Order Web Service, Order Query Web Service, Shipping Address Web Service, Payment Web Service, and then we have the utilities like Order Factory, Order Status Converter, Record State Converter. What are these adapters? So we have these several adapters which helps us to connect to the system individually like the order repository adapter, order service adapter, order web service adapter, order query web service adapter, and so on and so forth. So these adapters, which basically consists of actual implementation of the ports like database access, web services, API, etc. And the converters are actually used to convert an enum value to a proper integer value in the database. For example, order status complete is mapped to an integer value 100 in the database. Now CRUD, as we all know about CRUD, CRUD is is basically create, read, update, and delete functionality. So it basically has a presentation layer, then a service layer, then business logic layer, and the data access layer, where we can basically query the database and push the updates to the database. So what is the disadvantage with CRUD? It is basically doing a mismatch between the read and write representations of the data, It risks data connection while records are logged in the data store in a collaborative domain where multiple actors operate in parallel on the same set of data. These risks increase as the complexity and throughput of the system grows. It can manage security and permission more quickly. complex because each entity is subject to both read and write operations, which might expose data in the wrong context. Now we will discuss about the different testing strategies with microservice. Just like the other systems, Microservice also has the various testing like we have the unit testing is basically the smallest piece of testable software in the application to determine whether it behaves as expected. Then we have the component testing, which basically helps us to do component level testing. Then finally, then we also have the integration testing, which defines the communication paths and integrations between components to test and detect interface errors. defects. And then we have the integrate integration contract testing, wherein we basically do a contract Test within the boundary of an external system verifying that it meets the contract expected by a consuming service And finally there is an end to end testing which basically tells that a system meets external requirements and achieves its goals Testing the entire system from end to end And some of the tools which we can actually use for microservice testing is Cucumber and JUnit, which helps us to do a mock, and then we have Mockito, which is a great tool to basically mock the service responses when each service is actually connected to the other one. Moving on to the side of deployment land. Now, I actually spoke about microservices. I spoke about the monolith systems. Now, when it comes to the deployment, there are a few things which microservice comes handy with, and it really helps a lot. Especially when we work with docker. Now, what is a docker? Docker is an open source platform for developers and sysadmins to develop, deploy and run applications within the containers. It works on the principle of build, ship and run. As you all know that build is a command, build container images on local laptop or automated through continuous integration pipeline ship container images through container registry, et cetera. And run is to run anywhere on cloud and on prem. So this is a typical docker architecture where we have a client side, which basically does a docker build, docker pull and docker run. And then we have a docker host, within that we have a docker daemon and the containers with the images. And at the other hand it has a registry, and all of these are actually interconnected to each other. Now let me talk about kubernetes. Kubernetes is an open source system for container orchestration. So we spoke about the docker and the containers. So kubernetes is basically a platform which helps us to manage these containers. containers in an effective way. And it is focused around scheduling, scaling self healing and auto repairing. So this is a typical Kubernetes architecture where we have an API, which basically connects to CLI interface. And then we have a Kubernetes masters, which connects to multiple nodes and the image registry. And there are. certain kubernetes parameters which I would like to talk about and when we talk about kubernetes, we definitely talk about these things. So one is pods. So pods is one or more containers and volumes. It has shared namespace. one IP, it has one IP per pod. And then we have services. Services is something which gives us a stable network endpoint and it has a label selector and also the load balancing within it. This is what I would like to share as part of my talk. I thank you so much to listen to me. This is my email ID, jubin. thomas at itriplee. org. I request you to please reach out to me if you have any questions. And once again, thank you for having me.