What Is Cloud Architecture?

What is cloud architecture?

So, what is cloud architecture? And what is cloud computing architecture? Cloud architecture and cloud computing architecture are the same. Both terms refer to the “blueprint” that defines the design of a cloud computing environment's infrastructure components.

There are several different ways to conceptualize cloud architecture. For example, from a cloud service provider’s perspective, cloud architecture consists of:

• A hardware layer that includes bare-metal servers, networking gear, and storage devices
• A virtualization layer that includes hypervisors and software-defined networking (SDN) components to virtualize physical resources 
• A services layer that includes the cloud resources the provider delivers to users 

In the minds of users like developers and DevOps engineers, cloud architecture components include:

• A front end, like a web console, application programming interface (API), command-line interface (CLI), mobile app, or other client, that enables access to the cloud service 
• A back end that provides the compute, storage, and software resources that enable the service 
• A network that provides connectivity between cloud resources and services like DNS resolution 

The role of a cloud environment’s architecture is to specify how all the components fit together and communicate. In Figure 1, we can see the architecture for a cloud-based document management system.

Is private cloud more secure than public cloud?

In general, private clouds offer two security advantages over public clouds.

1. Private clouds are dedicated to a single organization. 
2. Private clouds aren’t generally directly accessible over the public internet.

That’s why you’ll often see claims that private clouds are more secure than public clouds. In theory, and when the enterprises maintaining the private cloud apply security best practices in configuration and maintenance, that’s a reasonable claim. All else equal, the isolation of a private cloud is a security benefit. 

However, many organizations lack the in-house security expertise and resources to harden, patch, scan, and manage infrastructure with the same rigor as hyperscale cloud providers. An unpatched or improperly configured private cloud could be more insecure than a public cloud, and enterprises should take that into account when evaluating risk. 

The distinction between these three cloud computing service models is what the service provider and user are responsible for. Table 2 breaks down who controls the different aspects of cloud infrastructure with the different models.

IaaS platforms provide users with the most control and are the most complex to manage and maintain. Users are responsible for everything from selecting an operating system to patching. On the other end of the spectrum, SaaS platforms like Google Docs and Slack abstract away everything except the application layer. 

PaaS platforms provide a middle ground and give the user control of the application and data layer. For example, with a PaaS platform, you might have direct access to a MySQL database, but you won’t be responsible for patching the underlying MySQL version or operating system. 

Beyond IaaS, PaaS, and SaaS

IaaS, PaaS, and SaaS are only the beginning when it comes to cloud service models. The last decade has seen an explosion of new cloud service offerings that cover a wide variety of use cases. 

Here’s a breakdown of other cloud service models you should know.

• Authentication as a service (AaaS) platforms, like Okta and Duo, provide services such as multi-factor authentication (MFA) and single sign-on (SSO).
• Desktop as a service (DaaS) platforms, like Amazon Workspaces and Azure Virtual Desktop, provide managed virtual desktops in the cloud 
• Containers as a service (CaaS) offerings, like Google Cloud Run and Microsoft Azure Container Instances (ACI), streamline the process of deploying and managing containerized apps on a cloud platform
• Managed Kubernetes platforms like AKS and EKS provide hosted Kubernetes services for automated orchestration of Kubernetes clusters in the cloud 
• Serverless computing allows for an “on-demand” approach to compute resources that enables users to execute functions without managing any underlying infrastructure.

The benefits of cloud computing

Cloud computing is beneficial to both consumers and enterprises alike. The key benefits of cloud computing relative to traditional on-premises computing are:

• Managed infrastructure: Installing, configuring, and maintaining servers, switches, racks, power, and cooling equipment are expensive and time-consuming. Cloud services provide you with the business benefits of a solution, without the complexity of infrastructure management. 
• Elastic resources: Scaling your cloud usage up or down is trivial in a public cloud. This elasticity enables businesses to avoid bottlenecks so they can expand rapidly without the risk of overinvesting in hardware.
• Comprehensive observability: Often, cloud platforms come with observability tooling and dashboards included.
• Built-in best practices: Service providers are incentivized to strike the right balance of performance, security, and usability. And they can provide their customers with the benefits of economies of scale. As a result, users can benefit from infrastructure best practices just by using the right cloud platform. 

Migrating to a cloud architecture

Launching new projects in the cloud is one thing, but migrating existing workloads to the cloud is another. There’s no one-size-fits-all approach that will work for every use case, but there is a general set of principles and best practices you can use to help you get it right. 

• Make sure cloud migration makes sense: Not every workload needs to be a cloud workload. Create a business case that weighs the costs of cloud migration against the costs of decommissioning the workload altogether or leaving it on-premises. 
• Choose your cloud provider wisely: Features and cost are important, but they’re not the only parts of the equation. Consider nonfunctional requirements, support, service level agreements, and vendor reputation as you make your decision. 
• Select a service and deployment model that works for you: Public versus private cloud and IaaS versus PaaS versus SaaS come with different sets of trade-offs in control, functionality, and vendor lock-in. Evaluate the pros and cons before locking yourself into a model. For example, although it might seem logical to migrate your on-premises Exchange server to a comparable virtual machine on an IaaS platform, Office 365 email (SaaS) might be a better solution. 
• Keep your budgets in check: Cloud costs can add up fast. Most major cloud providers have cloud cost calculators you can use to get reasonable estimates and avoid surprises. Additionally, be sure to set up budget alerts whenever possible and keep a close eye on your statements. Implement a systematic approach for tracking costs to make sure you’re staying within your budget. 
• Always have a contingency: Backups, rollback plans, and pre-production testing can help mitigate the risk of data loss and downtime as you migrate to the cloud. Make sure to take a “measure twice, cut once” approach to critical workload migrations. 
• Consider the strangler fig application for complex monoliths: Lift-and-shift doesn’t work for everything. If your team needs to shift complex monolithic apps to the cloud, consider using the strangler fig application to gradually migrate to cloud-native microservices over time.

Conclusion

Cloud architecture is a complex topic, and there’s plenty more to learn. With what we’ve covered here, however, you should have a solid understanding of the basic what, why, and how of cloud computing.