(Note: the following has been summarised from the book "Antifragile Software: Building Adaptable Software with Microservices" book)
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:
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
This is the hardest thing to remember do, as it leads to the 'right' set of microservices, and then evolves that set over time as the domain is research and developed.
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.
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"
Attempt to enable people to own their own code in development, and in production.
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.
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
Think about enabling continuous delivery to each of your services, to enable them to evolve at their own specific rates.
4. Test services in a language and platform independent manner
Test and design the contract on your services first. Attempting to avoid Tareq's deadly sin number 2.
5. Think about Events and Event streams as the High-Level Ubiquitous Language between your Services
Some microservices may be resource/entity-centric, others will not be.
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.
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
Think about what change your unique context needs to support, don't just copy the breakdown of microservices from other systems.
Carefully aim for the systemic-benefits of embracing change, enabling innovation and obtaining speed of delivery. Microservices is an architectural style for this.
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
When embarking on adopting microservices you are making a decision to build a distributed system, where things will fail all the time.
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.
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.
Russ is CTO at Simplicity Itself Limited, the Enterprise Microservices Consultancy who provide various services such as Microservices Bootstrap, Team Augmentation and Adaptive Learning to work with their clients to harness the competitive advantages of microservices adoption.
RSS Feed
