2023 Was a Turning Point for Microservices

For industrial process control, the IEC-61499 [1] standard introduces an architecture where the program and its function blocks are independent of where the components actually run.

I don't believe automatic distribution of the components to different devices is included. But, it allows setting up function blocks and their interconnections, and then distributing function blocks between devices. Inter-device communication is included in the standard.

Compared to standard PLC programming (IEC-61131), 61499 adds events to the function block diagram paradigm.

I don't think this standard os popular yet, but I've always wanted to give it a try.

4diac is an open source implementation.

[1] https://en.m.wikipedia.org/wiki/IEC_61499

[2] https://www.eclipse.org/4diac/

The worst pile of garbage software I have seen in my 30+ years career is a micro-services system. With 150+ services making it nearly impossible to figure out why the software blows up in production.

The easiest to maintain almost-never-a-bug-in-production software I have ever worked with is a massive but well-designed million+ line C++ monolith.

No architecture pattern or programming language will guarantee a well designed system. Only a good team of experienced developers, who truly understand how to design software well, will create great software.

It’s a people problem not an architecture pattern problem.

There is no silver bullet.

Any additional details on what tech they used to achieve this automatic splitting?

Pretty huge caveat over the entire piece. If we all had nice modular code bases this while thing would be easy regardless of the deployment details.

> The programming model enables a developer to write a distributed application as a single program, where the code is split into modular units called components (Section 3). This is similar to splitting an application into microservices, except that microservices conflate logical and physical boundaries.

I definitely do see the merits to this. The fact that we always see logical separation of services resulting in split codebases did never sit right with me.

We've been trying to solve the same problem, but albeit in a different way here: https://docs.differential.dev/getting-started/thinking/ (Disclaimer: I'm the founder - would love to collaborate)

Trying to answer the question of - can you build your entire stack in a monolithic way, but split it to domain-driven services at the runtime?

That way, you get the developer experience of co-location, and runtime benefits of isolated workloads. The service definitions are malleable and can evolve as the complexity increases.