S
ske
Guest
> First things missing that catched my eye are realtime messaging possibilities between f.e. appserver exe processes I'm not sure why that would be so hard to implement using ABL. There are various ways to communicate i ABL. Many of the links you provided talk about keeping the communication simple, and just use any means available. However, I'm no expert on what would be most efficient or easy to do in ABL (if anything), so it would be interesting to see others make suggestions. (Someone mentioned PacificAppserver? But I would think other solutions for internal communication might be possible too.) And I guess, providing some new bult-in mechanism in ABL specificially designed for even easier communication between processes could be a good idea for improvement. I guess that until now, using many separate ABL processes has not been so common, but being able (and encouraged) to do that more easily could open up new possibilities. > Moreover I don't know wherefore an appserver would be needed in a microservices architecture. One link you provided that differs somewhat from the others in an interesting way is the one to "Elixir", based on the Erlang Virtual Machine. Most of the other links talk about each microservice being run as a separate operating system process. In Elixir, they in stead have their own concept of a "process" being a lightweight thread being handled with the Erlang VM, with many may such threads probably within the same Erlang VM within one operating system process. (Although certainly there are mechanism for distributing the execution between different VMs and different machines too.) Also the programming model of Erlang itself is based on such small threads communicating internally within every single program, and probably also within each microservice, not just between microservices. Several of the links you provided, which talk about microservices as separate processes, mentioned that it would be useful to have tooling for monitoring and controlling all the microservices, because otherwise you will soon have a big unmanagable mess of microservices with no control. Most of them seemed to rely on each microservice implementing their own monitoring, and how they are controlled wasn't really discussed much at all. Some mention using Docker, but I would guess that is only part of the solution. It seems to me, this part of using microservices may perhaps still be evolving, and hasn't settled. (Or maybe that is discussed somewhere else?) Anyway, it would seem that it would be useful to have a framework for managing microservices, if you are going to be running a large system with many microservces. And it would be useful not having to reinvent such a framework every time you need it. In Elixir, apparently they already have a tool, apparently named "iex", for watching and analyzing and keeping track of all their fine-grained threads, simplifying this work (or at least parts of it). Maybe something like the AppServer (or broker or something) could also evolve into providing support for this? Helping to keep track of separate microservices, in whatever way they are incarnated. Also, as you see from Elixir, all microservice implementations might perhaps not need to revolve around using separate processes, although I do notice some advantages of having separate processes, as mentioned in your links. The essential part seems to be the ability to deploy, run and update each microservice separatly and independantly and easily, whether run as a separate process or as a separate thread as in Elixir, or some other way. (Maybe it would be possible for AppServer and other technologies to evolve to become better at that, as a start? I'm not sure exactly what could be done, but maybe others know more?) - Going back again to the question of communication between microservices, I also noticed some similarity between some suggestions for message passing mechanisms and the the ABL PUBLISH/SUBSCRIBE mechanism for sending and receiving events. Many of your links of course mention sending messages between microservices using HTTP, JSON, XML, and so on. But these are just mechanisms and message formats. Clearly, the only relevant thing is having some practical mechanism for getting the messages across and finding the right recipient. Various open source low-overhead message passing packages were mentioned too, when communicating with internal services within the same enterprise and not external third-party services. And one basic useful model mentioned was to be able to just publish messages about events that are happening, and having other interested microservices subscribing to the events they are interested to process. This makes it very extensible for adding more services for the same events. This sounds to me very much like PUBLISH/SUBSCRIBE in ABL, except that if microservices are run as separate processes, it would be nice to have this extended to work also between different processes. But if some microservices would be executed with in the same AVM process, like threads in the same VM in Elixir, then perhaps this could be used already to start designing programs in a more microservices-like manner. (Anyone else want to elaborate on this possibility?)
Continue reading...
Continue reading...