In this video, take a look at microservices from both a cloud-native and not cloud implementation detail to determine the distinction between these terms and how they are mutually exclusive of each other.
- [Instructor] Let me start by saying one thing very clear, Microservices do not make a system Cloud Native. And Cloud Native doesn't require Microservices. All too often this topic gets confounded. And I want to be very clear from the beginning about this. Now, from my perspective, and from the perspective of this course, we're going to focus more on how to utilize Microservices in a Cloud Native pattern for building our system. Why you may ask? Because Cloud Native can literally run anywhere, not just in the cloud. So let's talk a little bit about what Cloud Native means. First of all, Cloud Native is an architectural style. What that means is that it isn't a pattern per say, of how to solve a problem. Instead, it is a way of doing processes and building systems to facilitate an end goal. Cloud Native is designed primarily to facilitate operating in the cloud. This is a very distinct meaning in Cloud Native environment. It includes things like externalizing configuration, focusing on scalability, making your application startup fast, and handle immediate shutdowns gracefully. There's a whole plethora of ways to represent Cloud Native applications. Be them things like 12-factors, 15-factors, or whatever you may call it. I have a course here in the library called Twelve-Factor Application development that I encourage you to look at when wanting to learn more about Cloud Native. One very clear key and summed up in much of the operations needs, is that Cloud Native applications are designed to be portable and scalable. Portability comes into play when you can deploy or move your applications anywhere globally and they still work without adding additional code. Scalability entails building your applications to run as a single unit or multiple units, depending on the overall needs of your system. Advanced designs like using auto scaling to allow your services to scale up or down based on the overall system load, increase the need for this scalability. It is very important to note that Cloud Native designs can be run in a single datacenter. There is nothing that prevents you from building Cloud Native applications and running them in your corporate single instance datacenter. This is perfectly acceptable and actually, it's a very powerful way to do things because it will allow you to grow to multiple datacenters as your business and user needs also grow. So now let's talk about Microservices a bit and that's after all, why you're here. I want to start by saying that this is very open to personal interpretation. There is no clear definition of what makes a Microservice micro. I have seen nano services that go overboard, and I've seen smaller mono less that don't go far enough. Microservices are what you make them. But dependency graphs help determine the right size. And we'll talk quite a bit about this throughout the course. For now, we will just talk about Microservices being smaller scoped units of work. When we used to build large war files in the Java world that had multiple endpoints, sometimes hundreds or thousands of them that covered many business domains, we would then deploy these monolithic war files as part of an ear often, to large WebLogic or WebSphere servers, running as a single JVM. Scaling these systems was a massive undertaking. Microservices are all about breaking those endpoints into distinct units of work, so we can scale them independently, among other things. Microservices are built to focus on units of work that span data domains, business domains, or functional domains, each as individual units. We look at call patterns and dependency graphs to find the sweet spot where the service boundary should be. But the core concept here is that Microservices can scale independently. If your customer domain is experiencing high request volumes, but your order domain isn't, you can scale one without impacting the other and eating up your compute resources unnecessarily. The most important point in my mind is these are not monolithic service artifacts. I don't get too far in the weeds of where to break them down appropriately. Instead, I focus on them being individually scalable, hence, they are not monolithic artifacts. Now, I have some services that may be considered large in some circles. But I leveraged dependencies call patterns and focus from there, not really caring about the size when I'm defining a Microservice. So there may be very little overlap in the previous two slides between Cloud Native and Microservices. But often we hear these concepts talked about at the same time. Both Cloud Native development practices and Microservices architectures, put an emphasis on building scalability into your application and system as a whole. Now, often, when building Cloud Native systems, Microservices appears to be clear path to getting there. And this can muddy the water some when talking about these two topics. It is important to note that you can do Cloud Native development without building Microservices. And likewise, you can build micro services, not targeting Cloud Native deployments. It is important to make sure that this is clear. All too often I hear people talking about one topic, and implying the other. I have seen monolithic applications written to be Cloud Native. And I've seen Microservices designs that could never run in a public or private cloud without significant refactoring. So I do want to discuss for one moment here, why these very distinct concepts often get discussed together? And the answer simply is because they do go hand in hand very often. I would not consider a new Cloud Native deployment without using Microservices architectures, at least at the current time. There just is so much crossover when solving the needs for scalability, to not use Microservices when building a Cloud Native system. So then, as we talk about this in this course about Microservices, consider that we will be directing this conversation towards Microservices built for Cloud Native deployments because most often even though they are so distinct, they work so well together to solve the common problem. So please, just take into account that even though some may consider them requirements of each other, that is not the truth in any way, shape or form.