[music] Welcome to what
are microservices. After watching this video, you'll be able to describe what microservices are compared to monolithic applications, explain the drawbacks of using a monolithic architecture, and explain the benefits provided by using a microservices architecture. Next, hear Dan Bettinger from the IBM Cloud team describe what microservices are and explain the advantages of microservices. For those who don't know, a microservice is an application architecture that takes every application function and puts it in its own service, that runs in the container, and these containers they communicate over APIs. To better understand microservice, we should probably look and understand what a monolith is. A monolithic architecture is a server-side system based on a single application. In a Java world for example, the application would be put into a JAR or WAR file and deployed as a whole into a production environment. The thing about a monolith is, they're easy to develop, deploy and manage. But things happen over time. Let's use an example. In this case, pretend we are a ticketing service. One that sells tickets to sporting events and concerts, etc. In a monolithic world, the architecture might look like this, where we have a user interface, we have some semblance of an inventory component, a recommendation engine that provides outputs based on user inputs, maybe a cart service. We have a payment service and then some type of reporting function to generate reports. That's great. The thing you can realize right off the bat is that these are highly dependent systems or highly dependent software, meaning that there are shared libraries within this architecture. If you make a change, you have to understand what other components rely on those libraries, so they're easier to break over time. Another challenge we have around monoliths are that they're language and framework dependent. In this case, if this is a Java application, any additional component that has to be written needs to be written in Java, so you're somewhat limited by decisions made in the past. Another thing that happens and another challenge with monolith is growth. Over time, user input comes back into the product team and the need to add additional functionality. Initially it's small but over time, you might need to add capability A or capability B for example, or capability C. Now as a whole, the application is getting much larger, it's harder for a team to actually understand what's happening to it, and hard for a team to note every little intricacy about the thing as it grows. As it also becomes bigger, it takes heroic efforts to deploy the monolith, meaning that on a Friday night, you would have to shut down the original application and then actually deploy the new production application and the apps team would spend all weekend trying to stabilize it and get it to run so on Monday it can be up and functional again. That can be very painful for teams and can be really hard. Another challenge we have around monoliths is the way they scale. If it's really busy, and there's lots of people trying to buy tickets in this example, maybe that payment part of the application is under duress and it needs some additional capabilities. What would happen is, you'll have to redeploy the whole application to help satisfy that demand and that need. In this instance, we would need to go ahead and redeploy another version of this system. What that looks like is right now, so we have one system running. When this is under contention, we deploy another version of that application. There's number 2. The challenge is, it might take a lot of time to you go add that new instance of the application, and by the time it's up and running, that peak may have already subsided, and effectively, you've done nothing to help your users. That's a challenge around the monolith as well. Let's look at the same example of the ticketing company in the microservices based environment. Again, in microservice environment, we'd have the same functionality, you'd have your user interface, it would be in its own container as a service, you'd have your inventory service as well, your recommendation engine would be in its own service, your cart is in its service, we had the payment service and we had reporting. It's the same as the monolith. The difference is these all talk over APIs and right off the bat you can see something it's interesting. Because they're independent, the team responsible for the reporting engine for example, can choose a language and framework that they want to use themselves. They are not beholden to choices made by the team that run the cart, or UI, or the payment system. That's really good. It gives those teams flexibility, so that's the language part. Another benefit is the ability to iterate. Because these are independent components and they just talk over APIs, the team responsible for the reporting engine for example, can commit code that goes to the DevOps pipeline, and once it gets tested and it's proven to work it can automatically be deployed to the environment. Thereby, these teams can iterate as fast as they need to bringing value to the customers. That's fantastic. Additionally, these changes are minimal at best. If there is an instance where a service does fail, the rest of the application is still functional, so that's less risk. We also can scale these independently, meaning that in the case where there's a user or a number of users that drive load, and that payment service needs some additional help, what needs to happen is the system can actually add capability automatically just for that particular service until that load subsides. Eventually, what happens is when the load goes back to its regular cadence for example, those systems and those additional services can scale back to normal. Again just to reiterate, the microservices architecture is where every application function is its own service deployed inside of the container environment, they communicate via APIs, it got a language and framework independent, we iterates at will through DevOps pipeline. This reduces some of the risks that we see and then we can scale these components independently. In this video, you learned that microservices make each application component its own service and each service communicates via an API. Microservices allow application components to use different technology stacks. Microservices enable individual components to scale in response to demand and microservices lessen risks associated with change, because components can iterate independently. Failures in one service do not necessarily impact other services.
