Managed Objects

[SymbolicFrank]

Why don't micro-services fix the problem? Overhead and shared state.

While you could theoretically turn each function into a micro-service, it would be like passing your parameters through a REST API. Not very efficient. And a computer doesn't have an unlimited amount of sockets. There's a hard cap of about 50,000. Which sounds like a lot, but if you need 100 to handle a request, you can service 500 clients.

So, what you do is share state between those micro-services. It starts with the credentials of the user. The rights she has. And it's probably easiest to store the results of the other requests there as well. And of course you're not going to pass parameters through REST at the back-end. And we're back where we started.

In general, micro-services aren't all that different from an old-fashioned back-end. They just chop up the transactions in single AJAX calls, which all get their own socket. And you probably chop up the session variable into multiple blocks while doing so.

[Warfley]

If you are serious about high performance networking at scale, you use software defined networking stacks, where you access the NIC directly from userspace, instead of OS level sockets. There are a lot of libraries out there mimicking the socket API but without all those restrictions and much faster. There you don't have the limitation with 50k sockets but can have as much as the memory in your system allows. That said port numbers are restricted to 65k, so you may need additional disambiguation, but nothing impossible, and already widely used for very high demanding Network Services.

That said, Microservices don't solve the state problem, they are simply stateless. And this isn't really new, LISP already was a stateless language in the 50s, and there were some attempts to leverage lisps homoiconicity to implement distributed computation models, as at any point the whole program state can be represented as a lisp program, all operations are just transforming one lisp program to another, therefore all subexpression s can be split up, evaluated independently and concatenated back together.
The most interesting use case probably was some work for implementation in Browsers, where the lisp program would be transparently split up in server and client subexpression s that are evaluated independently and then rejoined to build a full web app. Note that this was around the same time JavaScript was developed, where the word Microservice did not yet exist.

Similarly functional languages often have similar properties through pure functions which have been heavily used to write parallel programs. Erlang was completely built around this concepts, where your functions are basically their own processes that can only communicate through well defined parallelity safe channels. Today go picked this idea back up with their go routines.
Note that this is pretty much the exact same thing as "Microservices" are today, but because the earliest versions of this came from the 70s (ML) and Erlang became big in that area in the 90s, it wasn't called a Microservice back then.

Microservices are just distributrd computation with a new fancy name to sell it to management. Nothing about that ia new, it's just recycled ideas from the past 70years.

[SymbolicFrank]

That said, Microservices don't solve the state problem, they are simply stateless.

Yes, just like HTTP. Which is fine if each request stands on itself. As soon as it is specific to a person, or the previous request, you have to store the state somewhere. The idea is that you do that in cookies. Which is the same idea as that session variable, but front-end.

Anyway, it doesn't matter if it is a cookie, record, class or combination thereof, it's still a managed object where the state is stored. And if you don't want that, you're back to passing everything as parameters. That's no different to any other computation model.

The Cell processor (PS/3) did that in an interesting way: use DMA to copy the data and parameters needed to a CPU core, have it process everything in local memory and use DMA to transfer the results back. At that point, you have to decide if you dedicate a core for that specific calculation, so you don't have to DMA the state every time, just the parameters. Earlier PlayStation processors used the same model (more or less).

Even in a high performance multitasking architecture, you either handle requests as a serial process, or you copy the data around. Because shared data only works if there is only one process that can access it at any one time.

[Warfley]

Cookies etc are basically nothing other than "hidden" parameters to a function. Also OOP methods of the form

Code: Pascal  [Select][+][-]

1. procedure TTest.Foo;
2. // Can be formalized to
3. function Foo(test: TTest): TTest;
4. // Where
5. test.foo;
6. // Basically is
7. test := Foo(test);
8.  

There is just one big difference, when you use global shared state such as global variables or OOP class state, you may share your state with others, while if you have "hidden parameter" hared state such as cookies, they are solely the in and output of a function. When I make two requests simulationiously then each gets a unique copy of the cookies, so they can't influence each other. This is the same principle behind most functional language type systems like in Haskell or Erlang or as the write borrow restrictions in Rust.
In the classical OOP, two references to the same class instance or using a global variable will share the state.

Therefore stateless does not mean no state, but no shared state. This is especially useful for parallel tasks, which is why it is for example used in scalable Microservice architectures, because here shared state means race conditions and race conditions make everything harder than it needs to be

Note that you don't need to create copies of the data necessarily as in micro services. The typesystem of Haskell or Rust enforces this behavior through constant/read-only types, which can still share memory as long as they aren't written to. This also allows for many optimizations such that unnecessary copies are avoided.

[SymbolicFrank]

Note that you don't need to create copies of the data necessarily as in micro services. The typesystem of Haskell or Rust enforces this behavior through constant/read-only types, which can still share memory as long as they aren't written to. This also allows for many optimizations such that unnecessary copies are avoided.

Yes, like strings in FPC.

You could do that yourself, by inheriting from TInterfacedObject and creating an Assign method, so you can make copies. Then again, you cannot keep state that way, as you (should) create a new one on write.

If you want a single state variable, you need to lock it with a mutex, or sync it through logging. I prefer a task queue myself.