In a recent post Mike Amundsen writes about building evolvable systems where he expands on his presentation "Beyond REST : An approach for crafting stable, evolve-able Web applications". The question he hopes to answer in the presentation is "How can we design and implement distributed network solutions that remain stable and flexible over time?" He says
[...] it's not all that hard to put up an 'app' that can be reached 'on the Web.' the hard part is implementing a solution that can successfully evolve over time. my assertion is that one successful approach involves a combination of accepting and embracing some realites of dist-net architecture, isolating the key transient aspect of the environment, and focusing most of your creative eneregies on expressing the vital problem domain information in a flexible and evolvable way.
According to Mike the keys to answering the question in are focusing on three aspects of the systems
* The transfer protocol - He argues that the current tooling around buiding distributed systems hide the underlying protocols from developers, often sacrificing inherrent advantages of the transport/protocol in the interest of abstraction.
the better way to deal with HTTP is to embrace it. let HTTP lead system designers in the direction of lossy, chunky, state-less designs. accept HTTP as the stable rarely-changing foundation for your implementations. [...] so that all your dist-net designs reflect the power, stability, and reliability of HTTP itself.
* State Management - Though a special case of recognizing and embracing different aspects of the protocol; state management is commonly used to maintain stateful communications over protocols (HTTP in his example) that arent inherrently stateful.
instead of constantly inventing new ways to ignore that state-less nature of dist-net interactions, designers and developers need to stop polluting the public internet with their transient personalization data bits. clients should keep track of the information users need (that's why they are often called user agents).
* Domain Semantics - He goes on to explain how to one could use media types to share the domain sematics between the client and the server.
it's the media type that provides the chance to customize messages between parties; to share understanding of what each data element and hyperlink 'means.' it's the media type that is specifically provided a registry where individuals who want to find shared understanding of a problem domain in order to implement mutually agreed appropriate domain-level solutions.
In conclusion he says
building evolvable systems is not very complicated. it requires clear understanding of the transfer protocol, careful isolation of transient data, and dedicated work to properly express the problem domian via shared messages. it may not be a complex process, but it does take hard work.
Can you think of examples, in the enterprise or otherwise, where these aspects hold true aswell?
