Microservices for macro-impact

Breaking up the monolith

There is an irony in that to build something large and scalable, you need to build it using small and tight components. To use a material-world analogy — to build a big house, you don’t carve it from a single block of stone. Instead, you use small, self-contained bricks, of similar shape and size, and build the house layer by layer from these small components, each of which interfaces with a few other bricks.

Today we see far too many companies, even startups, still building monolithic applications that will have trouble scaling down the line. Some have started the (often painful) progression from using monolithic applications running on power-hungry servers, to building more modular applications that often are akin to haphazardly sellotaped rocks, planks and tiles. Instead of following down the same, clearly unsustainable path, we have chosen to use “software bricks” from the start, building blocks called microservices.

Microservices without micromanaging

A microservice is effectively a small program or application that has one key function, and it performs it well. One could say that it is a relatively new phenomenon, but in many ways it is a rediscovery of the Unix philosophy of Ken Thompson exported to our world of clouds and distributed computing, and embodies the ideas of the modern 12 factor app.

Typically, a microservice will run in a (Linux) Container, more often than not built and run using a platform called Docker, which enables packaging an application and its information into an image. Often, they are run with configuration options provided a posteriori (i.e. the same container is usable across development, test and production DevOps environments).

A microservice has one key function, and it performs it well

Whilst scalable, creating and deploying Docker images at scale is not a fun job if you do it manually, this is where container orchestration tools come in. At AID:Tech we use a framework called Kubernetes (a.k.a. K8S). K8S effectively builds and manages a computer cluster where a set of computers or virtual machines form the nodes. K8S then allows you to easily deploy containers to the cluster, manages their configuration and secrets, regulates access to and from each microservice and permissions.

Still, even K8S, used alone ends up requiring manual work in modifying the separate components of each microservice each time you deploy it elsewhere. To avoid this laborious and error-prone process, we use the K8S package manager — Helm. Helm allows you to build Charts that act as templates or packages encompassing all the components of a microservice, easily customisable by providing a small file describing how the microservice deviates from the default configuration. Critically, Helm also allows you to package cloud applications into Charts that you can easily distribute for others to easily deploy.

Charting the future at AID:Tech

At AID:Tech we have taken full advantage of the microservice architecture, quickly deploying complex applications in minutes. We have not only consumed Helm packages for apps like Jenkins, cert-manager, Grafana, Prometheus, NGINX, but have ourselves contributed and improved Charts like Kafka, Zookeeper, kubeless, etc.

Indeed, we have publicly released a set of Charts to help Hyperledger Fabric and Composer developers to easily deploy their networks on K8S.

Stay tuned!

Follow AID:Tech on Telegram: https://t.me/AIDTech