Yesterday I wrote about 8 ways to lose at microservices adoption.
Today I'd like to flip over to the positive side of things and share with you some of the advice that we in Simplicity Itself often find ourselves giving throughout the successful microservice adoptions we help our clients with:
1. Think about and Visualise Change
It's an essential task, and doesn't even have to be done too thoroughly. Just thinking about and visualising change a bit, even just for fun, is often enough to improve a design a huge amount.
I always find it surprising how many architects and designers have never even considered change at all. I call that Platonic Thinking in the Antifragile Software book. Platonic thinking assumes that we know what we're doing and that the perfect, ideal, system is being built.
This is just not the case. We are involved in research and development, where the domain of the software system being built is being deliberately explored and discovered, and so we do not know what we're doing, and that's ok!
No system is ever perfect or ideal, it will always be subject to change and it is in this stoic thinking that great designs can be evolved.
Doing a short but regular premeditatium on how change is accommodated by your design will pay big dividends, and at the very least lead to a better set of microservices that actually embrace change.
2. Aim for "You Write It, You Run It"
This is often not possible given regulatory concerns etc, but a major win if you can achieve it.
In fact, this is the heart of DevOps in my opinion and although tooling has an enabling part to play the big culture change that can help you win with microservices is in Adrian Cocklofts wonderfully pithy phrase, "You write it, you run it".
Many good things stem from just that one phrase and its intention.
3. Continuously Deliverable Independent Services
4. Test services in a language and platform independent manner
5. Think about Events and Event streams as the High-Level Ubiquitous Language between your Services
We've found many systems start off being resource-centric through REST-default micro service adoption anti-pattern, and then move away to Commands and Query events over reactive streams over time as the design evolves.
6. Don't Copy; Pragmatic, not Dogmatic
Carefully aim for the systemic-benefits of embracing change, enabling innovation and obtaining speed of delivery. Microservices is an architectural style for this.
7. Consider Antifragility Early
Failure and Change are the norm in microservices-based systems, so there is danger in progressing without carefully considering how to thrive on those stressors.
Antifragility gives you some real tools to consider and address this; even turn it to your advantage!
Antifragile thinking changes your whole perspective on software architecture and design and will help you gravitate to the right design and architecture for your unique context to get the most from microservices.