If I build 92 of these things and they communicate with each other over sockets, files, streams, or messages, how does Coherence (a) help me visualize and debug that network, (b) transition the processing graph to a new state safely (blue/green deployments to one or more collaborating components)?

The problem that I have with these Serverless stacks is that they all demo pretty well for the trivial case of "it sends emails / transcodes video / puts files in S3" but then jump to "run your entire business on this" without clearly showing how its possible to do that with a complex system.

Is your solution different?

Hey, help me understand how you envision Coherence could help you debug that network.

I'm moving over some of my own services to Coherence so it's very much intended to "run your whole business".

There is so much more to running a cloud system than running a function - monitoring the function (billing, errors, throughput, latency), scaling the function, moving data between two functions, storing data, signaling a function, upgrading a function, downgrading a function, upgrading the stored data, authorizing the function to run, upgrading and downgrading stored data and functions while taking customer traffic with zero downtime without data loss.

"Backend-as-a-service" businesses need to check all of those boxes.

I'm going to decompress part of your comment here:

- scaling the function

This is where we've invested most of our effort. We're envisioning a load test demo soon.

- monitoring the function (billing, errors, throughput, latency)

This is something which we will need to invest more in. Great feedback here. We don't have much in the way of monitoring yet, but everything is there and we just need to expose it to the users.

- moving data between two functions, storing data

Traditional solutions like Redis and Postgres seem like a good solution here. You can't host them on Coherence yet, but it's something that we're working on.

- signaling a function, upgrading a function, downgrading a function

Versioning is particularly interesting here. A lot of time we've thought of these functions as ephemeral.

Send me an email (bryan at coherenceapi . com) I'm really interested to talk more about the use cases you're envisioning.

I would argue that in your use case, serverless in general is not a technology that will work for you, and trying to make it work is a square-peg-in-a-round-hole problem.

how do you stop someone from entering into some kind of malicious code?

We've made the assumption that users will enter malicious code and designed the security boundaries around that.

A malicious user that manages to break out of the container environment will only have access to other instances of their own applications. Stronger security policies exist between users.

I read the concern more as "what do you do to stop someone from cURLing an .iso a million times from someone's S3 account".

I'm not too sure what you mean here.

In terms of DOS'ing our services, we limit disk space usage per job, and are working on bandwidth limitations (this is a weakness, but for now we'll just ban abusers and work with those with legit needs)

Not DOSing your services, using your services to DOS others.

Or things like using stolen credit cards to do Bitcoin mining.

Every services provider will deal with this.

We have plans but ultimately won't really know until we're in the thick of it.

Our plans though are to limit bandwidth and ban abusers. We'll work with Stripe's Radar platform to reduce the stolen credit card fraud.