Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Iip saa s - kennissessie exact - tu delft - deel 2

1,566 views

Published on

  • Be the first to comment

  • Be the first to like this

Iip saa s - kennissessie exact - tu delft - deel 2

  1. 1. NWO Scale.It.Up research project Andy Zaidman 17-09-10 Delft University of Technology Challenge the future
  2. 2. Collaboration Exact – TU Delft Industry as laboratory MTS project 1 PhD student Funded by Exact NWO Jacquard Scale.It.Up project … Many others! 2
  3. 3. NWO Jacquard Scale.It.Up project • 440K € funding from NWO, Dutch science foundation • Starts November 1st, 2010 (lasts approximately 4 years) • 2 PhD students • Brings together: 3
  4. 4. Industry as laboratory approach Industry as laboratory We have a Research please! question or Research + issue Evaluate please! prototype Ideas or techniques for Research next-gen products papers 4
  5. 5. What is the setting of Scale.It.Up? • Multi-tenant software systems • A single (or limited number of) physical servers • A large and diverse user base vs. • Requirements 1. Configurability: system configurable per tenant 2. Performance: system should cope with large user base 3. Zero-downtime: downtime should be (near) zero 5
  6. 6. Requirement 1: configurability • 1 server, 1 application  reduces cost of deployment • Yet, tenants want configurability/customization • Look-and-feel, workflow, opportunities for integration • Solution: online versioning • Ideally, the software can be configured for each tenant  limited number of configurability options  probably fine for most tenants • More configurability? Maintain different versions of services  create specific service for tenant, country, branche, …  also allows tenants to stick with old version for some time 6
  7. 7. Requirement 2: performance • 1 or a limited number of servers • Optimal use of hardware resources • But when should we scale up? • Precise performance monitoring • Identify critical points ahead • Past usage behavior • Exceptional events (end-of-month, taxes, …) 7
  8. 8. Requirement 3: Zero-downtime • 1 server, many users • Only 1 server  single point of failure for many users • Solutions: • Build in redundancy  let backup server take over for a while • Allow online upgrades and tests • When is the load of the server low enough to test? • When are the least number of users affected? 8
  9. 9. Innovations w.r.t. maintenance and zero downtime Key aspects Evolve and test the MT application @ zero-downtime Create an Key technologies update Tracing/monitoring Integrate Schedule test update Versioning Configurability Schedule update Perform Online testing Test 9
  10. 10. Innovations w.r.t. performance • Determine critical points in time at which the hardware should be scaled up • Extend current load-balancing schemes with tenant- specific information (e.g., time-zone, past usage behavior) 10
  11. 11. Eager to start! Follow our adventures: http://swerl.tudelft.nl/bin/view/ScaleItUp/WebHome 11
  12. 12. QUESTIONS? More information: Web: http://www.st.ewi.tudelft.nl/~zaidman Email: a.e.zaidman@tudelft.nl 12
  13. 13. Network and service orchestration IP SaaS kennissessie Dr.ir. Marijn Janssen Delft University of Technology 13
  14. 14. Traditional Software Software as a Service • Large monolithic • Software becomes utility • Develop, Implement , Maintain your • Subscribe, Plug In, Use, Own Pay-per-Use • Creating of legacy • No concern of updates, always up-to-date • Designed to last • Problem shift to composing and • Variety of expertise integration • Quality assurance? Back up options? 14
  15. 15. Service compositie voor maatwerk Public services ZZP/Sole* Private services Services portfolio * self-employed without any personnel 15 Cascadis masterclass 15
  16. 16. The Promises of SaaS • Real-time • Pay-per-use • No maintenance and control costs • Always up-to-date (versioning) • Service vendor should ensure availability, scalability, security and other quality requirements • Increased control by users • Easier exchange of data • Focus on acquiring functionality • No need for software monitoring, although .. • .. 16
  17. 17. Saas brings new challenges • Bepalen wat we willen • Zoeken van geschikte services • Waar zijn de services te vinden? • Wie beheert ‘gouden gids’ • Zijn services getest? Gecertificeerd? • Service integratie • Kunnen de services samenwerken? • Welke service volgt na welke? • Service uitvoering • Doen alle services het? Hoe continuïteit garanderen? • Service levels? Hoe opschalen? • Eind-tot-eind beveiliging? Autorisatie tot data? • Welke wetgevings regime als de grens overgestoken wordt? • Wat gebeurt er als er een deel faalt? • Geeft service het juiste ‘antwoord’? • Wie is er verantwoordelijk als iets missies-kritisch niet werkt? • Wie is eigenaar van de informatie? KERN: grotere directe afhankelijkheid van andere partijen 17
  18. 18. Wie orchestreert de afhankelijkheden? bedrijfsleven overheid • Hoe zo zooi? • Hoe verkrijgen ik de voordelen? • Heb ik genoeg kennis? En tijd? • Hoe dienstgericht werken? • Wie investeert in de keten? • Wie is de regisseur? ? Burger/bedrijf 18
  19. 19. De klant orchestreert: “alles zelf doen” • Ondernemer heeft contact met vele organisaties voor belastingaangifte, aanvraag antwoord voor leaseauto, boekhouding, …. antwoord klant aanvraag • Vele afstemmingen • Managen van verschillende contracten en sevice levels • Duplicaties gegevens • Inefficiënte uitvoering • Onthoudt het maar eens .. 19
  20. 20. Hoe gebeurt dit op andere plaatsen? 17-09-10 Delft University of Technology Challenge the future
  21. 21. Georchestreerd dienstverleningsproces* • Een ‘orchestrator’ of ‘service broker’ neemt orchestratietaken over van klant aanvraag beschikking klant • Klant heeft eenduidig aanspreekpunt orkestrerend proces • Klant krijgt eenduidig antwoord • De orchestrator selecteert services, georkestreerd proces integreert, monitored en neemt maatregelen • Geen onnodig specialistische kennis nodig en langdurige zoekprocessen • Betrouwbaarheid • Orchestrator specialiseert • Innovatie ligt ook bij orchestrator 21
  22. 22. Restaurant 22
  23. 23. Welke orchestrator rollen zijn er? 17-09-10 Delft University of Technology Challenge the future
  24. 24. Ketenorchestrator rollen • Ervaring laat zien dat verschillende rollen noodzakelijk zijn • Rollen kunnen bij verschillende partijen belegd zijn 1. Initiator en facilitator (mogelijk maken) 2. Ontwikkelen (applicate en keten) 3. Standaardiseren 4. Compositie 5. Technische facilitator (infrastructuur) 6. Dagelijkse aansturing en voortgangscontrole 7. Service and product aggregatie 8. Accountability 9. Continue procesverbetering 24
  25. 25. Voorbeelden 17-09-10 Delft University of Technology Challenge the future
  26. 26. Hoe kunnen we dit realiseren? 26 Cascadis masterclass 26
  27. 27. Uitgangspunten • De klant stuurt, maar heeft niet de last • Specialisatie blijft • Werken in silo’s, maar verder kijken • Regie over de silo’s • Kunnen meerdere orchestratoren zijn • Specialiseren in services zoeken, afspraken maken en integreren • Maakt het makkelijker • Continue services toevoegen, verwijderen en innoveren 27
  28. 28. Hoe ondersteunen we dit? overheden autoverzekering Controleer data en Registreer prive of Scan bon bevestig werk rit Controleer route Registreer prive of Registreer roujte met werk rit adressenbestand 28
  29. 29. Platform as a Service – klant stuurt overheden autoverzekering Afgelegde km SaaS providers datawarehouse Klant info lant info K I-phone scan Controleer data en Registreer prive of Scan bon bevestig werk rit Geografische data Controleer route Registreer prive of Registreer roujte met werk rit adressenbestand 29
  30. 30. Practice might be more complex: mixed orchesration forms D Self-coordination Level of user involovement A • Context and Activity are most often implicit B E • Specialist expertise and knowledge • Monitoring and keeping up-to-date C F Multi party peer-to-peer relationship A D • User coordinates one part • Broker for selecting trusted services B E • Context and Activity are explicit • Context, ALS and Coordination are handled Level of outsourcing C F by the fabric broker Full orchestration Orchestrator A D • Hub and Spoke relationship • Hub can be a service provider or neutral B E platofrm coordiantion • Coordination is handled by the hub C F exclusively • Economies of scale and scope 30
  31. 31. Het gaat om alle lagen* Network and Governance Power and trust Agreements and contracts Accountability and processes Coordination Organization Responsibilities Division of roles Aligning processes (technology) Standards Information Interoperability Data *B. Klievink & M.Janssen (2010). Coordinating Multichannel Service Delivery in Digital Government. In: Proceedings of the 11th annual conference on Digital Government Research dg.o 2010 (published by ACM), May 17-20, Puebla, Mexico,31 209-216. pp.
  32. 32. Going beyond the goldrush requires interdisciplinary collaboration in open networks of business, government and academia 32
  33. 33. Gezamenlijke onderzoeksvragen • Mogen we wel informatiedelen (privacy)? • Hoe weet je dat de informatie secure is? • De keten is afhankelijke van de zwakste schakel • Nieuwe type ‘business modellen’ ontstaan. Wie betaald de orchestrator? • Hoe omgaan met SLA’s? • Wie monitort en grijpt in? • Failliet en wat nu? • Hoe omgaan met onbekende partijen? • Wie is verantwoordelijk? Who is to blame? 33
  34. 34. Vragen en discussie Marijn Janssen m.f.w.h.a.janssen@tudelft.nl 34

×