Some Thoughts On Shippable Software And Microservices
Stop reading now if you don't care about the machinations, architectures, and human reality of software. This post is for software philosophers and architects.
Dries Buytaert, the founder and core committer in chief of open source Drupal (according to Built With, the second most popular content management system software among the top million web sites) posted thoughtfully on keeping his open source software always in a shippable state. He writes this after a 3-year delay in releasing Drupal 8:
"We [will] create a feature branch for each major feature and only core committers can commit to feature branches. . . . Once we believe a feature branch to be in a shippable state, and it has received sufficient testing, we merge the feature branch into the main branch. A merge like this wouldn't require detailed code review."
This is sensible and now standard practice: Develop new features as decoupled components so committers and software managers can add them to the application without breaking it. That keeps the application always in a shippable state.
But the future of software is more than decoupled components. It also requires highly decoupled runtimes. That's called a microservices architecture: decoupled components available over the Internet as decoupled services. Think of it as a software component exposed as a microservice — a microservice component.
A microservice to place an order is decoupled from a microservice to alert you that your shoes have shipped. A microservice to display an image sized to your phone or computer is decoupled from a microservice to paint the page.
The hard part is getting the components the right size and connected in the right way.
Robert Zores, PhD, the CTO of REWE Digital, says that a microservice component should only be as big as a small development team can build and test in a single month. And if the service or API needs to be enhanced or extended, build a new one.
That's the software philosophy part. Now for the web application reality part: The vast bulk of the installed base — and shipping products — of web content management (WCM) technology is in a state of turgid morbidity: tightly coupled software stacks built off 10-year old assumptions of computing power, storage, and bandwidth.
It's no surprise, really. The power of software and networks multiples every year while software architectures advance only linearly with each new generation of software architects and developers. There is naturally a lag between what's possible and what's shipping.
It's also time for a change. The complex interplay of software components to serve customers on every touchpoint, device, and step of their journey is mind boggling and stifling in an old software world. Tweak the wrong interface and watch the whole experience crumble. It sounds like Drupal 8 suffered from just such an interdependency. Adobe, Sitecore, SDL, IBM, Oracle, and many other WCM solutions also suffer from this component collusion.
Fortunately, some other WCM and digital experience technology vendors — Hippo, Magnolia, Contentful, CommerceTools, and Backbase among them — have embraced microservices architectures already and others, including Acquia, Adobe, and IBM are joining them as they embrace the cloud. These vendors are building microservices architectures to deliver business capabilities as SaaS microservices over lightweight Internet connections.
The software must always be shippable — the cloud demands that. Microservices is the way you will build decoupled components and highly decoupled runtimes so you can improve your capabilities without breaking the application. Do what it takes, dear architects, to get us on that continuous release trajectory. Your customers deserve it.