How to Design a Hybrid Cloud Architecture

The the recent past, a hybrid cloud approach typically involved migrating some services from on-premises infrastructure to a public or private cloud, and these services communicating with each other. Even if a new application was built to be hosted on a public cloud, it adhered to a traditional service-oriented architecture (SOA).

But, today, microservices-based architecture is at the core of the hybrid cloud model. Microservices are an approach in which an application is broken into smaller components or services for easy deployment. These microservices differ from the services in SOA in that they have their own tech stack and are deployed in containers, which are lightweight executables that contain the microservice and its dependent libraries.

Containers are lightweight because they share the machine’s operating system (OS) kernel, meaning each container holds just the microservice and its dependencies. Any OS dependencies are shared from the hardware in which the container resides. This virtualization allows microservices to be independently deployable on any on-premises or cloud environment. And the self-sufficiency makes microservices much different from SOA and more suited for cloud deployment, wherein the need for elasticity and the flexibility to optimize cloud resources is paramount.

Containerization as a packaging model to isolate processes in any environment isn’t a new concept, but the emergence of Docker in 2013 as a container engine created a universal packaging structure. Further, a container orchestration platform like Kubernetes automates the deployment of Docker—or any other container that conforms to the Open Container Initiative (OCI) standards—across hybrid cloud environments.

The emergence of containerization has helped to truly tap into the benefits of hybrid clouds, with the focus shifting to easy portability of workloads and automatic deployment of services on the cloud environment of your choice.

A few years back, the key questions in a discussion on hybrid cloud architecture centered on which cloud or on-premises environment each workload should run and how to get these different environments to talk to each other. Essentially, the hosting location and physical connectivity remained the major considerations.

For example, an application that dealt with sensitive data would be hosted on a private cloud. Or a legacy app that’s difficult to modernize would continue to exist on-premises. Meanwhile, organizations would lift-and-shift the apps that need scalability to public cloud environments. Then, they would establish channels like virtual private network (VPN) tunnels or message streams to facilitate communication between environments.

These are still important factors to consider, but with the containerization paradigm, the focus has shifted from physical location and connectivity to flexibility in moving workloads seamlessly from one environment to another. So, whether to host an application in a private cloud or public cloud doesn’t have to be a rigid decision. If the strategy doesn’t work, it’s easy to move workloads packaged as containers across environments, scale up and down and even run instances of the same service in different environments.

All of this has led to a modern, highly available and flexible architecture that offers high performance, resource efficiency and cost savings.

The design and implementation of a hybrid cloud architecture needs to account for many factors, including the business objectives of an enterprise, its current technological landscape, digital transformation goals and security considerations. Since such an architecture with multiple hybrid cloud solutions could get complex really quickly, it’s important to leverage ops tools for centralized, seamless and scalable cloud management. Here are some factors to be considered while creating the hybrid cloud strategy.

Modernization strategy

For most organizations, the idea of hybrid cloud computing starts with modernization or moving their applications from on-premises to cloud, and there are a few ways to execute this:

• Lift-and-shift: One of the most common ways to kickstart modernization, lift-and-shift is moving the complete application off-premises to the cloud environment. This involves changing the underlying hardware to take advantage of the secure and scalable cloud computing resources and infrastructure services. It’s a convenient option when there is insufficient time to refactor or rearchitect.
• Refactor: Rather than moving the complete monolithic application to cloud—which is not only time-consuming but may also be unnecessary—it’s better to identify one or two services (something that doesn’t have compliance or urgent performance improvement needs), refactor them (for example, add glue code to expose REST APIs as the previous service interfaces could be tightly coupled to the specific platform) and deploy in the cloud. This phased move gives a chance to route a minor amount of traffic to new instances on the cloud for test-and-learn opportunities and, eventually, move all instances of the service to cloud.
• Rearchitect: Finally, there is the most sophisticated approach of breaking all system components into single-responsibility microservices that are modular and have an independent path to production and containerizing them. This involves a complete rewrite and is an expensive process, but it also maximizes the returns.

Unified control plane

Enterprise ops teams manage their cloud landscape through a unified control plane that provides a cohesive and consistent cloud operations experience across environments. It supports core cluster management capabilities like workload scheduling and orchestration, continuous integration and deployment (CI/CD) pipelines, logging, telemetry and federated security.

The goal is to abstract the underlying complexities of the individual cloud service providers (CSPs) and runtimes from the application teams and provide a common interface for ops teams to manage workloads in the enterprise. 

Here are some of the advantages of a unified control plane:

• Utilize dynamic workload placement strategies across virtual machines, containers or serverless deployments.
• Enjoy the ability to onboard additional providers or edge locations with minimal effort.
• Build PaaS capabilities like Function-as-a-Service (FaaS) that are highly available and work across different cloud implementations.
• Centralize compliance management.

API gateway and service mesh

Architecture patterns like centralized API gateways and service mesh enable transparent management of cloud capabilities like routing, service-to-service communication, security, rate limiting and observability.

The API gateway acts as a unified front door across all regions and is responsible for handling “north-south” traffic functions, including the following:

• User authentication and authorization
• Throttling and rate limiting
• Traffic management
• API lifecycle management
• Cloud security guardrails
• Edge analytics

The service mesh, on the other hand, handles the “east-west” traffic between service dependencies:

• Secure service-to-service communication in a cluster
• Traffic management with load balancing, routing rules, retries, failovers, disaster recovery and fault injection
• Telemetry with metrics, logs and traces for all traffic within a cluster, including cluster egress and ingress
• Distributed traceability to instrument the flow of a request across service boundaries
• Automated discovery of services

Istio, for example, is an open-source service-mesh layer that directs communication between services according to a predefined configuration provided by cloud administrators. It acts as a sidecar to the Kubernetes orchestration layer and works with containers, invisible to programmers and administrators.

Security

The complexity of hybrid cloud architecture requires a multi-tiered approach at different layers to ensure end-to-end security and protection. 

CSPs like IBM Cloud, Amazon Web Services (AWS), Microsoft Azure and Google Cloud have the responsibility—as per service level agreements (SLAs)—to authenticate and authorize any calls at the perimeter layer, building a firewall around enterprise applications. This includes denial of service protection and adherence to privacy regulations like General Data Protection Regulation (GDPR) and Health Insurance Portability and Accountability Act (HIPAA).

In an on-premises infrastructure, perimeter security can be achieved using API gateways, which secure all API endpoints. Any call from a web service or a mobile application residing outside a data center must be validated and routed through the API gateway.

A cloud computing environment contains an additional layer of security in the form of control policies defined at the service mesh and APIs exposed by the orchestration platform. These policies ensure that only secure calls get forwarded to the Kubernetes nodes and thereon to the microservices.

Also, the concept of micro segmentation—dividing the environment into different logical security segments to define access control policies for each service and workload—can be used to build and demarcate security levels between services running within an environment. And finally, encryption policies serve as an additional layer of data protection.

Network connectivity

In a single cloud region, availability zones have dedicated fiber network connecting all nodes in a network, allowing enterprises to create highly available architectures where bandwidth is unbounded and network latencies are low. However, communication across regions and multiple cloud providers is routed through public internet and comes at the cost of higher latencies and potential failures.

In a hybrid cloud architecture, there are three patterns for data exchange between the underlying providers:

• Public IP addresses over the internet (high latency due to shared bandwidth)
• Managed services like VPN (more predictable latency with higher security)
• Dedicated interconnect through common points of presence (POPs) (expensive option offered by CSPs but least latency with maximum security)

As these options differ in terms of transfer speed, latency, reliability, SLAs, complexity and pricing, it’s important to weigh the constraints and benefits before designing the network connectivity layer.

Bias for open source in development platforms

A hybrid cloud means the ability to shift workloads from one environment to another and having an application development platform that runs on any cloud. To be truly cloud-native, there should be no tight dependency on any specific technology, platform or even CSP, and enterprises should be nimble to market changes.

An open-source architecture enables this unified approach to development wherein it becomes possible for developers to manage their underlying infrastructure regardless of the technology used for its implementation. Open source is no longer on the periphery with a niche, exclusive audience who use it for cost-effectiveness; it’s now mainstream and has taken center stage because of its rich features, quality and community-based development.

Even in a sensitive area such as security, open-source software is now perceived as a great choice, as reported by the Red Hat Report on The State of Enterprise Open Source (link resides outside of ibm.com). Security, quality and support for cloud-native architecture are the top reasons why enterprises are showing a conscious bias for open source.

See JJ Asghar’s article “Cultivating Careers, Communities and Companies with Open Source” for more.

IBM Cloud hybrid cloud solutions deliver flexibility and portability for both applications and data. Linux, Kubernetes and containers support the hybrid cloud stack and combine with Red Hat OpenShift to create a common platform connecting on-premises and cloud resources.

Learn more about hybrid cloud solutions built with IBM Cloud.

To start building your own hybrid cloud solutions, sign up for an IBMid and create your IBM Cloud account.