Last re-post to test integration with Medium…

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.