Microservices without the drawbacks: Unison Cloud as a typed RPC middleware for your org

[@masegraye]

How do you think about cross-tenancy calls? IIRC, this model assumes everyone is in the same codebase and compute fabric. Something like Share brings the code to the caller, which is great for efficiency, but not great for IP protection. Do you essentially just use the Unison proxy for cross-tenancy situations (and just use Unison on both sides)? That gives you essentially the same network and code/data privacy isolation we have today. Or do you see a world where things go the other direction: Tenancy A's application code moves toward Tenancy B's data (essentially in B's enclave), where it can do arbitrary computation on it, and then some data policy (also defined in Unison) allows some data to make it back to Tenancy A?

[@skeptcode]

I understand when you say that some callers bring code to execute locally (thereby improving latency), but that only makes sense for stateless code-which can be solved by using libraries. What about stateful or persistence-related code, which (I guess) tends to account for most of the headaches?

[@jakecleary]

Yeah it’s a fascinating idea but I’m struggling to understand what happens when that album or thumbnail service naturally needs to talk to its db

[@andgatehub]

@@spartanghost_17 this shit is amazing for startups, hackathons, and side projects.

[@unisonlanguage]

If you have a service that needs to hit a database, that's ok. You're still saving an extra hop via ASGC. Instead of having to make one network hop to get to the service, then another hop for that service to talk to the database, you bring the service to the call site and make a single network hop to talk to the database. There are services that have in-memory state that they're accumulating and this video doesn't talk much about those. A data pipeline service is often this, but is often better handled with a distributed stream processing framework which can do exactly-once delivery and eliminate bookkeeping. For this type of system, being able to dynamically move code around can be a win as well - for instance, two pipeline stages deployed by separate teams can be dynamically colocated and pass data in memory rather that via a slower / more expensive materialized topic / queue. I think this question of "should this be a library or a service" is very interesting. Libraries don't really achieve separate deployment - all library code changes need to be propagated to (transitive) dependents, which all need to be redeployed, even though many code changes in services are backwards compatible and "dynamic binding" is simpler and less work. On the other hand, people also use services just to avoid dependency conflicts. If you import a library, you (with most technologies) import its dependencies, and can run into diamond dependency conflicts. Having a service be its own repo, with its own dependencies, eliminates this possibility. But in Unison, there are no diamond dependency conflicts, so you wouldn't introduce a service for just this reason. The video mentions separate deployment, separate permissions, and separate scaling as three fundamental reasons why services are introduced, and I think these reasons make sense regardless of the services being stateful / stateless.