In module 4.5, you distributed the Kladde over Orleans: quotes, appointments and deals live in grains, across several silos. In this module, you extracted a service. Both are called a "distributed system," and both spread work across several machines. Even so, the two tools answer different questions. This last lesson of the module puts them side by side so that, for a new piece of the Kladde, you can say with reasons: a grain, a service of its own, or both.
Two answers to two questions
| Orleans | Microservices | |
|---|---|---|
| The question | How do I distribute the state and computation of many small objects across several machines without my code being about that? | How do I separate parts of a system so that teams can build, deliver and operate them independently? |
| What is separated | activations on silos, per object | programs, deployments, databases, teams |
| What stays shared | one program, one deployment, one cluster, one type system | a contract over the network |
| Consistency | per grain, one call after the other | per service; in between, sagas and eventual consistency |
| Call between parts | a method call on a grain interface, Orleans finds the silo | HTTP, gRPC or a message, with everything from lesson 4.12.2 |
| A new field in the contract | version the grain interfaces, all silos roll out together | version the contract, each service delivers on its own |
From the teams' point of view, an Orleans cluster is therefore one thing: a program that distributes itself across machines. The grains in it are cut finely, but they are built and rolled out together. Microservices, by contrast, separate coarsely but for real: between two services stands the network, and every service can have a different version, a different team and a different technology.