ReubenBond
commented
6 years ago Thanks for opening this.
Regarding Schema Changes, it's worth linking #2653. In what time I can scrounge together, I have been developing https://github.com/ReubenBond/Hagar as a solution for rich serialization which supports schema evolution. In my mind, what I have is a sound and fairly complete solution to this problem, built on foundation laid by Bond, ProtoBuf, etc
Orleans persists state for many reasons both in the core framework and extension libraries. Persistent state introduces several concerns, among which are:
• Data partitioning. • Schema changes. • Supported backend storage systems. • Data migration and management tools. • Custom serialization.
Of the above issues, some are addressed, some are addressed inconsistently, and others are not addressed. This introduces risk to developers using Orleans because the ease of use hides the complexity associated with persisting state in an evolving production service. The responsibility ultimately lives with the service developer, but the way Orleans manages persistent state offers little to help developers be successful, and can in some ways hinder them by hiding the risks. Without addressing these concerns, adding new features like Transactions or Indexing are more difficult and aggravate the problem, while refactoring systems which have strong dependencies on storage, like streaming or reminders, are significantly hindered.
This issue is intended as a starting point for resolving these issues. The problems are beyond what should be covered in a single issue, so I suggest this thread be focused on identifying issues that need be solved, which should be spun off as separate issues to be resolved independently.
To start the conversation:
Data Partitioning Currently each silo is part of a cluster which is identified by a service Id, which identifies the type of service running on the cluster and should remain constant through the life time of the service, and a cluster Id which identifies a deployment of the service. Storage is partitioned by the service Id.
Schema Changes Storage is inconsistent in how data schemas are translated to storage, but most persistence logic uses Orleans serialization to convert complex objects to byte arrays to be stored. This does not support changes to the persisted state’s schema. This both limits the Orleans team’s ability to improve Orleans without introducing breaking changes to customers (for which few options are available to work around), as well as application developers ability to modify their own persisted data schema’s when persisted using Orleans features.
Supported backend storage systems We support abstractions for various components which allow for integration with different backends. However, these abstractions are not well defined enough for engineers to implement or program against them with clear expected behaviors. For instance, supported state size, error handling, and monitoring expectations are often unspecified and vary per implementation. In more recent additions, we’ve attempted to add test harnesses which can be used to vet the behaviors of implementations in an effort to standardize and formalize these abstraction layers, but there is still much to be done.
Data migration and management tools There is little to no support for cleaning up, migrating or managing persisted state outside the context of the public abstractions.
Custom serialization Custom serializers are primarily supported via the extensibility points in the serialization manager, but the serialization manager was initially and primarily intended for networking serialization, not storage which has different requirements. Some other patterns have been attempted for special cases, like streaming, but no storage specific custom serialization pattern is in use uniformly in the system.
Thought/comments? What did I miss or get wrong?