- 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.
- 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.
- Ensure the configuration can support any scenario or legacy application
- Control (and responsibility) over security
- Meet strict security, compliance, or legal requirements
- 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