A couple of weeks ago I was very fortunate to be able to attend the excellent GOTO Amsterdam conference. One of the tracks was all about microservices and since the company that I’ve been working for as a contractor for the last year is struggling to move to a (micro)service architecture, of course I just had to attend most of that particular track.
Right now the hype around microservices is fully raging, and it would appear that every company is wanting to board the bandwagon. With Netflix constantly being hailed as the paragon of a company that has succesfully implemented a microservices architecture, it is easy to fall into the trap of thinking that moving to a microservices architecture is going to be a piece of cake. Even Netflix didn’t get it right from the start and there probably was a lot of trial and error involved.
So I was delighted to hear some war stories at GOTO Amsterdam. Listening to people like Fred George, James Lewis, Remmelt Pit, Steve Judd and Tareq Abedrabbo whilst they were providing an objective perspective on the subject, was very enlightning.
Here are some preconditions, caveats, and pointers that I have taken away from the conference, or that I have personally experienced over the last year. They are in no specific order, and can be somewhat opinionated :-)
Start with a monolith first
As Martin Fowler suggests in his blog post Monolith First do start with a monolithic application before even considering a microservices approach. Or to paraphrase his First Law of Distribution: “Don’t distribute… unless you have a very compelling reason to do so.”
Of course, one still has to design and code that monolith well. I quite like the way Simon Brown has bluntly put it: “If you can’t build a well-structured monolith, what makes you think you can build a well-structured set of microservices?”.
Clearly define your bounded contexts
I have found clearly defined bounded contexts to be an absolute prerequisite for any architectural style, and even more so for microservices. Don’t focus on data, or canonical data models, or the likes. The bounded contexts are all about your business domains, and their processes, and not about datastructures. Without clear boundaries, you’re very likely to end up with a “distributed big ball of mud”.
Be sure to avoid sharing domain libraries across contexts.
Cloud infrastructure and DevOps teams
A very complex infrastructure is inherent to microservices. If your organization is not using cloud or containerized (Docker) infrastructure, and is not structured in DevOps teams, but still uses data center or VM-based infrastructure and has dedicated OPS teams, then don’t even consider moving to an microservices architecture.
Deconstruct the database
When considering microservices be willing to deconstruct the database. You will end up with a multitude of datastores, typically one per services, and a lot of different types (RDBMS, graph-databases, document stores, in memory key-value maps, etc.). Make sure your DBAs are willing to give up on the one and only central Oracle instance.
WTFM
As Remmelt Pit stated at GOTO Amsterdam, “With microservices there is no RTFM, instead you get to write the manual (WTFM)”. You literally have to figure out everything on your own, and basically start from scratch. There are no de-facto standards yet when it comes to frameworks and tooling. Still you have to think about and implements matters such as monitoring, logging, lifecycle management, externalizing configuration, handling failures, inter-process communication, end-2-end testing, etc.
Whatever frameworks and tools you will be using, do automate everything!
| Reference: | Don’t jump on the microservices bandwagon from our JCG partner Wim van Haaren at the JDev blog. |
