Successfully reported this slideshow.

Koen Handekyn - Variability in the Cloud


Published on

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

Koen Handekyn - Variability in the Cloud

  1. 1. iMinds 2011Variability in the Cloud Multi-tenancy vs Virtualisation
  2. 2. AgendaUnifiedPostThe Challange: Service Product Lines in a Cloud ContextArchitectural VariationsApplication Level Multitenancy challangesProject Results
  3. 3. UnifiedPostSpecialized in the optimizationof inbound and outbounddocument flows.  Standard and Tailor-made solutions in a transactional Software-as-a-Service model  Offering both paper, electronic and hybrid solutions  >10 years experience in the SAAS world with a growth at 40% per year Moving from ASP to PaaS puts higher further stresses the importance of efficiently handling variations points and customer driven engineering (CDE)
  4. 4. ThomsonReuters: worldwide solutionPrint, e-invoice, e-archivingStarted in 2003>1.000.000 invoices per year, presenting a revenue of around 20 billion poundInvoices towards 120 countries via distributed printingSupport SOX control workflow logicE-invoice roll-out to 50 countriesMerger Thomson and Reuters: UP gets all the Thomson invoices
  5. 5. Thomson-reuters
  6. 6. MultiTenant Platform Overview refers to a principle in software Community Convert Receive Receive Archive Render SocSec architecture where a single instance of Closed Portal Send Send Send Sign CAS Pay UP UP UP UP UP UP the software runs on a server, serving multiple client organizations (tenants). Solutions Services Docstore DocFlow: [receive] User Manager: Multi is contrasted with a multi-instance architecture batch processing Input Channels Alexandria Temp Identity, SSO Space auth. model Static Content where separate software instances (or ReatTime Doc Services [send] Output Channels Resource Mngmnt Docs: Triples List, Actions, hardware systems) are set up for different Realtime Payment [offline payments] SQL Distributed Hash Workflow Services Payment Channels client organizations. With a multitenant architecture, a software application is Core Services Processing Channels Persistence App designed to virtually partition its data and & Service Platform & Connectors & Streaming Platform configuration, and each client organization Foundation Middleware works with a customized virtual application Development : Operations : Business Intelligence instance. Support Components is also regarded as one of the essential attributes of Cloud Computing.[ wikipedia ]
  7. 7. Levels of SaaS Multinenancy Maturity• Level 1 - Ad-Hoc/Custom: At the first level of maturity, each customer has its own customized version of the hosted application and runs its own instance of the application on the hosts servers. Migrating a traditional non-networked or client-server application to this level of SaaS typically requires the least development effort and reduces operating costs by consolidating server hardware and administration.• Level 2 - Configurable: The second maturity-level provides greater program flexibility through configurable metadata, so that many customers can use separate instances of the same application code. This allows the vendor to meet the different needs of each customer through detailed configuration options, while simplifying maintenance and updating of a common code base.• Level 3 - Configurable, Multi-Tenant-Efficient: The third maturity level adds multi- tenancy to the second level, so that a single program instance serves all customers. This approach enables more efficient use of server resources without any apparent difference to the end user, but ultimately comes up against limits in scalability.• Level 4 - Scalable, Configurable, Multi-Tenant-Efficient: The fourth and final SaaS maturity level adds scalability through a multitier architecture supporting a load-balanced farm of identical application instances, running on a variable number of servers. The provider can increase or decrease the systems capacity to match demand by adding or removing servers, without the need for any further alteration of applications software architecture.
  8. 8. From ASP to PAAS ASP SAAS SAAS Servers Servers PAAS Data Data IAAS IAAS IAAS Center Center Isolation Isolation Between Tenants Tenant / Services Provider / Platform Provider SLA SLA Towards Tenants Complex cascade from Tenant to Infrastructure
  9. 9. Development and deployment supportFor service line architecturesIn public and private cloud contextsBackground : A software product-line is “a set of software-intensive systems sharing acommon, managed set of features that satisfy the specific needs of a particular marketsegment or mission and that are developed from a common set of core assets in aprescribed way” – A Feature model is a compact representation of all the products ofthe Software Product Line (SPL) in terms of "features".Goals: Service Line Architecture: Family of related software services managed on behalf of a large customer base Service Line Platform: Development and cloud based execution platform supporting a service line paradigm
  10. 10. CUSTOMSS Challanges Automating configuration and deployment of customer- specific variations inside a public or private cloud context managing:  Functional variatons and conflicts  Security/Isolation  Resources/SLA: modelling, provisioning, monitoring  Quality: protect for erosion of software quality Do public cloud offerings support application level multi- tenancy ?
  11. 11. Solving Variability through Virtualisation+ Leverage existing software product line principles and deploy variations in an isolated way Tenant- Tenant-+ Easily monitor and bill resource usage (cpu hours, specific specific memory, bandwidth) service service instance instance+ Simplified Resource Provisioning+ Limited security riscs Middleware- Middleware- library v2 library v1+ Legacy applications easily portable to the cloud VM1 VM2- No resource sharing for features that are identical between CPU+Mem instances Shared DB- Coarse grained allocation of resources at application level Per tenant schema’s- “Open door” for “version hell”- Systems Administration requires advanced automation to be scalable- Operations and Support require extra tools to keep an overview- Architecture allows „non scalable solutions‟
  12. 12. Solving Variability through Application Level Multitenancy An architectural design principle for SAAS applications to enable the servicing of multiple customers (tenants) by a (logically) single application instance and code base Multi Tenant Service Instances+ Optimal use of resources through Multi-Tenant+ Fine grained allocation of resources at feature level Middleware+ Operations and support see one system VM1+ Simplified systems management CPU+Mem- Security becomes a core challenge Shared DB Single schema for all tenants- Non trivial monitoring of resource usage- Non trivial fine grained allocation of resources- Forced to think about scalability from the start- No migration path for legacy applications
  13. 13. GAE Experiment (KULeuven)with an on-line booking applicationDependency injection (DI) separates the management ofcomponent dependencies from the application code intoseparate modules and it enables tenant-specific softwarevariations.Each tenant is represented by 200 users who each execute abooking scenario. This booking scenario consists of 10 requeststo the application The performance overhead of using DI (Guice) is low. Less instances are created in the multitenant variant. Nr of CPU hours as measured by Google for billing purpose is close to equal allthough we expect the multitenant version to be more efficient. Instable behaviour from > 40 tenants (might be google protecting for overloadA), specifically more so for the multitenant variant
  14. 14. Reference Platform Architecture Java/.NET(KULeuven)JBoss AS 7 Open Source JBoss cluster (domain management, server groups...) JGroups (reliable multicast communication) mod_cluster (load balancer) Infinispan: distributed in-memory storage (cache, shared memory) Supports JEE 6  WS & RS (soa)  CDI (variablity) JBoss Modules & OSGi support (versioning) Async messages: JBoss HornetQRedHat OpenShift Very similar to our suggestion Amazon EC2 Not yet open source
  15. 15. Feature Placement (UGent) Question: Where to place application instances in clouds to ensure demand is met? Assumption to variability: use (multi-tenant) instances of features and create application linking instances using service-oriented architecture Integer Linear Programming (ILP): optimal but to slow. Can we find an efficient heuristic Solver based on first-fit algorithm? Yes, it seems …
  16. 16. Different feature conversions Server counts Feature Counts Application Counts