Software that runs on rented virtual servers hosted in large remote data centers.
A cloud is a large pool of remote virtual servers available for rent. Servers are implemented in software and started/stopped on demand. Customers rent servers, access them over the internet, install required software, and use them.
Characteristics
Three defining properties:
- Scalability
Ability to maintain performance as user load increases, achieved by automatic adaptation. - Elasticity
Superset of scalability; supports both scale-out and scale-in, with servers added or removed dynamically. - Resilience
Ability to maintain service when a server fails, achieved by running concurrent software copies.
Architecture Decisions
3 interdependent architectural decisions:
- Database organization: multi-tenant or multi-instance?
- Scalability and resilience: what are the load and fault-tolerance requirements?
- Software structure: monolithic or service-oriented?
Database Organization
Decision factors:
| Factor | Favors multi-instance if… |
|---|---|
| Target customers | Customers need different schemas or have DB-sharing security objections. |
| Transactions | ACID guarantees required at strong consistency. |
| DB size/connectivity | Many different customer schemas; complex inter-schema data transfer. |
| System structure | Service-oriented architecture in use: use containerized multi-instance DBs. |
Multi-tenant preferred for very large, uniform databases where optimization effort is centralized.
Scalability
Scaling out
Add more server replicas. Normal approach in cloud systems. Software components must be stateless and replicable, runnable in parallel.
Scaling up
Increase power of existing server. Less common.
Resilience
Resilience via redundancy:
- Software and data replicas at multiple physical locations.
- Database mirroring: standby DB kept in sync with operational DB.
- System monitor: detects failures and triggers automatic failover to standby.
3 standby configurations.
Hot standby
Backup powered on and running in parallel with the primary. Immediate failover.
Cold standby
Backup offline until needed. Slowest recovery, lowest resource cost.
Warm standby
Backup in a low-power ready-to-operate state. Faster switching than cold standby, lower energy use than hot standby.
Software Structure
Monolithic Architecture
Large components, shared database, client-server model. Traditional multi-tier structure.
Strengths:
- Simple to develop and deploy initially.
- Easier testing and debugging: all code runs in one process.
- Lower operational overhead.
- Better performance due to in-process method calls.
- Suited to small and medium-sized systems.
Microservices Architecture
Aka. service-oriented architecture. System decomposed into fine-grained, stateless services. Each service independently replicable, distributable, and migratable. Suited to cloud deployment. Each service runs in containers.
Strengths:
- Independent deployment per service.
- Per-service scalability rather than scaling the whole application.
- Fault isolation limits the blast radius of failures.
- Teams can develop and release services independently.
Polyglot development
Where each service can use a different language or runtime.
Cloud Platform Selection
No universally best platform. Selection based on context.
Types of platforms:
- General-purpose (AWS, Azure, GCP).
- Application-specific (SAP Business Technology Platform).
- Smaller national providers: fewer services, more customer adaptability.
Technical selection factors:
- Expected load and load predictability.
- Resilience guarantees.
- Supported cloud services (databases, queues, auth).
- Privacy and data protection compliance.
Business selection factors:
- Cost.
- Developer experience with the platform.
- Target customer expectations.
- Service-level agreements.
- Portability and cloud migration risk.