Note: I'm in the process of moving to an awesome new blogging platform by the insanely great Dave Winer. If you blog I highly encourage you to look into Fargo. My new blog can be found at http://looselycoupledthinking.com.
I'm hearing the term "modern architecture" used quite a bit but haven't seen much clarification about what it actually means. Here are some principles and capabilities that I would expect to see in "modern architecture":
I'll plan to drill into more detail on several of these topics over the next couple of posts.
What do you think is missing from this list? What shouldn't be in this list?
BTW I'm currently reading Mike's new book. I'm liking what I've read thus far - I'll post a full review when I've finally finished it.
I feel your "modern architecture" targeting on web-based social networking apps, e.g., CAP, no stored procedures. Can these be applied to OLTP system as well?
@Bargitta Why couldn't they? There's nothing inherent in OLTP that says you "must" use any one technology/approach; only historical inertia.
@Bargitta: CAP and lack of sprocs isn't unique to web-based or social networking solutions. These design concepts can also be implemented with traditional systems. I've personally designed CAP-based systems for pure EAI solutions (e.g. no UX).
@MichaelY: You are correct. As I said earlier these aren't necessarily just for web-based solutions. As with any development effort stay focused on the business requirements, security, deployment constraints and service level expectations (SLEs) - these aspects should help you determine the optimal design.
@MichaelY I agree that there is no "must" in OLTP, but for me, it is hard to replace the RDBMS of a stock exchange system (a typical OLTP) with a nosql, and let clients accept eventual consistency. Though we can achieve consistency by adapting data model to that, we do not see the benefit outweights the effort.
That may explains why the combination of different data storages is quite popular.
P.S. Any pointers to OLTPs using nosql currently? (I do not mean newsql like sqlfire)
I'd like to learn your CAP-based systems for pure EAI solutions. Will you write about that some day?
Nice list. Not sure if this is implied by your point 22 (Asynchronous user experiences) but I would add Event Driven, which is basically asynchronous and push throughout.
@Bargitta: I'll post more as time permits. For now I'll point you to a fairly recent post from Rick Saling here: http://is.gd/eWji5J. Note: Rick mentions DTC which I am not particularly fond of (see #12 above). I prefer to design for idempotency "within reason". "Within reason" means the code necessary to enable idempotency shouldn't be larger than the code needed to perform the actual business event.
@Saul: EDA (event-driven architecture) scales wonderfully when properly designed and implemented. I've been threatening to post an entry on how the current fascination with APIs feels like a step backwards from event-driven architecture. Perhaps it's time...