I’m Andrew Levine, the CEO of Koinos Group, and below you will find our second episode of the Koinos Group podcast in which I’ll be exploring microservice architectures. We’ll be using this podcast to explore a wide range of topics because as a decentralized app platform with free transfers, free accounts, and free smart contracts, we expect the Koinos blockchain to touch every corner of the technology space. We’ll be using this podcast to share information about the project, interview members of the team, interview people from other projects, or just talk directly to you like I’ll be doing in today’s episode.
Up until a few months ago I’d barely even heard about microservices, but now I‘m convinced they’re a super important, and actually super cool, technology. So what are microservices? Why did they come about? And how could they help take blockchain technology to the next level?
The reason why we’re interested in educating people on microservice architectures is because Koinos, the blockchain we’re developing, will be one of the first, if not the very first, blockchain built on such an architecture. But we didn’t choose this architecture simply to set a precedent. We chose it based on the experience we gained working on the Steem blockchain, where the lack of such an architecture caused us countless headaches. But thanks to its microservice architecture Koinos will be more stable, more updgradable, and individual nodes will be more scalable (which shouldn’t be confused with scalability of the blockchain).
You might be thinking, “If microservices are so great, then why have no other blockchains taken advantage of them?” Microservice architectures are actually very young and they were emerging at the same time as blockchain technology (Bitcoin, Ethereum, Bitshares/Graphene). At that time the standard approach to developing software was what we now call “monolithic” architectures.
Brian Foot and Joseph Yoder explained monolithic architectures beautifully in their paper, “Big Ball of Mud,” published in 1999.
While much attention has been focused on high-level software architectural patterns, what is, in effect, the de-facto standard software architecture is seldom discussed. This paper examines this most frequently deployed of software architectures: the BIG BALL OF MUD. A BIG BALL OF MUD is a casually, even haphazardly, structured system. Its organization, if one can call it that, is dictated more by expediency than design. Yet, its enduring popularity cannot merely be indicative of a general disregard for architecture.
Their point was that despite the obvious downsides, monolithic architectures remained the dominant paradigm, that is until the development of the microservice architecture. In monolithic systems all of the complexity of the different subsystems is exposed and interconnected like a giant bowl of spaghetti. When one thing breaks it causes many other things to break which makes both finding and fixing the source of the breakage more difficult.
With a microservice architecture, all of the sub-systems are walled off with deliberate bridges erected between processes to isolate faults and make it far easier to find the source of a breakage. Once the source of a bug is found, the simplicity and containment of the microservice makes it fast and easy to patch the bug and restore functionality. This also makes maintaining and upgrading sub-systems easier because smaller teams, and even individual team members, are capable of working on a single microservice.
In Steem this meant that everything had to be written in C++ and changing any subsystem (Steem used plugins) would almost always require a reindex (which is a kind of system reboot). Plugins are an example of a modular monolithic architecture, which has some of the benefits of a microservice architecture, but as these examples demonstrate, many of the downsides of a monolithic architecture.
At the same time that people were rethinking low-level software architectures, blockchain technology was emerging. One of the big ideas behind Bitcoin (and the platforms that came after it) was that users would be both engaging in peer-to-peer financial transactions and providing the infrastructure needed to enable such transactions by running the blockchain software on their own computer.
These would be alternative financial systems without a middleman, not just another type of digital payment that would reinforce the established financial institutions. With that objective in mind, blockchain software was architected for the purpose of enabling users to download and run a single, easy-to-use program, that would enable them to both use and support the network.
The best way to accomplish that objective, and a number of others, was by providing the user with a single executable, for example, a .exe if you use Windows. That single executable would enable them to install and run the blockchain software quickly and simply. In addition to the blockchain database, that single executable would handle things like consensus, storage of blocks and transactions, p2p communication, and indexing. These processes aren’t technically required to have a blockchain--they aren’t “part” of the blockchain--but they are extremely important for having a useful decentralized network so it made perfect sense to write them all together, in the same programming language, so that they could be compiled into a single executable.
As blockchains were continuing to be developed along these traditional lines, and for perfectly good reasons, microservice architectures were continuing to evolve and mature. The problem with such architectures is that they involve creating a large number of very small services, which are best maintained in a decentralized manner by empowering individual teams to make decisions based on their own needs. This way fixes and improvements can be made quickly. The problem is that you have to monitor all of these systems and how they are all interacting with one another. Why would you take on all of this additional work?
There’s one primary benefit that has fueled the explosive adoption of this technology and it’s a term you hear a lot when discussing blockchains, though in a different context; scaling. Generally when people are talking about scaling in the blockchain context they are referring to sharding which is a way of reducing the size of a node by breaking up the blockchain database contained within it into smaller pieces which can be held on different computers. But microservice architectures enable a different kind of scaling; scaling within the nodes themselves.
Within microservice architectures, individual services can be scaled up without having to scale up the entire system, and this can dramatically reduce the cost of running a network while improving both the speed and quality of improvements to that network.
With a monolithic architecture when usage of your node increases, you increase the size of the node to meet that demand, or launch an additional node. This would be like scaling up every single microservice equally, even though only one or two might actually be in high demand. That can get expensive fast, but with a microservice architecture, node operators can scale up individual microservices within a given node to respond with precision to the increased load. Not only that, but they can scale up different microservices in different nodes! This might not sound like a big deal, but we guarantee that developers will be extremely grateful when they see how much they are able to decrease their infrastructure bills!
While the costs of implementing a microservice architecture are significant, other technologies that emerged alongside microservices like cloud computing and containerization have minimized those costs, making the benefits finally accessible to blockchain developers like us and in the blockchain context there are even more reasons to leverage a microservice architecture. But those reasons aren’t necessarily obvious unless you’ve spent years scaling decentralized applications with thousands of daily active users as we have.
Because our microservices are separated out from the blockchain (which is written in C++ for performance and efficiency), individual microservices can be written in practically any programming language and then modified or even wholly replaced without requiring a reindex (which as I said before is a kind of system reboot).
Since we can now use any programming language we want, we chose to implement the initial microservices in Go because it’s specifically designed to have high-performance and easy to use networking and concurrency which makes it an ideal language for writing microservices. On Koinos, microservices will talk to each other using types defined in Koinos-Types, allowing Go and C++ to easily communicate with one another. But support for even more languages can, and will, be added so developers will be able to build Koinos microservices in the programming languages they already know and love.
Our use of Go for microservices is just one example of why it is so valuable to have multiple language support on Koinos, not just for the microservices, but for the smart contracts as well. Different programming languages are better suited to different tasks. Multi-language support doesn’t just make the platform more accessible to a larger number of developers, it gives those developers more freedom to choose the right tool for the job so that their application can be more efficient, more secure, and more scalable.
The microservice architecture itself creates amazing new opportunities for developers who will be able to build application specific microservices for Koinos that will help them run their nodes, and their applications, more efficiently and as a consequence deliver better user experiences.
Best of all, this will make Koinos node operation more accessible, thereby improving decentralization, and enabling the network as a whole to run more efficiently so that developers and their end-users can get more out of their decentralized applications.
But what about that user or developer who wants to run Koinos on their own computer? Does adopting a microservice architecture rule out this possibility? Absolutely not! In fact, thanks to resource management solutions built into the Koinos blockchain framework, running a high performance blockchain node on an ordinary computer will be possible arguably for the very first time!
We can absolutely provide an easy way for users to run Koinos whether it’s through a Python script or a Docker container. We plan to have some solution that creates and manages all the microservice components with sane default settings geared for a single-machine environment. But once an application has success, the developers infrastructure needs will outgrow that of a single computer, and that’s precisely when they’ll want that ability to dive under the hood and start managing the different components separately because that’s where much of their cost savings will be. As you’ll hear us say many times, we are developer obsessed, and this is just one example of how that obsession influences our products.
Alright, I think that’s a pretty good overview of microservice architectures. I really think this technology is going to be increasingly important as time goes on and I think you can get a glimpse of that potential when you see how we’re leveraging it in Koinos to help deliver a more advanced decentralized network than anything else out there.
If you’d like to learn more about Koinos, head on over to koinos.io and if you found this content interesting or informative, please follow and share. Thanks for your time!
Twitter
Facebook
LinkedIn
Hive
Discord
Telegram
