There's nothing permanent in software engineering. Consider building services for Internet applications - for the last few years service design principles were quite straightforward:
- stateless >>> stateful
- sticky session (& session affinity) are made of suck
- if you really, really need session, at least make it immutable
- build a dedicated service layer, but make it as lightweight as possible & keep the state in separate persistent storage
If you think about it for a while, it all made sense (still makes!), but ... there's a new Holy Grail bursting in popularity these days (however, to do justice I have to mention it was emerging for quite a lot of time already ...) - stateful services are back!
The idea of microservices slowly matures towards microinstances - independent, bounded context that not only encapsulate the logic, but the piece of state as well. As they're supposed to be small & fast (with minimal latency) - and in actor-based implementation small is really small - primary source of information can reside within the instance (in memory) itself.
Huge, back-end persistent RDBMSes are not that welcome anymore - they don't scale out, easily become bottlenecks & even easier get tangled (due to direct data dependencies) if not maintained properly (controlled isolation of bounded contexts).
Obviously going stateful instead of stateless raises some questions:
- what if instance goes down? does the state do as well?
If it's the only instance that keeps this quantum of information - it does. If the state is kept in memory, it vanishes. However this is something that can be fixed in a very simple way - command-sourcing the incoming commands in a form of persistent transaction log is very quick, simple & enables re-creation of service state whenever it's needed. It's not trivial (you may need snapshot policy as well), but it's definitely doable.
- does it mean each service will be mini-distributed system?
Yes. But this is what Microservice-based architecture is about - it's a distributed system by design.
- will my system remain transactional after this reshape?
There's no short answer. If you serialize your commands to distributed data store & both reads & writes use quorum (majority of cluster nodes) AND your service is synchronous (even if memory-based operation is blitz, it waits until command store returns an ACK) - then you seem safe enough, but keep in mind it's still BASE, not ACID!
- operations-wise, having all these service data distributed won't be a huge pain (regarding backups, etc.)?
It will be. Proper tooling (with a lot of automation, monitoring & sanity checks) is crucial, but it plays well with the modern approach to operations - procedures & responsibilities are to be split just as the services themselves. Snapshotting the persistent state of whole ecosystem is not the goal when services aim for real independence.
It's a very interesting trend. Risky, demands true technical maturity, but can bring very substantial benefits (under some given circumstances):
- true componentization & enhanced control over coupling
- simplification of continuous delivery
- increased testability
Pic: © studiostoks - Fotolia.com
