jakiro
Author: ArweaveOasis, Source: PermaDAO
This article discusses the advantages of adopting a microservice architecture (or Actor model) and analyzes the logical complexity it brings to application development.
The release of @aoTheComputer has undoubtedly brought a new kind of thinking and practice to the entire @ArweaveEco ecosystem and even the entire Web3 industry.This is not only reflected in the attention of the majority of investors, but also in attracting a large number of high-quality developers to start in-depth research.
What hinders the massive adoption of Web3?
It’s very simple, because there are too few decentralized applications worth using.
Based on the current situation of Web3 infrastructure, development tools, software engineering practices, etc., many types of decentralized applications are almost impossible to achieve at present.
In terms of infrastructure, I think the emergence of AO fills some of the major gaps.However, the complexity of the project to build large-scale decentralized applications is still daunting.This makes it impossible for us to develop more diverse, larger, and often better, more functional decentralization when resources are constrained—usually in the initial stages of things’ development—to develop more diverse, larger, and more functional.application.
Don’t believe in those nonsense words like “Smart contracts/on-chain programs should be very simple, there is no need to make them too complicated”!
The real problem is not “not wanting”, but “not” – I can’t do it.
AO is a computer system running on Arweave, designed to achieve verifiable unlimited computing power.It is the short name for Actor Oriented.As the name suggests, this means that decentralized applications running on AO require design and programming methods based on the Actor model.
In fact, AO was not the first to use the Actor model for blockchain (or “decentralized infrastructure”).For example, TON’s smart contract is built using the Actor model.Speaking of TON, I personally think it has similarities with AO in some ways.
For Web2 developers who have not yet had a deep understanding of Web3, if you want to quickly understand the biggest feature of AO or TON compared to other “monolithic blockchains”, a convenient way to get the smart contracts running on them (chain)(Part 1) is regarded as a “microservice”.AO or TON is the infrastructure that supports the operation of these microservices, such as Kafka, Kubernetes, etc.
As a senior CRUD boy who has focused on application development for more than 20 years, I personally am very happy to see the emergence of non-monopoly blockchains such as AO and TON, and are full of expectations for their development.Below I would like to talk about my views on AO from the perspective of an application developer. Many of the views may not be very mature.Perhaps some application developers will feel resentful, that’s enough.
Is it really necessary to apply the Actor model to blockchain?
The answer is yes.Look at the Web2 applications that have achieved “massive adoption” and you’ll see.
Too many architects already know how to “make big” Web2 applications: microservice architecture (MSA), event-driven architecture (EDA), message communication mechanism, final consistency model, sharding… no matter what they are called, always coexist with the Actor model.Some of these concepts can even be said to be just different aspects of a thing.So in the following text, we do not distinguish between “microservices” and Actor, you can think of them as synonyms.
The prosperity of the Internet today is inseparable from the wisdom of these architects.They constantly explore, practice and summarize, and finally formed a complete engineering practice system.
As a Web3 infrastructure, AO does a great job.At least, AO has shown great potential as the best decentralized messaging broker in the current Web3 field (in my eyes).I believe that developers of traditional Web2 applications can immediately understand the significance of this: if Kafka or Kafka-like message broker is not available, can you imagine how many large Internet applications now have “how to write programs”?
Although the Actor model has theoretical advantages in many aspects, whether it is the Actor model or the microservice architecture, in my opinion, it is more of a problem that developers have to develop certain applications (especially large applications) in order to develop certain applications (especially large applications).The “pain” to bear.
Let’s use a simple example to illustrate this to non-technical readers.Suppose all banks in the world conduct business based on a “world computer”, and this world computer is a monolithic system.Then, when the ICBC customer “Zhang San” remits 100 yuan to “Li Si” who opens an account at China Merchants Bank, the developer can write the code for the transfer program like this:
1. Start a transaction (or “transactions”, which are the same word in English);
2. Deduct 100 yuan from Zhang San’s account;
3. Add 100 yuan to Li Si’s account;
4. Submit transactions.
No matter which step there is a problem with the above steps, for example, the third step, which increases the amount on Li Si’s account. If it fails for some reason, the entire operation will be rolled back, just as nothing has happened.By the way, when writing programs like this, we call using the “strong consistency” model.
What if computers in this world are systems that adopt microservice architecture (MSA)?
Then, the microservice (or Actor) that manages the ICBC account is almost unlikely to be the same as the microservice that manages the China Merchants Bank account.Let’s first assume that they are indeed not the same. We call the former Actor ICBC and the latter Actor CMB.At this time, the developer may need to write the transfer code like this:
1. Actor ICBC first records the following information: “Zhang San transfers 100 yuan to Li Si”; Actor ICBC deducts 100 yuan from Zhang San’s account and sends a message to Actor CMB: “Zhang San transfers 100 yuan to Li Si.Yuan”;
2. Actor CMB received a message, adding 100 yuan to Li Si’s account, and then sent a message to Actor ICBC, “Li Si has received 100 yuan transferred by Zhang San”;
3. Actor ICBC received the message and recorded it: “Zhang San transferred 100 yuan to Li Si, and it has been successful.”
The above is just a process of “everything is OK”.But what if a certain step, such as the second step, “add 100 yuan to Li Si’s account”, and there is a problem?
Developers need to write such processing logic for this possible problem:
-
Actor CMB sent a message to Actor ICBC: “Zhang San transferred 100 yuan to Li Si, but the processing failed.”
-
Actor ICBC received a message that it added 100 yuan to Zhang San’s account and recorded: “Zhang San transferred 100 yuan to Li Si, but it has failed.”
This is how the program is written, we call it the final consistency model.
As mentioned above, non-technical readers should be able to intuitively feel the huge difference in workload between the application of developing monolithic architecture and the application of developing MSA, right?You should know that the transfer example mentioned above is just a very simple application, if we call it an application, not a function.The functions in large applications are often much more complicated than such examples.
How big should this microservice be?
In other words, “Is this microservice too big and should be divided into two?”
Unfortunately, there is no standard answer to this question, it is an art.The smaller the microservices, the easier it is to optimize the system by creating new instances and moving them on demand.However, the smaller the microservice, the harder it is for developers to implement complex processes, as shown above.
By the way, split an application into multiple microservices, from the perspective of database design, it is the so-called “sharding”.One of the best practices for microservice architecture is that each microservice uses only one local database of its own.Simply put, sharding allows horizontal expansion.When the dataset becomes too large to be processed in the traditional way, there is nothing else (to scale it up) except splitting them into smaller fragments.
Go back to the splitting issue of microservices.In order to better practice this art, we need to master the use of some thinking tools.The “Aggregate” of DDD (domain-driven design) is such a “big killer” you must have.I mean, it helps you destroy the “core complexity” in software design.
I think aggregation is the most important concept of DDD at the tactical level.
What is aggregation?Aggregation draws a boundary between objects, especially entities.An aggregate must contain and only one aggregate root entity, and may contain an uncertain number of aggregate internal entities (or non-aggregated root entities).
We can use the concept of aggregation to analyze and model the fields that the application serves; and then when encoding, we can divide microservices according to aggregation.The easiest way is to implement each aggregation into a microservice.
However, no matter how skilled you are, you cannot guarantee that you will do the right thing the first time.At this time, a tool that allows you to verify the modeling results as soon as possible and if it doesn’t work, it will be precious to you.
What else could constitute a barrier to migration of large Web2 applications to the AO ecosystem?
I want to talk about language and program runtime issues.
AO is a data protocol.You can think of it as a set of interface specifications that define how each “unit” in an AO network implements collaboration.Currently, the official implementation of AO includes a WASM-based virtual machine environment and a Lua runtime environment (ao-lib) compiled into WASM, aiming to simplify the development of AO processes.
Lua is a small and beautiful language.Lua is generally believed to have the advantage of its lightweight and easy embedding into other languages, which makes it particularly useful in specific scenarios, such as game development.However, the Lua language is not the mainstream choice for developing large Internet applications.Large-scale Internet application development often tends to use languages such as Java, C#, PHP, Python, JavaScript, Ruby, etc., because these languages provide a more comprehensive ecosystem and toolchain, as well as a broader community support.
Some people may argue that these languages can be compiled into WASM bytecode and run in a WASM virtual machine.But in fact, although WASM has performed strongly in the field of web front-end development, the current use of WASM as the back-end operating environment for Internet applications is not a mainstream choice.Note that smart contracts (on-chain programs) are the “new backend” of the Web3 era.
Summarize
In summary, we have discussed the advantages of adopting a microservice architecture (or the Actor model) and the complexity it brings to application development.Some complexities are inevitable.For example, even in more mature engineering Web2 environments, achieving “final consistency” based on message communication is already a great challenge for many developers.The challenge seems to be even more obvious when developing Dapps on the freshman AO platform – of course it is completely understandable.An example is shown at the beginning of the following link article.
https://github.com/dddappp/A-AO-Demo?tab=readme-ov-file#an-ao-dapp-development-demo-with-a-low-code-approach
We all know that the battle between public chains is actually a war for application developers.So, how can AO win developers in this case?
I think there is a need to continue learning from Web2 that has already received “massive adoption”.This includes not only learning its infrastructure, but also all aspects such as development methodology, development tools and software engineering practices.In the next article, I will show you one of the solutions I firmly believe in: low-code development.
