Zootnet Ltd - An IT Architectural Practice
Cloud architecture: choosing the right model for the job
Cloud computing is where your business really begins to scale. With the right strategic approach a company can grow from hundreds of business transactions per day to millions. The key decision is how much of the technology stack you want to run yourself, and how much you want to consume as a service.
The three service models
Every cloud service sits somewhere on a spectrum of control versus convenience. IaaS gives you the most control, SaaS the least, and PaaS sits between them. Moving up the stack hands the provider more of the operational burden, so your team can spend its time on business workflows rather than the plumbing underneath them.
Infrastructure as a Service
The provider supplies virtualised compute, storage and networking on demand. You build and manage everything from the operating system upward, exactly as you would on your own servers, without owning the hardware or the datacentre.
Typical examples
Azure Virtual Machines, Amazon EC2, Google Compute Engine, virtual networks, block and object storage.
Best suited to
- Lift-and-shift migration of existing workloads
- Legacy or licensed software that needs a specific OS or configuration
- Bursty capacity, test environments and disaster recovery
Watch out for
- You still patch, secure and monitor the OS and everything above it
- Costs creep up if idle machines are left running
Platform as a Service
The provider also manages the operating system, runtime and scaling. You deploy your code and configuration, and the platform takes care of hosting, patching, load balancing and availability.
Typical examples
Azure App Service, AWS Elastic Beanstalk, Google App Engine and Cloud Run, managed databases, managed Kubernetes.
Best suited to
- New web applications and APIs
- Teams that want to ship features, not manage servers
- Elastic workloads that scale automatically with demand
Watch out for
- Platform limits and supported runtimes shape your design
- Some vendor tie-in, which good integration design can reduce
Software as a Service
A complete application delivered over the internet, usually by subscription. The provider runs everything; you configure it, manage your users and decide what data goes into it.
Typical examples
Microsoft 365, Google Workspace, Salesforce, Dynamics 365, Xero, Slack, ServiceNow.
Best suited to
- Commodity business functions such as email, CRM and finance
- Fast onboarding with little or no infrastructure
- Organisations without in-house operations teams
Watch out for
- Limited customisation and a fixed upgrade cadence
- Data export, integration and exit planning need attention early
Who manages what?
The shared responsibility model is the single most useful way to understand the differences. As you move from on-premises towards SaaS, the provider takes over more layers. Notice that your data, and who has access to it, is always your responsibility.
| Layer | On-premises | IaaS | PaaS | SaaS |
|---|---|---|---|---|
| Users, identity and access | You | You | You | You |
| Data | You | You | You | You |
| Application | You | You | You | Provider |
| Runtime and middleware | You | You | Provider | Provider |
| Operating system | You | You | Provider | Provider |
| Virtualisation | You | Provider | Provider | Provider |
| Servers and storage | You | Provider | Provider | Provider |
| Network | You | Shared | Provider | Provider |
| Physical datacentre | You | Provider | Provider | Provider |
Exact boundaries vary by provider and service, so always check the provider's own shared responsibility documentation.
Which model should you choose?
| IaaS | PaaS | SaaS | |
|---|---|---|---|
| Control | Highest | Moderate | Lowest |
| Operational effort | Highest | Moderate | Lowest |
| Speed to start | Hours to days | Minutes to hours | Minutes |
| Scaling | Configured by you | Largely automatic | Handled by provider |
| Typical billing | Per resource, per hour or second | Per plan or per usage | Per user, per month |
| Choose it when | You need OS-level control or are migrating existing servers | You are building or modernising your own applications | A packaged product already meets the need |
Most real organisations use all three at once: SaaS for productivity and CRM, PaaS for customer-facing applications, and IaaS for the workloads that are not yet ready to change. The architecture challenge is making those pieces work together, which is why integration strategy matters so much.
Modern cloud-native building blocks
The three classic models are now complemented by a set of architectural approaches that sit across them.
Containers and Kubernetes
Packaging an application with its dependencies makes it portable between laptop, datacentre and cloud. Managed Kubernetes services (often called Containers as a Service) reduce the effort of running clusters while keeping workloads portable.
Serverless and Functions as a Service
Code runs only when triggered and you pay for execution rather than idle capacity. Ideal for event-driven tasks, APIs and background processing, such as Azure Functions, AWS Lambda and Google Cloud Functions.
Microservices and event-driven design
Breaking a large system into small, independently deployable services lets teams release faster and scale only what needs scaling. Messaging and event streaming keep those services loosely coupled.
Managed data and AI services
Databases, analytics platforms and machine learning services are now available as fully managed offerings, removing much of the administration and bringing advanced capability within reach of smaller businesses.
Hybrid and multi-cloud
Combining on-premises systems with one or more public clouds lets you place each workload where it makes most sense for cost, latency, resilience and regulation. See our on-premises guidance.
Infrastructure as code and DevOps
Defining environments in version-controlled templates and deploying through automated build and release pipelines makes change repeatable, auditable and fast.
Principles behind a sound cloud architecture
The major providers publish well-architected frameworks, and they converge on the same themes. We use them as a checklist when reviewing or designing a solution.
- Security first. Strong identity, least-privilege access, encryption, and a zero-trust approach to networks.
- Reliability. Design for failure with redundancy, backups and tested recovery.
- Performance efficiency. Match resources to demand and scale automatically where possible.
- Cost optimisation. Right-size, shut down what is idle and track spend with FinOps practices.
- Operational excellence. Monitoring, automation and continuous improvement.
- Sustainability. Efficient use of resources reduces both cost and environmental impact.
- Compliance and data residency. Know where data lives and which regulations, such as UK GDPR, apply to it.
Read more in the Azure Architecture Center, AWS Well-Architected Framework and the Google Cloud Architecture Framework.
Ready to plan your cloud journey?
Zootnet Ltd can help to ensure your supporting infrastructure is ready to enable cloud workloads, so you can concentrate on developing the workflows rather than the underlying code that delivers them.