In this video, see a high-level overview of what microservices are.
- Microservices-based architectures are really the new kid on the block, but they aren't babies. In fact, many of the concepts of microservices architecture can be traced to core roots of SOA and other service-based architecture patterns. As with all patterns in software development, there is no silver bullet, and that is the theme that we will discuss throughout this course. Let's start the discussion with a 50,000-foot view of what microservices means.
At its core, microservices are about decomposing the system into more discrete units of work. In my view, microservice development is about making the architecture at a component level work the way good development practices do with modularization of the code itself. When we are taught how to solve problems in software, we're taught to decompose the problem into smaller problems and then solve each of these problems in a modular and decoupled fashion.
Microservices simply takes this concept and applies it to the system as a whole. There is no real size requirement on microservices. It's about building the services the right size for the use cases. Microservices embraces the concept of protocol-aware heterogeneous interoperability to handle all communications. This means that every call within the service boundaries are solved via REST.
This common communication allows microservices to be implemented in a true polyglot fashion as long as the language provides some mechanism for creating, responding to, and executing against RESTful endpoints. Microservices are just as much about the communication as the services themselves. In a pure microservices architecture, each unit of work can be called from any other unit of work within the system.
This ability to call any service provides a lot of flexibility, but can also lead to headaches, and often hybrid architectures are leveraged to solve these concerns. This architecture pattern has really gained incredibly popularity in both the traditional enterprise and startup communities, and it has done so for a good reason. SOA was expensive to implement and get off the ground. Microservices, however, are cheap.
In fact, the entire execution and proxy environment can be done entirely with open source software. Even if you choose to build a cloud-native platform to execute your services in, you can do this entirely as open source. The more you dig into the framework as a whole, the more power you will see in leveraging the OSS model. There is, after all, no better experience than learning from the mistakes and successes of your peers.
We did see this level of hotness before with SOA, but it really only applied to enterprise shops for the most part. But that excitement quickly fizzled out, whereas with microservices, so far, it hasn't. While there are many reasons for this, I believe agility and the ability to distribute these systems are the most critical reasons why the level of interest continues. As we go through this course, we will definitely focus on the positives that this pattern brings, but we must temper our excitement some and look at what we pay for in moving to this pattern.
- Reviewing the history of service-based architectures
- Microservices and cloud native
- Communications in a microservices architecture
- Data domains as a service boundary
- Logging and tracing in a microservices architecture
- Continuous delivery as a requirement
- Addressing design considerations and patterns
- Embracing a DevOps culture