Microservices 101 - Kubernetes Tutorial

- [Instructor] In the dev world, one of the most popular buzz words is microservices. Almost everyone, from developers and large enterprises to startups, are talking about microservices. If you're new to the ecosystem, think of microservices as a variant of service-oriented architecture that structures the entire application as a collection of loosely coupled services. From a high level, using a microservice architecture has many benefits. First, by breaking up a monolithic service into many smaller, independent services that work together, developers have more freedom to create, manage, and deploy the individual components without compromising the integrity of the entire application. Because the surface area of each individual service is smaller, it's easier to plug in this approach into a continuous integration pipeline. Which enables continuous delivery. Microservices allow for a more resilient application over all. If one service fails, the whole application shouldn't fail hard and other components should still continue to work. This allows you to isolate faults in a better manner and make your overall application more fault tolerant. Typically, microservices are broken up with the intent to solve a specific business need or enable a business capability. The structure makes it easier to build services that can be clearly communicated to the business side of the organization. In my experience within large orgs, it's always been easier to justify technical work when it relates directly to a specific business need, as opposed to a generic code refactor. It helps us build a common language with our business counterparts. From the sounds of it, microservices seem pretty rosy. But is that necessarily the case? Like a lot of other questions in software, the right answer is - it depends. There's a lot of data on whether to choose a microservice versus a monolithic architecture. But I like the practical approach in the Martin Fowler blog article. He recommends using a microservice pattern to build larger complicated applications but a monolithic platform for simpler apps is still acceptable. For greenfield opportunities, there's an initial learning curve and many additional facets to set up with microservices that you won't encounter with monoliths. As you continue development you start to build a more complex system. During this process, you'll need more organizational knowledge of the inner workings of the monolith. This is different in microservices architecture, where you'll need to know less upfront. Later, when you have a rather large codebase or larger teams, Conway's Law kicks in and you end up mimicking the structure of your organization in your codebase. Chances are, you'll end up being more productive using the microservice architecture, rather than trying to add features or debug a large monolith. Thus, if you started with a microservice architecture up front, you'll end up seeing rewards later on in the lifecycle of the application. One of the lessons I've learned, by building microservices for many years now, is that I always think of applications in a modular way. You can certainly build applications in this way even if you're building a monolith, but you inherently end up paying more attention to how to keep your code modular by using a microservices approach. We'll spend the majority of time, in this course, looking at common microservices patterns and architectures. And see how these fit into the Kubernetes environment. My hope is that, by the end of the course, you can build out large microservices based applications using Kubernetes as your microservices platform.