This video offers an explanation of services and service types.
- One of the first questions I am always asked when discussing microservices is what makes a microservice just that? And in reality, it's a compound answer. I want to start by stressing that it isn't as much about the size of the service, but the operation of the service that really matters. There isn't a finite requirement on size. Before we get into the size question, however, let me answer one of the easiest parts of the question, and that is how the services communicate.
In a microservices architecture, all communication between services leverages REST over HTTP. There are other methods like event-based communications. However, the intra-service calls are all REST based. This is a powerful proposition, especially for large organizations. Consider a company the size of Amazon or Netflix. Both of these companies leverage microservices-based architectures.
Each of their teams can build software as they see fit, as long as the services are exposed via REST. Each team can them consume the services of another team because they all communicate in a common way. Now I hope you can see the need to unify service documentation. There is no standard way of documenting RESTful services like we had with WSDL in the SOAP world, so developing common means of service documentation is critical, especially in large organizations.
Along with documentation is service discovery, but we will talk more on that later on. So let's return to our size conversation. In a microservices world, size isn't as critical as operations. A microservice handles one set of related functions with little or no cross-domain operations. This is where concepts like domain-driven design come into play, and we will spend a significant amount of time talking about domains in a little bit.
I like to use the analogy of good object-oriented programming practices when describing microservices. In a well-defined OOP space, a class is built to handle one type of thing and provide the operations for that type. In a microservices architecture, a service operates on a well-defined domain. Operations aren't defined on data objects or business objects.
Instead, it's the domain as a whole. Now you can and probably should provide very low-level, data-focused services in a microservices architecture. Often, these services expose domain-specific CRUD operations on the domain object, but that domain can span multiple data objects. You can also build a service to handle a set of related business processes that may spin one or more domains.
The answer here, to the size question, should be domain operation-focused. In my opinion, this is one of the hardest parts to learn. All too often, when a company or team moves into a microservices architecture, they build their services either too fine grained or not fine grained enough. Usually, however, it's the former. This is a common occurrence. And quickly, the distribution tax will hit you hard as the latency of calls really kicks in.
As you start building these services, don't be afraid to refactor. And my hope is that, by the end of this course, you will be more willing to experiment. The ability to experiment comes from the size of these services. Yes, size isn't part of the answer, but logic will tell you that, as you start decomposing these services down, they become smaller in size.
Smaller services build faster, have fewer test scenarios, and deploy and start up much quicker. All of these aid in the willingness to experiment and make mistakes because you can fix those mistakes much faster in smaller components of code.
- 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