Join David Linthicum for an in-depth discussion in this video Use cases, part of Cloud Architecture: Advanced Concepts.
- [Instructor] Let's talk about the use case for microservice, and there are a number of use cases. You got to remember that this is a development oriented kind of technology. We're going to leverage microservices whenever we want to reuse services that are typically going to be fine grained. These are typically going to be leveraged remotely. They're not going to be embedded in the application. They're great because we can reuse things that other people have written. We can reuse things that we've written and it's very much a productive paradigm as you move into cloud computing or any development for that matter.
They can be used anywhere where services can be decomposed in the microservices and reused. That's core to this. If you look at microservices, they can be leveraged as serverless components, in other words, the ability to leverage serverless based systems. We talked about the marriage there. If we're building serverless based components we can build microservices that are themselves serverless, which means they're dependent on serverless technology, which if you understand the benefits of cloud computing, and serverless computing, systems such as Lambda and Microsoft Functions, they're able to allocate the server resources back in resources automatically.
Therefore they can scale. Microservices are innately scalable using this technology or they could be within a component based technology or a container based technology, where we use schedulers and orchestrators to do the scaling. They're service oriented. We can go through a repurpose exercise in microservices. Remember, if we build a microservice, and they're compiled and they're binary, it's typically we have to accept the behavior and the data that the micro server is able to provide. Many of those are configurable.
You can pass in parameters and change behavior and change the way in which it handles data. You're going to typically take what the microservice does. You're not necessarily going to have an opportunity to change it. However there are microservices that come with code. If they do and it's open source code and you have access to it, then you can repurpose the microservice. In other words, you can take it and you can change it so it's able to work for you in a specific way. That typically means changing the code. When you do that, by the way, that becomes your microservice.
You have to maintain it. You have to check it back into the repository, GitHub, or whatever. You're responsible for changing this service and maintaining the service to make sure it lives up to the needs of your application, versus if we're leveraging a microservice that somebody else writes. We don't have access to the code. It's up to them to maintain the service or up to us to basically see if we trust those folks to maintain the service over time. And then there's reuse, which is reusing something without making changes to it. This is typically the way we want to leverage microservices because we're able to reuse the microservices over and over again.
We don't have to pay to write the services, typically. It's just a matter of finding the services in a repository, such as GitHub, leveraging them, and then embedding them into our application, as basically an invocation of a service, which is going to be hosted on a remote machine, typically.
- Microservices and containers
- Complex, disturbed, serverless, and composite architectures
- DevOps integration
- High-performance solutions