Microservices

We (myself and my close colleagues with whom I’ve worked on this) believe that a microservice approach to enterprise software architecture holds many benefits. It is an increasingly hot topic, not least because Netflix do it. And it is an increasingly polarising one, not least because Netflix do it! It is often lauded for its scalability, but that is not the greatest interest to us. At almost the opposite end of the scale is where our interest picks up, in that a microservice suite should be easily replaceable. What kind of ambition is that?! Software is like the people who write it – always claiming to do and know everything, and then sagely reviewing that after another year of growing up. Things change, people change, needs change; and software should change. But some software can’t change, or easily be replaced. People eventually hate that software. We want ours to be maintainable, extensible and ultimately replaceable.

We did not arrive at this preference by following the flock to the latest fad. We boiled down numerous day-to-day architectural decisions, burning off the distractions of ‘how’ and ‘why’, until we reached a simpler definitive ‘do’ or ‘do not’. In doing so we came to a design that we would not have reached if we’d allowed ourselves to become embroiled in the daily scuffles between framework devotees. Our transcendence brought us to a design which we realised was a definition of microservices. Having reached that through logical reasoning, we had no cause to mistrust the answer; so we began researching industry-best-practice in that field.

Each bold decision to depart from “the norm” causes more cracks in the old foundation, until there is little remaining of the de-facto approach. This makes for a steep learning curve with no shortage of challenges – but we are driven by the purity of our original vision. And we are confident that time invested now will pay dividends in the future.