Cloud Application Lab

Offerings

• Agile (micro-)service modeling and rapid API prototyping

• Evaluate cloud-native application properties and support assessment of cloud migration readiness

• Develop criteria for cloud provider evaluations and comparisons

• Help graduate project experience to architectural knowledge (design principles, patterns, decision models)

• Software engineering, covering all phases from initial requirements engineering and design to deployment and evolution

Cloud Design and Architectural Refactoring (CDAR) Approach

• Develop new applications and partially re-engineer existing ones – and deploy them to selected cloud offerings (in varying configurations)
  • Different applications deployed and run:
    • Spring Boot, JS2E and JEE enterprise applications (of varying complexity), e.g. Self Information, Domain-Driven Design (DDD) Sample Application. Another sample application is Lakeside Mutual.
    • Spring MVC, ActiveMQ, WSDL/SOAP, JDBC, MongoDB, …
    • Probe applications, e.g. system self information, network connectivity
  • 10+ public Platform-as-a-Service PaaS clouds investigated (in multiple iterations) 
    • List of evaluated providers updated annually (since 2013)
• Scoring of Patterns of Enterprise Application Architecture and other pattern languages regarding their cloud affinity and suitability
• SWOT tables for selected PaaS offerings and Cloud Design Guidance Model; SLA checklists

Selected CDAR evaluation criteria:

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"). See our blog post on seven defining traits of cloud-native Applications.
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?
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.

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.