Successfully reported this slideshow.
Your SlideShare is downloading. ×

Introduction to Distributed Architecture

Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad

Check these out next

1 of 61 Ad

More Related Content

Viewers also liked (18)

Advertisement

Similar to Introduction to Distributed Architecture (20)

Recently uploaded (20)

Advertisement

Introduction to Distributed Architecture

  1. 1. Distributed Architecture Introduction to
  2. 2. What is Architecture? A software architecture is an abstract view of a software system distinct from the details of implementation, algorithms, and data representation. SEI @ Carnegie Mellon
  3. 3. Why Architecture Matters
  4. 4. Accidental Architecture Every… system has an architecture. While some of these architectures are intentional, most appear to be accidentalGrady Booch
  5. 5. Requirements Analysis Design Code and Test Integration System Test Waterfall Process
  6. 6. Requirements Analysis Design Code and Test Integration System Test Waterfall Process Analysis Paralysis Massive Integration Design divorced from reality
  7. 7. Manifesto for Agile Software Development We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more.
  8. 8. Scrum: An agile Process
  9. 9. Architect Code Techies crave Extremes
  10. 10. Functional requirements What the system should do. • Use cases, User stories, acceptance criteria • Defines passing QA • Day to day you focus on this
  11. 11. Nonfunctional requirements What the system should be. • Extremely expensive or impossible to “fix” later on • Defined passing Production • Assumed by your customers and users
  12. 12. Nonfunctional Requirements • Availability • Stability • Efficiency • Reliability • Maintainability • Extensibility • Fault Tolerance • Security • Capacity • Latency • Flexibility • Scalability
  13. 13. Functional: Passed QA Beautiful site (in my opinion) Easy to use Nonfunctional: Failed Production Availability Stability Latency Capacity Throughput
  14. 14. ArchitectureThere is no best architecture
  15. 15. Pacemakers and Guided Missiles
  16. 16. The Flying Buttress
  17. 17. Patterns
  18. 18. Example: Layered Architecture
  19. 19. Three Tier Architecture The classic 3 tier architecture
  20. 20. N-Tier Architecture Because three tiers wasn’t enough!
  21. 21. N-Tier Architecture SHAREPOINT BIZTALK SQL SERVER Windows Server 2008 SMS License managementIIS
  22. 22. Questions about Architecture?
  23. 23. Distributed Architecture Designs appropriate for small brochureware websites fail outrageously when applied to thousand- user, transactional, distributed systems... Michael T. Nygard
  24. 24. Key Constraints on Distributed Systems • Stability • Reliability and fault tolerance • Consistency • Capacity and Scalability • Security
  25. 25. Scenario: Stability You are the lead developer on a national health care site that will register millions of users a week. You are responsible for the signup process. Your team must verify the identity of users with a third party API. You call the service and the third party system will return a boolean true if the identity is valid or false otherwise.
  26. 26. private string Register(RegistrationInfo registrationInfo) { try { bool validIdentity = identityService.verifyIdentity(registrationInfo); if (validIdentity) { database.save(registrationInfo); return “register_success.htm"; } return “register_failure.htm"; } catch (Exception) { return "errorpage.htm"; } }
  27. 27. 6. Registered Identity Verification Database 2. Verify 3. Verified Site Server Stability 4. Save User5. User Saved 1. Register
  28. 28. 6. Registered Identity Verification Database 2. Verify 3. Verified Site Server Unbalanced Capacities 4. Save User5. User Saved 1. Register
  29. 29. Identity Verification Blocked Threads Site Server Verify sally Verify bob joe verified Verify joe Verify sally Verify joe Verify bob Verify bob Verify bob Verify bob Verify bob joe verified
  30. 30. Cascading Failures Site Server Site Server Site Server Site Server
  31. 31. private string Register(RegistrationInfo registrationInfo) { try { identityService.Timeout = 10000; bool validIdentity = identityService.verifyIdentity(registrationInfo); if (verified) { db.save(registrationInfo); return “register_success.htm"; } return “register_failure.htm"; } catch (Exception) { return "errorpage.htm"; } } Pattern 1: Timeouts
  32. 32. Identity Verification Pattern 1: Timeouts Site Server
  33. 33. private void BeginRegister(RegistrationInfo registrationInfo, Function<string> callback) { try { identityService.EndIdentity += identityService_EndIdentity(callback) identityService.BeginIdentity(registrationInfo); } catch (Exception) { callback("errorpage"); } } private void identityService_EndIdentity(bool success, Function<string> callback) { if (success) { callback("register_success.htm"); } callback("register_failure.htm"); } Pattern 2: Non-blocking I/O
  34. 34. Pattern 2: Non-blocking I/O Identity Verification Site Server
  35. 35. For Users… ==
  36. 36. The site is stable. We’re still failing.
  37. 37. What’s the president recommending?
  38. 38. What might be happening Thank you. We’ll email you when you are verified.
  39. 39. What might be happening Identity Verification
  40. 40. “The” Registration Process When two principles are pushing in opposite directions, some underlying assumption is wrong. Often the word the is the culpritUdi Dahan
  41. 41. Read this again You are the lead developer on a national health care site that will register millions of users a week. You are responsible for the signup process. Your team must verify the identity of users with a third party API. You call the service and the third party system will return a boolean true if the identity is valid or false otherwise.
  42. 42. Pattern 3: Decoupling Site Server Thank you. We’ll email you when you are verified Pending Registration Database
  43. 43. Pattern 3: Decoupling Pending Registration Database Verification Application Identity Verification
  44. 44. Scenario 2: Reliability You are the lead developer on a hospital’s prescription filling service. Your RX wholesaler has provided you with an HTTPS endpoint to integrate with. It is critical a prescription is not accidently prescribed twice and that prescriptions are not lost.
  45. 45. 5. Success RX Service 2. Fill RX 3. RX ID Site Server Reliability 1. Prescribe Database 4. RX ID and Fill Info5. Record Updated
  46. 46. Invoking the Serviceprivate string Prescribe(PrescriptionInfo prescriptionInfo) { try { RxService rxService = new RxService(); int rxID = rxService.Prescribe(prescriptionInfo); database.Save(rxId, prescriptionInfo); return "success.htm"; } catch (Exception) { return "errorpage.htm"; } }
  47. 47. 404 Timeout RX Service 2. Prescribe Site Server What if the network goes down? 1. Prescribe
  48. 48. Invoking the Serviceprivate string Prescribe(PrescriptionInfo prescriptionInfo) { try { RxService rxService = new RxService(); int rxID = rxService.Prescribe(prescriptionInfo); database.Save(rxId, prescriptionInfo); return "success.htm"; } catch (Exception) { return "errorpage.htm"; } }
  49. 49. RX ServiceSite Server Can I retry? Prescribe RX Service Site Server Prescribe Got it, but I couldn’t get Back to you. 404 Timeout
  50. 50. RX ServiceSite Server Pattern 1: Idempotency Prescribe RX Service Site Server Prescribe Got it, but I couldn’t get Back to you. 404 Timeout Sheesh… I already got it!
  51. 51. 5. Success RX Service 2. Fill RX 3. RX ID Site Server What if the database is down? 1. Prescribe Database 4. Update Patient Record
  52. 52. Invoking the Serviceprivate string Prescribe(PrescriptionInfo prescriptionInfo) { try { RxService rxService = new RxService(); int rxID = rxService.Prescribe(prescriptionInfo); database.Save(rxId, prescriptionInfo); return "success.htm"; } catch (Exception) { return "errorpage.htm"; } }
  53. 53. Can We Guarantee this code?private string Prescribe(PrescriptionInfo prescriptionInfo) { try { RxService rxService = new RxService(); int rxID = rxService.Prescribe(prescriptionInfo); database.Save(rxId, prescriptionInfo); return "success.htm"; } catch (Exception) { return "errorpage.htm"; } }
  54. 54. Pattern 2: Transactional Queues
  55. 55. 3. Pending Site Server Transactional Queue 1. Prescribe Fill RX Message Queue
  56. 56. Inserting into a Queue private string Prescribe(PrescriptionInfo prescriptionInfo) { try { Queue.save(new RXPrescribeMessage(prescriptionInfo)); return "rxPending.htm"; } catch (Exception) { return "errorpage.htm"; } }
  57. 57. Transactional Queue Queue rxPrescribeMessage RX Service Fill rx rx ID Handler rxDBUpdateMessage
  58. 58. Transactional Queue Queue rxDBUpdateMessage Save rx Handler Database
  59. 59. Message Handlers public void HandleRXPrescribeMessage(RXPrescribeMessage message) { var prescriptionInfo = message.prescriptionInfo; RxService rxService = new RxService(); int rxID = rxService.Prescribe(prescriptionInfo); Queue.save(new RXDBUpdateMessage(rxID, prescriptionInfo)); } public void HandleDBUpdateMessage(RXDBUpdateMessage message) { var rxId = message.rxID; var prescriptionInfo = message.prescriptionInfo database.Update(message.rxID, message.prescriptionInfo) }
  60. 60. Nygard, Michael T. Cynical software expects bad things to happen and is never surprised when they do. Cynical software doesn’t even trust itself.. It refuses to get too intimate with other systems, because it could get hurt.

Editor's Notes

  • Correct but lacking.

    Why would I need a view distinct form the code? Is architecture just busy work?


  • Of the things you will learn at this conference, I believe this will be the most important stuff for your long term career.
  • What causes accidental architecture?
    - Misusing agile methods
    - Bad estimation. If you told your customer we’re not going to do architecture because we think you don’t want us estimating for it…
    - The expectation that a product will provide an architecture.
  • Often called the “ilities”

    Your customers and users don’t know they need to tell you these things.

    Assumptions made by your customer:
    - The site is going to be performant.
    - The site can handle an infinite number of users.
    - The site will be secure
    - The site will maintain itself. We already paid for it – look the project is done. You don’t need to continue working on this thing do you? We spent millions!
    - The site will be stable. Why would the site ever need to be down? 5 9’s.
    - There shouldn’t be runtime errors. We went through the entire QA process!
    - Why would the number of users on a site even matter? Look at Google! It’s just a search box!

    Ultimately defined by physics (The twelve fallacies of distributed computing)
    - Bandwidth
    - Moore’s law
    - Speed of the light
    - spinning rust

    What about the cloud?
    - You too can spend an infinite amount of money in the cloud!

  • The constraints and requirements very substantially for each system.


    Beware if someone approaches you in a back alley and says “pssst…” wanna buy an architecture

  • I better choose a memory efficient architectures for the Pacemaker.

    Do I care if I have an efficient garbage collection if my computer is destroyed upon hitting its target?

  • In physical architecture we see certain patterns such as the flying buttress here.

    Remediates lateral forces
    Allows us to build less massively and have stained glass windows


  • Let’s think instead of architectural patterns.
  • Each architectural pattern will have pros and cons

    Who can think of something good about this pattern?

    1 Understand a single layer without understanding the whole
    2 Substitute layers so long as their interfaces don’t change
    3 Reduce coupling
  • The classic three tier enterprise architecture is an example of a layered architecture.


  • Too much of a good thing?

    And N-Tier architecture is also a layered architecture
  • The enterprise is and always has been starved for good architecture.

    Beware vendors promoting architectures. They surely have some products to sell you.
  • Therefore…
    When dealing with distributed systems we should choose patterns that mitigate constraints relevant to distributed systems.
  • Unbalanced Capacity
  • Your system is at the mercy of this third party system
  • Their problems become our problems very quickly
  • While not perfect, Timeouts are your first line of defense. Always use timeouts.
  • What about Node.JS?

    With non blocking I/O where a response is required, we’ve really just kicked the can.



  • RLY?
  • Zen like patience required for this job.
  • With non blocking I/O where a response is required, we’ve really just kicked the can.
  • With non blocking I/O where a response is required, we’ve really just kicked the can.
  • Unbalanced Capacity
  • Unbalanced Capacity
  • Unbalanced Capacity
  • Unbalanced Capacity

×