Golem + Microservices = ❤️ …(Part 1)

Microservices are all the rage right now, with investors so abuzz that there have even been venture capital-sponsored summits on the topic. But what exactly is a microservice? The good folks at Microsoft Azure helpfully chart it out like so:

As you can see, the microservices model breaks the components of an application down into discrete services. This is considered by some as the next great leap in software development, largely because it removes code from projects, placing reliance instead on more generic inputs and outputs. This may sound on the surface somewhat similar to RubyGems or similar code package managers, but the difference is that these microservice “gems” are hosted live over the network.

How does this relate to Golem’s decentralized compute network? Well, with one additional service layer in place, microservice containers can be advertised to the world at large, and put to use in applications — even the applications we write today.

HYPERBRICK

Let’s imagine for a moment, a prototype network of microservices with a highly simplified API, built on top of Golem. Let’s call it “Hyperbrick”. In the Hyperbrick universe, each microservice we’ll call a “module”. These modules can be combined into workflows where, for example, one module receives an input of yesterday’s sales data, compiles a visually compelling graph as an image, and outputs it. We can then store this image with, say, an S3 module, or perhaps we connect the previous output, with the input of an email module, to send yesterday’s results back to everybody in sales.

Every module should include a server component which translates the Hyperbrick protocol into UNIX standards, feeding the data to a process encapsulated in a Docker container. Hyperbrick modules would thusly able to be built by any developer, and published on the Hyperbrick portal, for both public and private use.

Building a Hyperbrick module would be as simple as wrapping any UNIX-based software into a Docker image, and then adding Hyperbrick’s simple server component. Once the Docker container was running, it would register as a module, connect to the Hyperbrick network, and listen for any incoming jobs. It might also be called directly, responding synchronously to any incoming request. Needless to say, the maintainers of Hyperbrick modules would of course be paid microtransaction fees for their ongoing efforts, giving a new revenue possibility to builders of great open source software (and not only).

Again, Hyperbrick is a theoretical application of Golem, but as you can see, with its vast pool of computational resources, Golem’s native Docker support would take care of execution, and the Hyperbrick layer would take care of the rest.

In closing, let us state our belief that microservices and decentralized compute are a one-two punch that will enable more and more decentralized applications to spring to life, without requiring any major changes to existing development habits. Something like Hyperbrick would wrap all the comfortable, familiar tools developers already use, and deploy them across Golem’s truly decentralized compute grid. We believe this will lead in time, to far more reliable applications written far more easily, with greater uptime and resilience, by default. We look forward to a future of entrepreneurial innovations such as Hyperbrick being built on top of Golem.