There is no generally accepted definition of Microservices architecture. However, there are some starting points and generally accepted properties that I consider to be valid enough to see as part of the definition. Let's just start with what Adrian Cockcroft, the architect who introduced the concept at Netflix, has to say about it:
"Microservices are loosely coupled service oriented architecture with bounded contexts"
This pretty much sums it up, but it lacks detail to get a proper understanding of Microservices architecture. So, we need to analyze this sentence and draw some conclusions from it.
First of all, mr. Cockcroft is clearly seeing Microservices architecture as a form of SOA, instead of something completely different. Then he goes on to put some limitations on how this SOA should be done:
- Loosely coupled
- With bounded contexts
Why are these aspects so important?
First of all, to understand why loosely coupled is so important here, one needs to understand how much SOA applications are built. They mostly rely heavily on reusable business services, a canonical data model and a shared runtime. It's not exactly what I would call loosely coupled, since there are quite some dependencies and the impact of making changes to a service or the runtime configuration can be rather large.
Secondly, bounded context is another thing that is lacking in some SOA applications. While I've been working on projects where SOA was done quite right and each service had a single purpose, there are also many examples of services doing multiple things, having poor naming standards and rather unclear service definitions. Therefore, the context is no longer bounded and services become rather ambiguous. Any changes to them could have unexpected impact and there's a risk of overlapping functionality between services. Even if you don't consider Microservices architecture, bounded context is important for the sanity of your SOA application.
An important thing about bounded context is that the term does not imply that each Microservice can only contain one operation or only be about one object. It just has to be bound to a certain context and the granularity is up to you. In most cases, business domains are a nice way to identify Microservices, but it can be done in smaller parts, as long as the Microservice can remain loosely coupled.
Implications of "Loosely Coupled"
So, we want our Microservice to be loosely coupled. What does this mean? It means that dependencies are evil. This is a major shift from the "redundancy is evil" train of thought that we know and love from traditional database design. However, for a Microservice to be fully independent, it needs to control its own data, which inevitably means that you're going to have some data replication going on.
Since we don't want any runtime dependencies, we are no longer bound to one deployment platform. This opens the opportunity to be polyglot: for each Microservice, you can choose the appropriate technology. This can be very powerful, but be aware of the risk of too many different technologies in your organization. It would be good to set some restrictions, so on-boarding or switching developers between teams on occasion will not be a major headache.
With a separate runtime environment for each Microservice, we're also gaining the advantage of scalability. Each Microservice can be scaled to its own particular needs and a heavy load on one Microservice doesn't have the risk of slowing down another.
Ever thought of what it means for the Operations team having to manage a lot of different runtime environments with different technologies? They are going to be hard-pressed and probably overloaded. So, with Microservices architecture comes a "you build it, you run it" attitude, making the team fully responsible for the runtime application, while the Operations team will focus more on the underlying hardware.
Choreography, instead of orchestration. While in traditional SOA we are used to orchestrate services, especially in case of BPM implementations, this is introducing dependencies that we cannot have in Microservices architecture. So, we need to change our minds and think of choreography. Instead of a service telling other what to do, the service will now basically push a milestone (registered an employee, received a payment etc...) and it's up to other services to pick this up if they're interested.
Implications of "Bounded Context"
A Microservice will be focus on a certain business function. For example on-boarding, supply management, shipping or billing. Since the Microservice is independent, it means that the team developing it needs all skills to build and run it, from UI to Middleware, Database and Operations. So, you're going to want DevOps teams centered around business functionality, instead of technology. For many organizations, this is a major change in culture, while others who are further on the road of agile development can adopt this quite easily.
You need to understand your business domains really well. Microservices architecture is not just a technology fest, but it's ultimately about offering business functionality in an organized, independent manner. Therefore, you need to be able to separate your business functions really well and have a clear understanding about what each Microservice should be doing.
This blog is just a starting point to make clear what kind of thing we are talking about. I hope it helps to provide some understanding about what Microservices architecture means and how it compares to traditional SOA. In future blogs, I will expand further on what is required to be ready for Microservices, what the risks are, when it should (not) be applied, how it relates to BPM, what the relationship with DevOps culture is, how to handle data replication, how it impacts continuous delivery, how to handle events and what the Oracle Cloud has to offer in terms of Microservices. Most likely, even more will come up during the process.