Microservices and the Blockchain

Building unique blockchain infrastructure

In the world of application development, microservices and containers are all the rage. Developers everywhere are working to break monolithic applications into smaller, more modular pieces by using microservice architectures coupled with technology like Docker containers.

At Po.et, we believe in the power of microservices. However, as we are building a decentralized application powered by the blockchain, we’ve learned that implementing microservice architecture into a decentralized application needs a special approach.

In many ways, what we’re doing is quite unique, and this speaks to the special challenges and opportunities that arise when you combine microservices with the blockchain.

Traditional Microservices

Microservices have become so popular in recent years for two main reasons:

• They are easier to scale. When one part of your application needs more capacity, you can increase the resources available to the microservice or microservices that power that part of the application. This is especially easy to do if you are deploying the app using containers. You can simply create more instances of the containers that host the microservices that you need to scale.
• They are a “black box.” From the outside, each microservice is a black box. Other microservices can send requests to it and receive information from it using a predefined protocol, such as an HTTP request or AMQP. They don’t need to worry about what is going on inside the microservices they are communicating with. This design strategy makes it easier for multiple microservices to interact seamlessly and simplifies application management.

The Original Plan For Po.et’s Microservice Architecture

When we began developing Po.et, our plan was to adopt a traditional microservice model.

Each Po.et node needs to run multiple services — ranging from a torrent service and Bitcoin scanner to a system for processing “claims,” which refer to information regarding ownership of digital content that is managed on the Po.et network.

Initially, we intended to implement the Po.et node application so that each of these services would run as a distinct microservice inside its own container. The containers would be managed using Docker Swarm.

The major goals of this approach were to make it easy for the services to scale independently and to simplify management using Swarm.

The Decentralization Dilemma

As the project developed, we realized that the Po.et node is different from most traditional applications in one key way: it is a decentralized app.

That is a big deal. Traditional microservice architectures are designed to support applications that are deployed and managed centrally. In most cases, a company or group of administrators hosts the app in a datacenter somewhere. The app might be “distributed” in the sense that it is hosted on a cluster of servers rather than a single one, but, even in that case, the server cluster is still centralized. One authority controls the application and is responsible for managing it. In this case, being able to deploy the app using containers and manage it with an orchestrator like Swarm is useful.

Po.et is fundamentally different. Po.et is a decentralized network of nodes, with each node more or less running like a desktop application rather than a cloud-based one. No single entity is responsible for managing the nodes or making sure the network can scale. Instead, the network manages itself and scales automatically as nodes are added or subtracted.

Centralized management through an orchestrator like Swarm is, therefore, unnecessary in Po.et’s case. In addition, breaking each node into traditional microservices isn’t advantageous from a management standpoint because the nodes are self-managed and self-contained. It’s important to ensure that each node instance is able to stand on its own, but having to deploy multiple microservices to start a single node would make it harder, not easier, for people to use Po.et.

The New Po.et Architecture

The new Po.et architecture.

Because of these considerations, we have migrated to a new application architecture. You might say it is microservice-inspired, even though it does not use microservices or containers in the conventional sense.

Instead, what we are doing is building Po.et as a set of distinct code modules but not separate services. Each module behaves in a fashion similar to a microservice. The modules have no knowledge of each other and communicate only via a message queue.

From a programming standpoint, modules are easier to manage. They also help to make Po.et nodes more efficient and secure.

However, this module-based architecture doesn’t require each node to run multiple microservices, so setup and management is simpler on a decentralized network.

Conclusion

Microservices are great, but decentralized apps have special challenges that traditional microservices cannot easily solve.

At Po.et, we’re applying the microservices concept to the development of our decentralized platform, but we’re doing something different from run-of-the-mill microservices.

We hope that our example will help lead the way for the development of other decentralized apps as the blockchain space matures and developers adapt to the new realities of programming for a decentralized world.

Join us on Telegram!: https://t.me/joinchat/GKMQ1kOQSdXVZpN1Rygcdw

Follow us on Twitter!: https://twitter.com/_poetproject

We’re hiring!: https://angel.co/po-et

Visit our Website!: https://po.et/

Check out our GitHub!: https://github.com/poetapp