Institute for

Cloud Design and Architectural Refactoring Lab (CDAR)

Evaluation of PaaS Offerings from an application architecture viewpoint



  • Develop criteria for public Platform-as-a-Service (PaaS) comparison/evaluations
  • Harvest architectural knowledge from gained experience
  • Support cloud evaluations and readiness assessments


  • Develop new applications and partially reengineer existing ones – and deploy them to selected cloud offerings (in varying configurations)

    • 10+ public Platform-as-a-Service PaaS clouds investigated (in multiple iterations)  

      • List of evaluated providers updated anually (since 2013)

    • Different applications deployed and run:

  • Scoring of Patterns of Enterprise Application Architecture and other pattern languages regarding their cloud affinity and suitability; SLA checklists
  • SWOT tables for selected PaaS offerings and Cloud Design Guidance Model


Selected CDAR evaluation criteria (subset):

  1. Support for defining cloud characteristics: on demand, self service, scalable, measured ("OSSM") and architetcural principles such as isolated state, distribution, elasticity, automated management, loose coupling ("IDEAL")
  2. Billing model and Service Level Agreements (SLAs): Accountability of provider, penalties/refunds, customer obligations
  3. Physical location (of data)
  4. Country/place of jurisdiction (CH/EU/other)
  5. Service scope: Support for cloud computing patterns? Platform middleware versions? Can main programs (batch jobs) be run? Can JEE EARs be deployed?
  6. Deployment process and tools; standardization
  7. User/programmer documentation incl. getting started information
  8. Cloud services lifecycle, e.g. hibernation due to inactivity/restart time?
  9. Operational model (runtime topologies): inbound traffic, outbound traffic, cloud-internal communication
  10. Domain and port management capabilities for user
  11. API security and VPN support
  12. Cloud service management capabilities


CDAR recommendations (design and deployment best practices):

  1. Avoid calls to proprietary platform libraries (e.g., via JNI).
  2. Limit usage of expensive operations, e.g. SecureRandom in Java SE.
  3. Do not define resource identifiers such as IP addresses statically.
  4. Prefer HTTP over raw socket communication even for cloud-internal integration (or use messaging capabilities offered by cloud provider).
  5. Do not expect cloud messaging to have the same semantics and QoS as traditional messaging systems (at-least-once vs. exactly-once delivery).
  6. Do not expect NoSQL storage to provide the same level of programming and database management convenience as mature SQL database systems.
  7. Do not expect cloud provider to handle backup and recovery of application data for you.
  8. Be prepared to log resource consumption on same level of detail as provider (in case bill from provider contains suspicious items)


Lab results and related projects

Selected architectural patterns, decisions and principles in cloud design are featured in this OOP presentation (slides). See website of Architectural Refactoring for Cloud (ARC) project for more CDAR results as well as links to Cloud Knowledge Sources. Our cloud solutions blog (in German) can be found here.


The MAP website collects advice regarding microservice API design (and other aspects of cloud-native application design) in the form of design patterns. Two such patterns are Rate Plan and Service Level Agreement.  


Contact Mirko Stocker or Olaf Zimmermann if you are interested in the CDAR lab activities.