Key Considerations for Designing Cloud Applications: Scalability, Availability, Manageability, and Feasibility

When designing applications for the cloud, it is useful to start discussions around four specific topics: scalability, availability, manageability, and feasibility . These topics serve as a starting point for detailed, long‑term conversations with stakeholders, aiming to produce an initial to advanced design and architecture that considers trade‑offs and side effects.

1 Scalability

Discussions on scalability should focus on the need to add capacity to the application and its services to handle increased load and demand. Key areas include:

Capacity

Do we need to scale a particular application layer, and if so, how can we do it without impacting availability?

How quickly must we be able to scale an individual service?

How will we add extra capacity to the application or any of its parts?

Does the application need to run at 24×7 scale, or can we scale down outside business hours or on weekends?

Platform / Data

When working at large scale (database size, transaction throughput, etc.), can we stay within the constraints of the chosen persistence service?

How can we partition data to help scalability within persistence platform limits (e.g., max database size, concurrent request limits)?

How do we ensure efficient use of platform resources? In practice, many prefer many small instances over a few large ones.

Can we minimize internal network traffic and resource usage while maintaining scalable, future‑proof code?

Load

How can we improve design to avoid contention and bottlenecks (e.g., using queues or service buses between producers and consumers)?

Which operations can be handled asynchronously to balance peak‑time load?

How can we use platform features for rate‑limiting (e.g., Azure Queues, Service Bus)?

How can we use platform features for load‑balancing (e.g., Azure Traffic Manager, load balancers)?

2 Availability

Availability describes the ability of a solution to run in a useful way for consumers despite temporary or permanent failures in the application, OS, network, or hardware. Topics to cover include:

Uptime Guarantees

What service‑level agreements (SLAs) must the product meet?

Can we meet those SLAs with the cloud services we plan to use? Remember, SLAs are composite.

Replication and Failover

Which parts of the application are most prone to failure?

Which parts are most impacted when a failure occurs?

Which components would benefit from redundancy and failover options?

Is a data replication service required?

Are we limited to specific geographic availability zones, and are all services we plan to use available there?

How do we prevent corrupted data from being replicated?

Will recovery from failure place excessive pressure on the system? Do we need retry strategies or circuit breakers?

Disaster Recovery

If a catastrophic failure occurs, how do we rebuild the system?

How much data loss is acceptable in a disaster‑recovery scenario?

How will we handle backups? Do we need backups in addition to data replication?

How do we handle in‑flight messages and queues after a failure?

Are we idempotent? Can we replay messages?

Where are our VM images stored and are they backed up?

Performance

What is an acceptable performance level and how do we measure it? What happens if we fall below it?

Can any part of the system be made asynchronous to improve performance?

Which parts of the system compete most intensely, potentially causing performance issues?

Are traffic spikes likely, and can we auto‑scale or use a queue‑centric design to mitigate them?

Security

Key cloud‑related security questions include:

What local laws and jurisdictions govern data storage, including fail‑over and metrics data?

Is federated security (e.g., ADFS with Azure AD) required?

Is this a hybrid‑cloud application, and how do we protect the link between corporate and cloud networks?

How do we control access to the cloud provider’s management portal?

How do we restrict other services (e.g., IP‑whitelisting) from accessing databases?

How will we handle regular password changes?

How do service decoupling and multi‑tenancy affect security?

How will we manage OS and vendor security patches and updates?

3 Manageability

This topic covers understanding the health and performance of a live system and the ability to operate the site. Cloud‑specific considerations include:

Monitoring

How do we plan to monitor the application?

Will we use a ready‑made monitoring service or build our own?

Where will monitoring/metric data be physically stored, and does this comply with data‑protection policies?

How much data will our monitoring plan generate?

How will we access metric data and logs, and can we keep them available as volume grows?

Is auditing and logging required?

Can we tolerate loss of some metrics/logs/audit data (e.g., “fire‑and‑forget” design) to improve performance?

Do we need to change monitoring levels at runtime?

Do we need automatic anomaly reporting?

Deployment

How will we automate deployments?

How can we patch or redeploy without interrupting a live system while still meeting SLAs?

How will we verify that a deployment succeeded?

How will we roll back unsuccessful deployments?

How many environments (dev, test, staging, production) are needed and how will we deploy to each?

Does each environment require separate data storage?

Does each environment need 24×7 availability?

4 Feasibility

When discussing feasibility, we consider the ability to deliver and maintain the system within budget and time constraints. Points to explore include:

Can we meet the required SLA (e.g., uptime guarantees from cloud providers)?

Do we have the internal skills and experience to design and build a cloud application?

Can we build the application within budget and a business‑meaningful timeline?

What operational costs will we incur (cloud pricing can be complex)?

What scope, SLA, or resilience can we wisely reduce?

What trade‑offs are we willing to accept?

5 Conclusion

Considering these four topics—availability, scalability, manageability, and feasibility—helps identify areas that require cloud‑specific thinking early in a project. The listed items are not exhaustive but provide a solid discussion starting point.