Partager via

What is Modern Architecture?

  • Article

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 https://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":

  1. Cloud first
  2. Loosely coupled, distributed services
  3. Support Postel's Law
  4. Distributed storage and caching
  5. Weak/Eventual Consistency (CAP) - committed reads
  6. REST APIs where appropriate
  7. Scale out, not up
  8. Stateless
  9. No apparent downtime
  10. No biz logic in sprocs (prefer no sprocs at all)
  11. No ref integrity in db - enforce in service/app if needed
  12. No distributed txns
  13. Simple data abstractions for data access
  14. Multiple service versions in production 
  15. Active-active failovers across DCs where appropriate
  16. No singletons, at least 4 instances of a service running in prod (2 per DC)
  17. Consistent approach to monitoring/logging/SLE threshold compliance•
  18. Real-time access to service health/activity
  19. Design for/expect failure - degrade gracefully
  20. Test in production
  21. No reporting from txn data - keep OLTP and OLAP separate
  22. Asynchronous user experiences (no blocking)
  23. Avoid designing for a single device or form factor (user-scalable=0 is evil)

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?

 Updates:

  • Mike Kavis suggested via FB that "Modern solutions have a combo of SQL, nosql, cache, CDN, and many other data and storage technologies under the hood".  I'd interpret this as: Data stores should be abstracted without regard to where/how they should be accessed.   The abstraction hands off to a more granular access component/service with specific awareness to location/access requirements/etc.

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.

Comments

  • Anonymous
    February 16, 2014
    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?

  • Anonymous
    February 16, 2014
    @Bargitta Why couldn't they? There's nothing inherent in OLTP that says you "must" use any one technology/approach; only historical inertia.

  • Anonymous
    February 17, 2014
    @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).    

  • Anonymous
    February 17, 2014
    @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.  

  • Anonymous
    February 17, 2014
    @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)

  • Anonymous
    February 17, 2014
    I'd like to learn your CAP-based systems for pure EAI solutions. Will you write about that some day?

  • Anonymous
    February 18, 2014
    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. www.reactivemanifesto.org

  • Anonymous
    February 19, 2014
    @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.

  • Anonymous
    February 19, 2014
    @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...