In this video, explore the reasoning and overview of the strategies behind decomposing monolithic services into microservices as well as designing new services using appropriate decomposition-based patterns. Additionally, learn about the key differences between greenfield and brownfield development strategies.
- [Instructor] We have talked about microservices being smaller, but what does that really mean? Consider for a moment how you decompose a problem when writing a piece of software. You don't cram everything into a single function and finish. You break the problem into logical steps and convert those steps into reusable functions that can be used as the code base grows. This is much the same with microservices, but instead of a single problem statement, you are looking at all of the problems across the system as a whole, that you're operating within. The first area of decomposition we will talk about is the service types that you can create. These are designed to provide very specific uses across the system as a whole. Each service has a distinct function in the system and through building these services, we decompose the problems we need to solve into smaller blocks of work. Domain-based services are usually one of the first areas we attack when building microservices. We will discuss how we use domain driven design to build functional domains, and then break up our system on these domain boundaries. These domains can further be broken down into functional needs like data domain services or ed services, but only if those are called upon, based on our architecture as a whole. Another breaking point in service designs comes from your business processes themselves. Sometimes, complex processes have so much inherent coupling that you cannot further break it down into smaller domains while still maintaining sustainable traffic patterns across your system as a whole. Because of the needs of network health, these business process domains become a clear point of delineation within your system without further breaking them down. Now, in some business models, eventual consistency isn't an acceptable model. While these are few and far between for most industries, there are some use cases for this, especially in the financial services realm. As such, business process themselves maybe too granular to still achieve an atomic state. So, you need to build your decomposition model around the atomic transaction itself. And we're going to get really deep into this because this is an important point. Functional use patterns. We need to talk about ways to achieve this in a microservices architecture as a whole. The first one that we will discuss is a very powerful strategy to migrate from a monolithic system into a microservices architecture based on other design patterns. And that is called the strangler pattern. It is by far the most common pattern talked about when dealing with microservices, because often, we are breaking down monoliths instead of writing new systems. Another strategy that we will discuss that often gets used to promote separation of concerns across the system as a whole is the sidecar pattern. This pattern allows us to offload often operational security functions into separate functional components that they themselves get deployed alongside the main service component so that we don't litter our code with all of these functional needs across the system as a whole. So now, that we have an overview, let's jump into our domain-based services.