Distributed Systems Design

Editor's Notes

• #3: Hekelaan recruitersHelaasvindenzewél het werkvoor je, zoals PHP klussen in Limburg.BlaakSelectie : Actief in Zuid-Holland met vacaturesgefilterd op Rotterdam & Den Haag
• #6: Disclaimer : Jon Snow doesn’t know everything, me neither! ;-)I will explain concepts, I will answer questionsI will not go into discussion if it’s wrong or right or better or worse
• #7: Wie kent deze plaat?Wie bouwt applicaties volgens deze architectuurWie negeert deze architectuur bewust?
• #8: Haight-Ashbury in San Francisco
• #9: Network is reliableLatency isn’t a problemBandwith isn’t a problemNetwork is secure (only disconnected computer that is turned off!)Topology won’t change (servers moved across domains)Administrator will know what to doTransport cost isn’t a problem (bandwith, serialization)Network is homogeneous (all speak same protocol)
• #10: System is atomic/monolithicSystem is finishedBusiness logic can and should be centralizedMonolithic, één database, is wat ik altijd bouwdeFinished = greatest trick we ever pulled on businessCentralized = wat alle lagen zijn, wat een webservice is? Mag niet centralized?!?!?!
• #11: Seperation of concerns : Put the right stuff where it belongs, like business logic. But how many times haven’t you simply used the layers to pass data on to the next layer?Reusability : How many times have you reused business logic related code, like calculating how much something costs? How many times cross applications?Scalability : Have you succesfully scaled out layers over servers?wie schaalt zijn lagen over verschillende servers?wie heeft een database die performance bottleneck is?zien we connectie met de drie additionele fallacies?Database changes, column added. Goes up all the way to user interface to add a single column! What if entire tables change?
• #12: We creëren eigenlijk continu monolitische applicaties!Maar wat is een monolitische applicatie nu?A system which consists out of modules that all depend on each other.They cannot be used seperatly and cannot be reused by other software.
• #26: Instead of looking at it as computers, load balancer and physical systems...Look at it as an application, calling out to another application using messages. The messages are transferred to the correct handler by the framework.That way we don’t have a hard spatial coupling to our methods. And we can also choose to route our messages to wherever we want!
• #29: RPC benchmarks are performed as micro benchmark multiple times.Benchmarks don’t lie, but liers do benchmarks“Connection refused by the remote host”Threads allocate 1MB memory on stack. Data is stored in Generation 0, 1 & 2.GC comes by, tries to free up Gen2 memory & calls everything to complete stop!IIS recycles app pool. DB transactions have to time out though! How long? 5 to 10 minutes!!!
• #35: - Weinighandvaten HOE we ditbereiken- Run-time aspecten van services alsscalability, availability, en robustnesswordennietbehandeld.
• #36: Capability -> Generic value-add business capability (3rd party credit card processing or rating components)Activity -> Specific application-level business capabilityProcess -> Orchestration of business processUtility -> Generic infrastructural functionality
• #38: Websites need companiesContracts need to know which companies are still availableCustomer Services needs to know if bills are paid or not and if it's a higher ranking customerBilling needs to know the price of the products to calculate correct scoreNew requirementProducts need to know if a special discount or bulk discount was made
• #76: Hoe bouw je een systeem wat nooit down gaat, zelfs niet tijdens updates.
• #77: Wat schaalbaar en flexibel is, maar toch te bouwen is door junior ontwikkelaars.
• #79: Exceptionsmogenoptredenvanwege bugs, nooitvanwege business errorsTeken je process flow goed!!!