Moving from Monoliths to Microservices

Learn more about microservices at Streaming Media East 2020.

Read the complete transcript of this clip:

Nathan Moore: I usually define microservices in contrast to a monolith. So with all computer programs, all apps, you have an input, it goes away and you have this black box that does something with that input to give you an output. And the whole point of a monolith is everything is hidden behind that black box. But with a microservice, you break out that black box into the different stages of its workflow. You can then encapsulate the state of what each work stage has to do, such that you can pass that around as its own separate thing. And what this allows you to do is exactly open up the world to be able to rip out a work stage and replace it with a completely brand new one without changing any of the rest of that pipeline.

So it's a really good way of breaking down the workflow and it's a really good way of making sure that everything is correctly encapsulated, such that you do not accidentally destroy something else. And being able to break your workflow out into those individual stages, where each stage is appropriately encapsulated for what you want that particular stage to do. So every stage has an input, has an output, passes that off to the next-stage input/output, and so on and so on down the chain. So you get this sort of chain microserviced together in order to get you your final answer that you actually wanted in the first place.

So that's the first thing, though you have to understand the problems base well enough that you can break it into its individual components. To continue with the discussion on state, you have to know ideally, everything is sufficiently discrete that you don't have to pass any state data across if you're lucky. If you're unlucky, it comes down to your specific use case. Maybe you have to shoehorn something in to accommodate for that. But once you understand the workflow, then you can break it out, and then you can determine what it is that you want it to do, and then you can start applying the usual failure analysis against this, you can start applying the usual separate and discrete logic that you want that particular one to do.

Olga Kornienko: We are on the opposite side of moving people from a monolithic environment over to our microservices, mostly because we believe that, just like Nathan said, in a monolithic environment a process does everything, and figuring out a point of failure sometimes is really, really hard. And if the whole system fails, digging through various pieces to see which one actually failed is a process, whereas if you can catch, just like you said, input and output, and see where the process is going, and figure out the one piece that is failing, is the part that you want to do.

Dom Robinson: What were the business drivers for moving to microservices with a DRM service?

Olga Kornienko: Well, I guess with a DRM service you are looking at somebody who is a specialist in the field. You don't want them taking the non-technical approach to it, you don't want your plumber installing your lock on your door, because they are not the person who knows what they are doing. And in a microservices environment, the idea is to find, in any microservice--be it DRM or anything else-- the idea is to find a person who knows exactly what they're doing, and just because they can do 12 other things, you don't really want them doing your security as well.