Cloud architectures are akin to the designs and blueprints of a building, informing engineers and construction crews where certain components are, how systems are threaded throughout the larger infrastructure, and offers a means for understanding the whole system in detail that can be shared and referenced. In much the same way as building designers, cloud architects begin with a use case and then architect a system to meet the needs that support that use. Then they will pull together the server components, networking infrastructure, and application software that will compose the physical infrastructure, and create the cloud virtualizations served to its users. In this analogy, like every building, each cloud architecture is unique though they’re made of standard materials. Clouds can be constructed for personal use, or for public use—like homes or stadiums, each requires a cloud architecture design suited to its purpose.
Before architecting a cloud solution, organizations need to perform a comprehensive requirements analysis, and answer the basic question of “what do we need this cloud to do for us?” Cloud architects must consider in their designs: user and business requirements, compliance requirements, cloud security requirements, and budgetary requirements. Careful reflection and planning can lead to useful specifications like user requirements documents (URD), and business requirement documents (BRD), which are helping in guiding the new cloud system. In one way, these documents can be used to map requirements against multiple cloud-vendor capabilities to determine appropriate solutions.
When considering compliance and security requirements include the following sub-concerns:
- Compliance Concerns: Data Retention, Encryption, Vulnerability Management, Auditing, and Privacy.
- Security Concerns: Authentication, Log Management, Patch Management, Privileges, Access Control, and System Hardening.
After compiling the requirements for the new cloud architecture, cloud engineers can begin designing a solution based on those requirements. The solution design should include security design, technical design, integrations, and acceptable downtime.
- Security Design — The aim of security design is to answer what level of security is required, and how to implement that level (e.g., using tools like two-factor authentication, encryption, etc.). To begin, identify the data flows in the system, and how that data is secured using a data flow diagram. Data flow diagrams depict the flows and types of data and their level of encryption from point to point. Also consider how the system is segmented, and if that configuration introduces vulnerabilities or removes them. This can mean installing firewalls in-between web, data, and storage layers.
- Technical Design — The technical design outlines the resources and services—software, hardware, network, routing and subnets—used to comprise the system. For software, think about which functional technologies, security controls, and licenses will be used. If the cloud will be deployed on-premises, then hardware is a concern, otherwise, deploying to the public cloud normally beneficially removes the need to think in detail about hardware resources since they are managed in the cloud. Networking, routing, and subnetting are important considerations for system performance and security. Poor segmentation can add vulnerabilities, poor routing can cripple system performance and availability. Design for redundancy and expect failures.
- Integrations — Cloud components are integrated and do not run in isolation. Ineffective designs can introduce bottlenecks, dependencies, and dead ends that develop into long-lasting problems for network admins and developers as systems grow. Understanding how components integrate, especially data flows and authentication domains, is important to ensure the cloud system remains resilient and functioning.
- Downtime — Adopting new cloud architectures, or performing regular cloud maintenance usually results in some downtime which can be planned for, either through redundant systems, or scheduling. (Minimizing downtime is a crucial business objective, e.g. tier 4 classified data centers are defined by a 99.995% annual uptime, allowing only a few minutes of downtime per year providing maximum availability.) While at first, this may be less of a concern for budding clouds, downtime ultimately impacts business goals, and if the cloud is supporting revenue generation, any system downtime is money out the door.
Cloud architectures support the implementation designs of several different types of cloud service models. The main benefit of cloud architecture is the ability to effectively and efficiently supply these services and shared resources to multiple users across the globe. Cloud service models are IT-related services that provide particular cloud services under pre-defined mutually agreed service level agreements (SLA). Popularly there are three types of service modes, Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS), and Software-as-a-Service (SaaS). However, the concept of XaaS, anything-as-a-service, extends cloud service models to virtually any aspect of IT and delivers those services via the Internet.
- Infrastructure-as-a-Service — In this model, CSPs outsource IT infrastructure aspects, hardware, networking, and OS. Cloud consumers can follow this path when scaling is their primary objective, but do not want the burden of maintaining the physical infrastructure themselves beyond paying for it.
- Platform-as-a-Service — PaaS enables cloud consumers the ability to deploy their applications without the need to manage their own back-end. The CSP provides the development platform on top of the infrastructure they manage, including dev tools, databases, APIs, and programming frameworks.
- Software-as-a-Service — SaaS is a common and helpful cloud application. SaaS apps are typically accessed via a web browser, where the UI abstracts the business layer away from the underlying technologies for the end-user. These apps are designed for end-use, like a web email system, CRM, ERP, community, etc.
The physical components and user interface are the most visible parts of a cloud system, but cloud architecture encompasses more. In the most general sense, cloud architects concern themselves with the following categories:
- Back-end Hardware — The physical components that support cloud services are CPUs, disk storage, memory, storage networking, and connectivity components like routers and cabling. Businesses may also want to include the components that support the system hardware, like server racks, cooling equipment, lighting, which can help them understand overall costs.
- Middleware — Middleware is the software used to create connections between other components on the network, acting as a communications intermediary. In the cloud, middleware also abstracts the hardware adding a layer of virtualization that gives clouds their characteristic multiple environments on shared resources. This is a broad definition, but examples include web servers, hypervisors, application servers, database servers, or transaction-processing monitors, and more.
- Front-end Interface — Front-end interfaces come in GUI or a console form, though clouds tend to promote GUI interfaces. While cloud architects need to consider the technology that supports the front-end designs and workings, including an experienced UX designer to develop the interface helps bridge the gap between the system and the user.
- Management Software — Cloud management software assists cloud providers to monitor and control multiple cloud deployments, resources, and services. These packages are used to orchestrate the virtual environment, optimize cloud deployments, and potentially understand costs.
- Automation Software — Highly associated with cloud deployments, automation software coupled with virtualization technology has been the enabler that makes the public cloud a reality. When an organization's cloud services grow, serving more users, and more environments, many of these tasks will pile up, completing them manually is time-consuming, and error-prone. Enter automation software to delegate those responsibilities.
Cloud deployment models articulate how cloud services models (IaaS, PaaS, SaaS, or any XaaS) will be implemented in relation to business requirements, whereas the service models are implementations serving the cloud consumers. There are two main cloud deployments: private, and public. Hybrid and multi-cloud deployments are combinations of those two main deployments. The following describes each:
- Private Cloud Deployment Model — Private clouds are owned by a single company, enabling centralized access to cloud resources behind the protection of a company firewall. Private clouds offer the same functionality as public clouds, with the added responsibility of maintaining the infrastructure that supports the cloud resources made available to departments and staff. This is called their private cloud space (PCS), and while it grants maximum control and cloud security, it does not produce the same return on investment as using public resources.
- Public Cloud Deployment Model — Public clouds are cloud services that are available over the Internet. Google, Azure, and AWS are some of the most popular CSPs. Public clouds are exceptionally attractive because they can leverage their efficiency from economies of scale, distribute their wins to all their users, and charge based on pay-as-you-go schemes. Public clouds provide cloud consumers virtually unlimited resources, without the burden of managing and funding an on-premises IT department.
- Hybrid Cloud Deployment Model — Sometimes circumstances require bridging both private and public cloud deployment models, for instance, compliance standards may require companies to retain customer’s personally identifiable information (PII) in a sanctioned geographic boundary, by hosting that information on a private cloud while servicing users from public resources, companies may be able to satisfy compliance requirements. Compliance is not the only driver for hybrid clouds, but the defining characteristic to be considered a hybrid cloud is that data moves between public and private clouds.
- Multicloud Deployment Model — Multicloud is a combination of multiple public cloud service providers. These scenarios arise for several reasons: one CSP simply does not have all the best cloud components, but by combining multiple vendors, the desired system can be achieved; a company seeks service redundancy and diversification across multiple vendors to avoid vendor lock-in, or avoid single points of failure. Further, multi-cloud deployments can also include private clouds, making it a hybrid and multicloud configuration, but to remain multicloud it still must contain two or more public clouds.
Managing the cloud, or cloud governance also must be considered during cloud architecture planning. The following six principles for cloud governance provide a framework for cloud architects.
- Data Management — The data lifecycle needs to be organized, consider data classification, access controls, encryption, long-term storage, and retirement.
- Security and Compliance Management — A progressively more complex area in the cloud, security and compliance concerns risk, privacy, identity and access management (IAM), application security, data encryption, and contingencies.
- Financial Management — While the cloud allows for great cost flexibility and control, these factors must be monitored and budgeted. Financial management uses policies, reports, controls, and alerts, to assist in understanding cloud usage.
- Operations Management — Operations encompasses the tasks of keeping systems up and maintaining service-level agreements. This requires monitoring the state of the cloud, how the technologies interact, and managing the resources for applications and new code deployments.
- Performance Management — Performance management monitors application, and infrastructure resources at a granular level to understand performance and optimize the system.
- Asset and Configuration Management — Automation can help to keep an accurate and up-to-date inventory of assets and devices, as well as be able to push configuration changes to those devices. Additionally, there must be a way to securely control and store keys and secrets.
Cloud platforms are designed to make deployments and the worries over managing and securing them easy. Below are some of the top cloud service vendors that provide solutions for many standard and custom deployments. Many share the same features, and capabilities, but technologies do differ, so, it is always advisable to perform a comprehensive requirements analysis and compare multiple vendors to find the right fit.
- Amazon Web Services (AWS)
- Microsoft Azure
- Google Cloud Platform
- IBM Cloud
- Huawei Cloud
- Oracle Cloud
