hi I'm Darren Bettinger with the IBM cloud team today I'm here to enter the question what are micro-services 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 a container and these containers then communicate over api's to better understand what a micro-service is we should probably look into understand what a monolith is the monolithic architecture is a server-side system based on a single application in a Java world for example the 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 Lesly 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'd have a payment service and then some type of reporting
function to generate reports so that's great the thing you can realize right off the bat is that these are highly dependent systems or highly dependant 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 those libraries so they're easy to break over time another challenge we have around model ifs are that their language and framework dependent so when the 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 monoliths is growth over time user input comes back into the product team and they need to add additional functionality so initially it's small but over time you might need to add capability hey 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 know 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 team the ops team would spend all weekend trying to stabilize it and get it to run so at Monday it can be up and functional again and that can be very painful for teams and it 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 the payment part of the application is under duress and it needs some additional capabilities what happened is you would have to redeploy the whole application to help satisfy that that demand and that need so in this instance we would maybe need to go ahead and redeploy another version of this system what that looks like is right now is we have one system running when this is under a contention we need to redeploy another version of that application there's number two the challenge is it might take a lot of time to
go add that new application the 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 so that's a challenge around the monolith as well let's look at the same example of the ticketing company in the micro services based environment so again a micro service 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 your cart is in its service we had the payment service and we had reporting so it's the same as the the monolith that differences these all talk over api's and right off the bat you can see something that's kind of 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 toward the UI or the payment system so 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 api's the team responsible for the reporting engine for example can commit code that goes through the DevOps pipeline and one site gets tested and it's proven to work it can automatically be deployed to the to the environment so thereby these teams can iterate as fast as they need to bringing value to your to the customers so 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 the until that libs load subsides so eventually what happens is when the load goes back to its regular regular cadence for example those systems and those additional services can scale back to normal so again just to reiterate the
micro services architecture is where every application function is its own service deployed inside of a container environment they communicate via api's their language and framework independent we iterate at will through a devops pipeline this reduces some of the risk that we we see and then we can scale these components independently so thank you for your time today if you like to learn more and see more light boarding videos check us out on the IBM cloud blog
