For a successful cloud deployment, it is inevitable for businesses to determine the cloud deployment models that best suit their business requirements. A deployment model is classified based on how and by whom the cloud services are used.
Each cloud deployment model satisfies different organizational needs, and each has a different value proposition and different costs associated with it.
Therefore, deciding which deployment model you will go with is one of the most important cloud deployment decisions you will make. It will determine the number of things, such as where the deployment’s infrastructure resides and who controls the infrastructure.
This post will compare three cloud deployment models: public, private, and hybrid cloud.
- Public Cloud: This cloud infrastructure, owned by an organization selling cloud services, is available to the general public or large industry groups that include educational institutions, industries, government institutions, or businesses or enterprises.
- Private Cloud: This cloud infrastructure, operated solely for an organization, is exclusive for private use by the employees. Managed either by the organization or a third party, it may exist on-premise or off-premise.
- Hybrid Cloud: This cloud infrastructure comprises two or more clouds (private or public) that remain unique entities yet are bound together by proprietary technology enabling data and application portability.
1. Public Cloud
Criticality of cloud services: Public clouds are more appropriate for services that are not mission-critical and do not require access to sensitive information. They are more appropriate for organizations that do not have the resources to ensure the high availability of on-premises systems.
Type of workload: Public cloud is suitable for workloads that require access to high volume data (e.g., real-time analytics running against very large data stores), for workloads with highly variable load patterns, and for access to advanced services that may be difficult to implement on-premises.
Migration costs: Public clouds have low upfront costs for the use of cloud services. The implications are similar to the outsourced private cloud scenario, except that additional security precautions need to be considered.
Elasticity: Public clouds can generally be considered unrestricted in their size. Additionally, they can generally use multitenancy without being limited by static security perimeters, which allows a potentially high degree of flexibility in the movement of customer workloads to available resources.
Security threats: With a Public model, customers have limited visibility and control over security information. The details of provider system operation are usually considered proprietary and not available for examination by customers. The certification of cloud services often provides a level of assurance to customers.
Multi-tenancy: With a typical Public model, a single physical machine may be shared by any combination of customers’ workloads. In practice, this means that a customer’s workload may be co-resident with the workloads of competitors. This introduces potential reliability and security risks, though the evolution of technology and practices have helped reduce both.
Compliance: Many public cloud services are explicitly certified for compliance with one or more standards and/or regulations. It is necessary to select cloud services with appropriate certifications – or cloud services which the customer can get certified appropriately.
Environment portability: Organizations need to investigate portability and minimize vendor lock-in risk before they proceed with deployment on public clouds.
Disaster Recovery/Failover: Many large cloud service providers have multiple data centers worldwide and provide DR and failover options with standardized and documented procedures.
2. Private Cloud
Criticality of cloud services: Private clouds are appropriate for mission-critical applications and sensitive compliance services necessary for business continuity. Critical data availability is key to deciding whether to keep the workload on-premise.
Type of workload: Private on-premises may be preferable for applications that have very stringent latency requirements.
Migration costs: With a Private deployment model, installing and managing cloud software may incur significant cloud software costs even if non-allocated hardware exists within a consumer organization. Expenses may be mitigated if the organization has adopted a service-oriented architecture environment and moves to an expense formula for internal departments.
Elasticity: With Private (On-premise), finite resources are available since computing and storage capacity is fixed and have been sized to correspond to anticipated workloads and cost restrictions. If an organization is large enough, it may provide enough elasticity to clients within the consumer organization.
Security threats: With Private (On-premise), consumers have the option of implementing appropriately strong security to protect resources against all external threats to the same level of security that can be achieved for non-cloud resources.
Multi-tenancy: With Private, risks are mitigated by restricting the number of possible attackers: all clients would typically be members of the customer organization or authorized guests or partners.
Compliance: Organizations using an on-premise model typically have more control and more responsibility in ensuring compliance with various industry and government standards (HIPAA, GDPR, etc.) since they control the entirety of the infrastructure.
Environment portability: For on-premise deployments, portability is unlikely to pose a significant challenge.
Disaster Recovery/Failover: Depending on the organization’s size and maturity and the nature of the application, DR and failover provisioning might involve high costs and workload. It might require multiple physically separated data centers, for example.
3. Hybrid Cloud
Criticality of cloud services: Hybrid deployments help take advantage of public cloud features for certain non-critical workloads while retaining business-critical data and applications on-premise.
Type of workload: Cloud bursting of on-premises core business capabilities during a seasonal surge is an example; replicating selected customer information to a lightweight cloud database for quicker access by mobile apps is another.
Migration costs: Hybrid deployments, by definition, are transitory between private and public, and hence a point in migration to/from the public cloud. Costs can be controlled based on need and maturity.
Elasticity: Hybrid deployments typically include a component of public cloud services; availability of resources is only limited by acceptable security limitations.
Security threats: Organizations utilizing Hybrid deployments can choose to limit the kind of data/services exposed to the public, thus helping mitigate threats.
Multi-tenancy: Multi-tenancy on the public part of a Hybrid cloud can be limited to either periodic use (bursting) or by exposing limited information/services to the public cloud. Sensitive and mission-critical areas can still reside on-premises to minimize risks.
Compliance: Hybrid deployments help organizations stay compliant by providing the customer with the ability to choose the environment most suitable for compliance requirements – on-premises or public cloud. Care needs to be taken, however, to ensure compliance where solutions transition between the two.
Environment portability: Portability is typically an issue with the public cloud part of a Hybrid deployment. In addition to avoiding potential vendor lock-in, organizations need to ensure access via API and a streamlined integration approach to all applications/infrastructure.
Disaster Recovery/Failover: Organizations might choose to leverage the public cloud to act as a failover option for their internal applications or disaster recovery, but they need to ensure regular synchronization between on-premises and public cloud systems.