You are here

Microservices architecture

This post follows on from Global groupware requirements, which describes the software a lot of people seem to be looking for. The distinction between a website with content and a web application is becoming sharper, and its clear that systems in the paradigm of content management (like Wordpress and Drupal) are not optimal for social organising.

I've been convinced for a couple of years by another approach proposed by David Bovill, namely that REST microservices are the way forward.

Web 2.0 involved building large back-end systems like Drupal, which generated and sent full web pages to the browser. All the features you wanted in an app had to be implemented in the same framework running on the server. As we move towards app-based architecture, apps manage the user experience completely on the device, i.e. the mobile phone or tablet, and they pull and push data as needed and render it in the User interface.

Architects of heavy duty systems like Twitter have turned to microservices because they scale well - each service can live on an optimised server. But David's sees a different value in them because they make it possible for different organisations who want to be interoperable but who have different brands and different functional requirements to share code and and become interoperable. For example you could have a calendar microservice which allows users to add events to a database. The events database can be visible to other groups using that microservice, or the microservice might offer a federated search. Other groups might not want events, but they could still find each other.

Furthermore, each microservice can be written in a different language, and they can make superfast REST calls to each other, which means any volunteer developer who comes along can contribute.

I recently started to realise though that this approach isn't as simple defining an API for each function, writing the front and back ends and switching them on. Though individual microservices are likely to be relatively simple scripts, they won't operate entirely independently and will more likely depend on and refer to each other to some extent. For example any posting like a calender entry will want to reference the name of the person who posted it. And certain configuration options, (which could be in any microservice), might need to go through a governance process, such as a vote by committee members, to be changed. So before we could start bulding microservices, we would need some kind of a core, and an API for communicating with that core. Features like:

  • Allow disallow search bots
  • Translation interface
  • Download data backup
  • grant & retract user roles.
  • message all members
  • Need multiple channels to contact members, e.g. whatsapp, Telegram, Email, Discord
  • Edit the menu
  • Edit the contact email for the site admins
  • invite a user
  • Store and access files like pdfs and working files in a common space.
  • Compose newsletter
  • Member notification options. (personal digest module)
  • manage categories
  • create a new photo album
  • Admins can keep private notes on users
  • Edit the email footer

Commercial platforms like Liferay and Mulesoft have various answers to these questions, but we will only consider open source! David has proposed a new project called Platform Earth which aims to create this open source core. So I have my fingers crossed, but I'm not holding my breath. It will only work to the extent that the organisations who (I think) want this stuff, get engaged.


Unix seems to me an excellent model for this. The fundamental design of unix hasnt changed since 1971. The core tenet of unix is written on wikipedia as: "The Unix philosophy emphasizes building simple, short, clear, modular, and extensible code that can be easily maintained and repurposed by developers other than its creators. The Unix philosophy favors composability as opposed to monolithic design."

This design I think can be very clearly extended into a "web" or "internet" substrate of microservices linked together through REST api calls. The ubiquity of the http standard, and perhaps webSockets as well have solid metaphors in the *nix universe.

What seems to be the core requirements for this flavour of *nix (if you will excuse the aforism), are that we can have some kind of mid-level of services which are composed of lower level services, and that provide a reasonably stable language targeted at certain sets of community requirements.

As the unix kernel and low level software can evolve, whilst leaving the interface to higher level software (e.g. Media Player running on top of the sound sub-system), so must miscroservices be able to evolve without breaking the ecosystem.

As the sub-systems evolve, they can offer "extra" potential behaviour to end-user products, without breaking backwards compatibility.

Add new comment

Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer