There is a lot of talk going on about Microservices architecture these days. Since I presented about the subject at the NLOUG Tech Experience this year, I’ve been getting a lot of questions and comments about it, so I’ve decided to make a more structured breakdown through a series of blogs. To kick things off, I will explain what Microservices architecture is, which in itself is not that simple.
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. Read the complete article here.
For regular information become a member in the WebLogic Partner Community please visit: http://www.oracle.com/partners/goto/wls-emea ( OPN account required). If you need support with your account please contact the Oracle Partner Business Center.