Update README.md - Add Distributed Execution Platforms.

[MichalCz]

Hi there!

I'd like to add Scramjet Platform to the list. The reasoning is that it fits at least two of the three criteria you mentioned (full disclosure: I'm the author, so I can't claim regardless of my personal opinion). The software has won three awards since full launch, at: CloudX, API World and DeveloperWeek conferences.

I'd also like to propose to add the "Distributed Execution Platform" category, as our platform is combining some features of stream processing (the software model is based on delivery of streamed data between programs in remote environments), remote execution and workflow platforms and can't be reasonably pushed to a single one of the current categories. I believe Temporal would actually fit quite closely with Scramjet, as through a different set of features they also offer similar value.

I do see the gentle reminder, but we're still small and additional visibility would let us continue bringing a fully featured solution to the open source community, and additional justification to our backers to fund the effort in that direction.

Please let me know of any suggestions and additional information to provide.

[v-bus]

Hi! Why do you call it DEP? It looks like heterogeneous virtualization or heterogeneous cloud computing. And your github project looks old https://github.com/scramjetorg/framework-v4

[MichalCz]

@v-bus

The github project of the platform agent is here and is actively developed: https://github.com/scramjetorg/transform-hub

The framework is stable and is in maintenance mode.

Regarding the naming: the main reason is that we're not aiming this solely for cloud computing, but also for on-premise and localised deployments. The agent is capable of running on something like NanoPi or a Raspberry Pi Zero with just 512 MB of RAM, and the use cases we're after are more on how to glue cloud computing resources with localised systems (imagine something in Retail or Industrial space). The distributed nature of the use case is key here, as we believe that intra-cloud use cases are solved to a certain extent and though could be improved, there's just incremental value we can bring.

To put it in a context - imagine the amount of code to be written when having to do something in the cloud when a physical button is pushed in comparison to turning on a lightbulb in a physical location, when an event in the cloud happens. We're aiming to solve cases similar to the latter.

[MichalCz]

And then - looking at it from that perspective you'd think Industrial IoT, or Retail IoT - which again escapes the full picture.

But I'm definitely open to hear any advice as a new category is always an uphill battle. :)

[v-bus]

I get it. We developed nanoservices for such solution https://github.com/dmerkushov/nanoservices - better to understand, and newer version https://github.com/dmerkushov/nanoservices2
Main idea to run many nanoservices at any place you can run them. They will be fine while they have network connectivity. We wanted to develop nanoservices skeletons for different languages. On a private production environment, we launched python, node.js and C++ code on many desktops.

[MichalCz]

That's really cool - we also have a runner developed for a project that runs C++ code (or any native code packaged as a .so or potentially .dll - the latter not well tested though) - this is though one of those things that are kinda purpose built. I'll look at nanoservices, as it's possible to build an adapter to it (essentially treat is as docker/k8s replacement in our codebase).

But yeah, essentially we want to run programs in a distributed set of remote environments, hence the "Distributed Execution Platform". You click a button "in the Internet" (or call a public API) and all of the sudden, a couple milliseconds later, a digger in Australia is locked so it can't be stolen. :)

[MichalCz]

Hi, just checking in - is it ok to merge?

[stn1slv]

Hi @MichalCz ,
I apologize for the late response. I have a few doubts:

1. New categories are welcome, but they should be widely known in the industry (for example, there are analytical reports from Forrester or Gartner for this class of solutions). As for Distributed Execution Platforms applied to integration solutions, it doesn't seem to be the case. Therefore, I suggest adding the solution to an existing category.

2. If this is an OSS-based solution, it is highly recommended to provide a link to the github repository instead of a link to the website.

[MichalCz]

Hi @stn1slv,

Thanks for the remarks - since the Cloud Platform is as of yet not open-source I decided to include the Transform Hub (which is) in the Workflow Engines and the platform in iPaaS - which would cover the category I wanted to create here.

[stn1slv]

Please remove new line

[stn1slv]

Which workflow management capabilities does it provide? For example, long-running and stateful, timers, visual workflow management user interfaces, support workflow management notations (like BPMN, CMMN, DMN) or custom ones, etc.

[stn1slv]

It appears that the product does not possess the core capabilities of an Integration Platform as a Service. These capabilities include strong support for technical protocol connectors, application adapters for both SaaS and on-premises packaged applications, support for various data formats (such as XML, JSON, ASN.1, etc.), and data standards (such as CIM, EDIFACT, HL7, SWIFT, etc). Additionally, an Integration Platform as a Service should offer orchestration, choreography, data validation, and transformation functionalities.

[stn1slv]

Perhaps, the product's main focus is not on system integration.