Tau Alpha, Microservices Architecture, and Internet of Languages

In the most recent Q & A we got an update from the development team. The update this month was quite meaningful and for those who haven't seen it yet, I suggest you look at it here:

I'll be discussing in my blog some of the technical details of what they discussed in the video and giving my interpretations of what is being developed.

The Microservices Architecture and Tau Alpha

The Broker in a microservices architecture makes sense to anyone who is familiar with RabbitMQ or ZeroMQ. ZeroMQ will likely not be the messaging technology used in the alpha. The alpha is more likely to be using a custom messaging technology developed by AK (Andrei). In my own interaction with Andrei and from studying his decision making process I would say he is extremely competent as a programmer and as a designer. For example if we look at Github we can see that with every decision he is making in his design he is weighing the costs against the benefits.

For example in the skeleton or sketch code base on Github we can see even from that a lot of strategic decisions. These decisions of course can be changed but from the current code we can see he chose Boost which is a library which enables advanced P2P functionality. Boost is actually such a good library that Dan Larimer favored using Boost for Bitshares and Graphene. When I saw he was going with Boost immediately I knew that if he uses that library it makes handling security issues and auditing easier because it's a well known library, it makes maintaining the code easier because a lot of people are familiar with boost, and it's also easy to read which means we can look at it and clearly see what is going on.

The state machine can be written in TML. What does this mean? Theoretically TML is supposed to be able to translate one language to another without losing meaning. By languages I refer to formal languages which are languages which can be expressed in the way that machines can handle and process. The interesting thing here is that in the context of an Internet of languages if we have a microservices architecture it could make adding additional languages a rather simplified process. The central broker is supposed to be inside the client, which indicates at least in the beginning we will have a client server model. At this point I don't really know what impact this will have but I would say it's probably easier to read the code.

The Microservices Architecture needs to be explained in more detail

In the first half of this blog I explained more how Tau could use microservices and I used concepts like messaging. Not everyone knows what ZeroMQ or any of this stuff is. So I will now explain a bit about that part. ZeroMQ is an asynchronous messaging library. These sorts of messaging libraries work in a particular way and here are some concepts to list and understand:

• State machine. This is the internal state and to understand a state machine think about a Rubik's Cube. In mathematics we would describe the possible states or positions the patterns on the Rubik's cube can take as being combinatorics. There is some finite amount of possible states in a finite state machine and so when we see the current state of a state machine it is the current position or pattern out of the many possibilities which can emerge. The machine exists in a particular state at a particular time and this is sequential in order from first to last, so the first state is the state the machine starts in, and in the consecutive or next states the machine accepts a set of named "events". Given an event, the machine executes a list of actions which correspond to your code. So the machine simply goes from one state to the next, executing according to your code and based on the events accepted. This concept is not going to be an easy one to understand so if you want more detail look here.
• Broker. The Broker in this context is the messaging mechanism which handles the routing. You can learn more about that here. What is the importance of this? This is like the central data hub which forwards requests and responses.
• Microservice. This is a component in the microservices architecture which isn't an app, but a component or piece of what can make up an app. Using this you can have a modular design and an ability to update any piece of any app independently.

To understand the microservices architecture as a whole and to grasp the messaging component it helps to think about the design patterns.

• Synchronous Request/Response
• Asynchronous Request/Response
• Publish/Subscribe
• Push/Pull
• Exclusive Pair
  Reference: https://blog.scottlogic.com/2015/03/20/ZeroMQ-Quick-Intro.html

Synchronous or asynchronous refers to the pattern. For those familiar with packets you can recall how with UDP you have an asynchronous communication pattern. TCPIP is a synchronous communication pattern. To put it in more plain language, you need a sort of timing to stay in synch while with the asynchronous pattern you have emergent patterns which can appear random. Since we cannot predict when someone or something will be online it is asynchronous but if you want it to always be in sync then you have to be on the same clock. For decentralized networks and for certain kinds of processes you simply cannot be on the same clock so for this reason we have to distinguish between these two patterns.

Note: For those familiar with C/C++ and who know Linux/Unix you may be familiar with the concept of sockets. This concept in programming can dramatically help and is very much connected to what is going on here. Request and Response are what used to be called "socket programming". This kind of programming was heavily used by hackers in the late 90s to do certain things with packets which I will not go into detail but for those who know what I'm referring to you will be able to grasp these concepts. The sockets are like a two way road where information can be sent in both directions.

Request socket can be put into context if we imagine for a moment that the client can send a Request by opening up a communication channel with the server. It can then upload the command. We can see from the image below what this looks like:

Request-Reply by iMatix Corporation is licensed under cc-by-sa 3.0

In the Hello World example we can now see what a Request socket looks like. We also can see in that visualization what a Response socket looks like. We can see that the client can send a command to the server and receive a response. In other words an input it sent from the client and an output is produced as requested and given as a response by the server.

And what if you want to do the same thing in an asynchronous manner?

Extended Request-Reply by iMatix Corporation is licensed under cc-by-sa 3.0

As you can see from the visual, any number of clients can request from any number of brokers. This in my opinion is where it becomes a peer to peer thing. The Broker which Andrei (AK) was talking about is the central component in that image which routes all the messages between clients and servers. It handles the requests, it handles taking commands and delivering responses. So based on this understanding what does it mean that the broker is going to be inside the client? It could mean that scaling takes place on the client side? It could mean something for security as well.

Now to understand Publish and Subscribe is to think about data streams. This is to say that maybe for example on Tau Alpha you will want to Publish or Subscribe to a data stream. Publish lets you output to any number of possible clients. Subscribe lets any number of possible clients stay connected to your outputs. The useful visual:

Publish-Subscribe by iMatix Corporation is licensed under cc-by-sa 3.0

Push/Pull are familiar to programmers and this sort of thing is useful for times where you want to do global updates in a uniform manner across all clients or all servers for example. This is heavily synchronized activity in the sense that they all share the same state.

Exclusive Pair I will not go into because I don't see how it is immediately relevant to Tau Alpha.

Conclusion

If we can assume Tau Alpha will have a custom message broker then we can think that the kind of messaging that will be going on will likely be in the context of TML/Alpha related concepts. So we know for example there will be a TML where languages can be translated between one another then perhaps we will be able to subscribe to discussions. These discussions perhaps will be translated into many different formal languages. At first our discussions will likely be in the not so attractive looking TML syntax but over time we will be able to use the microservices architecture to add new lang to lang translations so that we can eventually have our discussions in something close to natural language (near English) and turn that into any of the programming languages available in a completely automatic process. That in my opinion is what the Tau Alpha is likely to look like and if it goes well most of us will be able to code in near English.