Heard a rumour that the ccs specs are published. Now that the nda has been silently (!) dropped there's no restriction to publish and discuss them here now is there? ;-) In how far an eventual evolution to a micro services architecture (http://martinfowler.com/articles/microservices.html) will be kept in mind?
I would be happy with a small brms included. Not an interface to that expensive and vast corticon, just a small one written in abl. Easy integration possibilities with an os solution like http://openl-tablets.org/documentation/apologia would be nice. Furthermore dynamic catalog generation for datasets with more than one table. I could use that for batchmode insert of orders f.e. (so not first save an order and afterwards save orderlines one by one). Mailed this link before with a demo: http://eurekaaddons.co.uk/products/web-so-for-sage-200/ nice eh?
Moreover I don't know wherefore an appserver would be needed in a microservices architecture.
moreover, i don't know where a microservices architecture would be needed. what is it for?
Internet is full of arguments, if you're interested just google. Moreover, I sent some links that already explained some things. Did you digest those?
Counter question: what is the appserver needed for, Gus? I just googled a bit after some simple logical thought, that lead to "what is this appserver good for anyway". You know me. I read in one of the first hits "app servers are fading away in the move from monolithic middleware to microservices and cloud services" (www.jamesward.com/.../). Moreover "appservers are dead" etc. That's of course bad practice, googling to get my good rights, I should look for the opposite. So I thought let's ask Gus. Be my enemy, please, my virtual friend. ;-) I'm not the smartest but I can google, lets say. :-)
I liked what I read in the nginx link, no wordiness there, here's one introducing microservices: https://www.nginx.com/blog/introduction-to-microservices/ .
Another quick google result, sorry to bother you with so much letters but I think some of them make sense: "Micro services on light weight containers like Docker or maybe Dropwizard or Spring Boot are the end of the application server that served us so well last decade." (http://blog.xebia.com/the-end-of-common-off-the-shelf-software/)
You want to hear it in my own words? See if I learned my lesson? :-)
The Microservices Architecture pattern has a number of important benefits. First, it tackles the problem of complexity. It decomposes what would otherwise be a monstrous monolithic application into a set of services. While the total amount of functionality is unchanged, the application has been broken up into manageable chunks or services. Each service has a well-defined boundary in the form of an RPC- or message-driven API. The Microservices Architecture pattern enforces a level of modularity that in practice is extremely difficult to achieve with a monolithic code base. Consequently, individual services are much faster to develop, and much easier to understand and maintain.
Second, this architecture enables each service to be developed independently by a team that is focused on that service. The developers are free to choose whatever technologies make sense, provided that the service honors the API contract. Of course, most organizations would want to avoid complete anarchy and limit technology options. However, this freedom means that developers are no longer obligated to use the possibly obsolete technologies that existed at the start of a new project. When writing a new service, they have the option of using current technology. Moreover, since services are relatively small it becomes feasible to rewrite an old service using current technology.
Third, the Microservices Architecture pattern enables each microservice to be deployed independently. Developers never need to coordinate the deployment of changes that are local to their service. These kinds of changes can be deployed as soon as they have been tested. The UI team can, for example, perform A|B testing and rapidly iterate on UI changes. The Microservices Architecture pattern makes continuous deployment possible.
Finally, the Microservices Architecture pattern enables each service to be scaled independently. You can deploy just the number of instances of each service that satisfy its capacity and availability constraints. Moreover, you can use the hardware that best matches a service’s resource requirements. For example, you can deploy a CPU-intensive image processing service on EC2 Compute Optimized instances and deploy an in-memory database service on EC2 Memory-optimized instances.
Now did I learn my lesson or not? :-)
From what I've read so far in those NGINX articles (Which isn't all of it, have to leave that as a new year's resolution...), it looks like the architectural changes in the Pacific AppServer for OpenEdge (11.6) take a few big steps towards enabling the micro-services pattern.
Every individual service can now be it's own self-contained ABL Web App, which can be distributed as needed/desired (see also: documentation.progress.com/.../index.html for the technical details on that).
And there's nothing that stops the code from one Web App to make requests to another.
How big or how small each service becomes is then left up to the developer.
I'd say that if you want to transition from a monolithic classic appserver towards microservices, you'll want to start by grouping together your different entry points by what functionality they provide, and then start splitting off those groups into their own service.
(In theory, you can do something similar with the classic appserver as well by using the often-overlooked AppserviceList functionality. But then you end up with a lot of extra work to avoid collisions between the different services running under the same brokers.)
Stefan, I think you are missing two things here. One of them is fine because it is just a aversion for some things and a passion for others ... but not always remembering the context. Some of the stuff you write about is perfectly interesting in and of itself, but not necessarily relevant in the context of building enterprise class business applications. Of course, sometimes it is relevant, but just new words for something that has actually been around for a long time. I readily agree that the ABL community needs to think about architecture a lot more than it does, but I think this should be grounded in where we are and what we have available now, what we can do with that, where we would like to go from here, and what we need to do that.
The local thing that you are missing is that the CCS effort explicitly excluded architecture from its mandate beyond defining interfaces for the components, which one has to do to have specified anything. I wish that were not the case since I think that improving the architecture of our legacy systems is one of our most important challenges, but it is the choice they made. So, really, there is no architecture here to argue about, only pieces. One can imagine how those pieces are likely to be used in real systems, but really, that is up to the person using them. So, really the only architectural criticism which is appropriate is to say that one would like to use a component in a particular way, but the current definition of that component presents an obstacle to that use.
Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice http://www.cintegrity.com
The world is flat and on the borders monsters live (aka the elephant in the standup). When will the soapbubble burst? Did it burst already?
Dreaming of bright newyear, best wishes!
> 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?)
I must confess that I don't know much of pas. If you are right the component specification group could have a look at microservices, if they did not evaluate that architecture already. Thanks beforehand for all those quick replies to the question in my first email then! :-(. Concerning the communication with the appserver agent I had a problem in the past (classic appserver), I could not contact idle sessions. Is this problem gone? The communcation was said to be impossible because of how the agent was built. Exerpts from community.progress.com/.../1674
"a) An AppServer agent is not running the ABL language engine when idle, it is waiting solely on (socket) communications from the AppServer broker
b) Running a remote AppServer procedure n-number of times in an attempt to cycle through all the 'idle' agents will almost certainly not produce consistent results"
"With regards to 'idle', an AppServer agent works very differently from an ABL client or WebSpeed agent. An AppServer agent is not actively running any ABL procedure when in an idle state; it is actually sitting in an 'C' code idle loop outside of the ABL language interpreter. So no, the agent is not idling in a 'wait-for' where it can be interrupted, timeout, or handle asynchronous [i/o] operations. The agent re-enters the language engine when a client's remote procedure request arrives, exists the language interpreter when the remote procedure has completed, and then waits in its idle loop until the next remote procedure or broker operation is received."
>> 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.
Maybe we are making things more complicated than they need to be. Why not just run one AppServer for each "microservice", and let them connect to and call each other using remote RUN in ABL?
After all an AppServer is just an AVM ready to receive calls from other processes. And they can be located on the same machine or other machines on the network; it doesn't matter. The calls don't necessarily have to go through HTTP, unless you really need that. And you can run as many instances of each one as you need. And each one can have its own database, if that is what you want for a microservice. Each one can be started, stopped, deployed, updated and so on whenever you want, separate from each others.
Just resist the urge to put your whole application in the same AppServer, that's all...
>>> First things missing that catched my eye are realtime messaging possibilities between f.e. appserver exe processes
> I commented:
>> I'm not sure why that would be so hard to implement using ABL. There are various ways to communicate i ABL.
You commented that, but I have had a problem in the past with idle appserver agents (classical appserver). See prev. email with comments from Michael Jacobs (psc).
> Why not just run one AppServer for each "microservice", and let them connect to and call each other using remote
> RUN in ABL?
Beforehand you should take into account that the services might be replaced with non-abl services. You would want a communication protocol that is (as much as possible) language agnostic, and performs well. It could be that your call is an event that has listeners subscribed. Etc, see the nginx link. This has been thought over by others already of course.
> but I have had a problem in the past with idle appserver agents
I don't understand how that would be a general problem for microservices?
> I don't understand how that would be a general problem for microservices?
I was talking about a communication problem between two abl sessions that existed with the classic appserver.
"Micro services on light weight containers like Docker or maybe Dropwizard or Spring Boot are the end of the application server that served us so well last decade. If you can scale your application by starting a new process on a fresh VM you don’t need complex software to share resources. That means you don’t really need a lot of infrastructure. You can deploy small components with negligible overhead. Key-value data stores allow you to relax constraints on data that where imposed by relational databases. A service might support two versions of an interface at the same time."