Cloud Deployment Models

Defines
- where your data is stored
- how your customers interact with it – how do they get to it
- where do the applications run?
Choose depending on your budget, and on your security, scalability, and maintenance needs.
- E.g. how much of your own infrastructure you want or need to manage.

Public cloud

Most common deployment model
No local hardware to manage or keep up-to-date, everything runs on your cloud provider’s hardware.
Save additional costs by sharing computing resources with other cloud users.
Can use multiple public cloud providers of varying scale.
Example use case
- Deploy a blog / web application quickly wihout worrying about purchasing, managing or maintaining the hardware on which it runs.

High scalability/agility: you don’t have to buy a new server in order to scale
Pay-as-you-go pricing: you pay only for what you use, no CapEx costs
You’re not responsible for maintenance or updates of the hardware
Minimal technical knowledge to set up and use: you can leverage the skills and expertise of the cloud provider to ensure workloads are secure, safe, and highly available

Specific security requirements that cannot be met by using public cloud
Government policies, industry standards, or legal requirements which public clouds cannot meet
You don’t own the hardware or services and cannot manage them as you may want to
Unique business requirements, such as having to maintain a legacy application might be hard to meet

Cloud environment in your own datacenter
Provide self-service access to compute resources to users in your organization.
A simulation of a public cloud to users, but you remain completely responsible for the purchase and maintenance of the hardware and software services you provide.
Users can be external customer or specific internal departments such as Accounting or Human Resources.
Example use case
- Have data that cannot be put in the public cloud e.g. because a government policy requires specific data to be kept in-country or privately.

Initial CapEx costs & must purchase the hardware for startup and maintenance
Owning the equipment limits the agility - to scale you must buy, install, and setup new hardware
- Private clouds require IT skills and expertise that’s hard to come by

Combines public and private clouds, allowing you to run your applications in the most appropriate location.
Helpful when you have some things that cannot be put in the cloud, maybe for legal reasons.
Example use cases
- Host a website in the public cloud and link it to a highly secure database hosted in your private cloud (or on-premises datacenter).
- Some specific pieces of data that cannot be exposed publicly (such as medical data) which needs to be held in your private datacenter.
- An application that run on old hardware that can’t be updated. Keep the old system & connect it to the public cloud for authorization or storage.

Keep any systems running and accessible that use out-of-date hardware or an out-of-date operating system
Have flexibility with what you run locally versus in the cloud
- Easier migration to Azure
- Cloud-bursting: Use cloud when your compute resources are not enough
- Pass data back and forth: Process part of your data in cloud, part of it on-premises.
Take advantage of economies of scale from public cloud providers for services and resources where it’s cheaper, and then supplement with your own equipment when it’s not
Use your own equipment to meet security, compliance, or legacy scenarios where you need to completely control the environment

More expensive than selecting one deployment model since it involves some CapEx cost up front
More complicated to set up and manage