Hybrid cloud for enterprises

Imagine your organization has an e-commerce website with seasonal traffic and, at the same time, a sensitive financial database where you don't want even a single record to leave the walls of your own data center. If you entrust everything to the public cloud, you worry about data privacy; if you keep everything on-premises, you have to buy servers for traffic peaks that sit idle for eleven months of the year. The middle-ground solution is the hybrid cloud; an architecture where part of the workload runs on on-premises infrastructure and part runs on the public cloud, with the two communicating through a secure, low-latency connection.

In this article, we're not going to give a theoretical definition. We're going to understand why a real organization should adopt a hybrid cloud, what it should keep on-premises, how to design the connection between the two sides, and where things usually go wrong.

Why Hybrid Cloud? Three Reasons That Have Nothing to Do with Being Trendy

The hybrid cloud is not a luxury choice; in many cases, it's the only option that satisfies both technical requirements and legal constraints. Let's examine the three main reasons in detail.

1. Data That the Law Does Not Allow to Leave

In Iran and many countries, financial, medical, and certain government data are subject to regulations that mandate their storage within borders or even within a specific data center. If your organization works with such data, a pure public cloud is practically removed from the options. But this doesn't mean you can't benefit from the cloud for other parts. Sensitive data stays on internal servers, while less sensitive parts like the public web server or the test environment run on the cloud.

2. Fluctuating Workloads and Hardware Purchase Costs

Suppose you have a university entrance exam registration system whose traffic becomes 50 times its normal level during two specific weeks of the year. If you want to handle this peak by purchasing internal servers, you'd have to buy hardware that is 50 times your normal need and sits idle for 11 months a year. In a hybrid cloud, you keep the baseline capacity on-premises and spin up cloud instances during the peak. This both reduces purchase costs and gives you the flexibility to release cloud resources once the peak is over.

3. Critical Latency for Real-Time Processing

Some processing, such as fraud detection in banking transactions or quality control on a production line, requires latency below 10 milliseconds. Sending data to a cloud data center that might be hundreds of kilometers away violates this requirement. These processes must run on internal hardware. However, you can send their final results to the cloud for later analysis.

What Should We Keep On-Premises? A Decision-Making Framework

Instead of giving a ready-made list, I suggest a three-question framework. Ask these three questions for every service or piece of data:

1. Does the law or a contract specify where the data must be stored? If yes, that data stays on-premises.
2. Does the service require latency below 20 milliseconds? If yes, on-premises execution is mandatory unless you have a cloud with a very close geographical location.
3. Is the workload fluctuation more than 5 times the average? If yes, this service is a good candidate for the cloud portion so you don't have to buy hardware for the peak.

With this framework, a common pattern emerges: core databases, payment services, and real-time processing stay on-premises; public web servers, test and development environments, data analytics services, and batch processing go to the cloud.

Connectivity Architecture in Hybrid Cloud; Where Everything Falls Apart

The biggest technical challenge of the hybrid cloud is the connection between the two sides. If this connection isn't designed properly, the entire architecture collapses. You need to design three connectivity layers separately.

Network Layer: VPN or Dedicated Connection?

The simplest approach is to establish a VPN tunnel between your internal data center and the cloud VPC. For getting started and low volumes, IPSec Site-to-Site VPN is sufficient. But it has two limitations: bandwidth is limited by your internet connection, and its stability depends on the quality of your internet link.

If the volume of data being transferred is high (for example, more than 50 gigabytes per day) or you need high stability, you should consider a dedicated connection. Many cloud providers offer a direct connect service that connects to your data center through a dedicated link. In this case, latency is more stable and bandwidth is predictable.

One important note: never rely on a single link. Design at least two redundant connection paths so that if one goes down, traffic can traverse the other.

Data Layer: Two-Way Synchronization

When you have an internal database and cloud applications also need it, you have two options:

• Direct access: Cloud applications connect to the internal database through the network connection. It's simple, but if the connection is lost, cloud applications go down.
• Data synchronization: A copy of the data is kept in the cloud and synchronized periodically (for example, every 5 minutes) with the internal source. Cloud applications connect to their local copy. This method is more resilient but adds synchronization complexity.

For synchronization, open-source tools like pglogical for PostgreSQL or MySQL Replication for MySQL work well. The critical point is that synchronization must be two-way and conflict resolution must be defined. For example, if a record is edited both on the internal side and the cloud side, which version wins?

# Example: setting up one-way replication from internal to cloud with pglogical
-- On the internal server (provider)
SELECT pglogical.create_node(
    node_name := 'internal',
    dsn := 'host=192.168.1.10 port=5432 dbname=mydb'
);

-- On the cloud server (subscriber)
SELECT pglogical.create_node(
    node_name := 'cloud',
    dsn := 'host=10.0.0.5 port=5432 dbname=mydb'
);
SELECT pglogical.create_subscription(
    subscription_name := 'internal_to_cloud',
    provider_node := 'internal',
    replication_sets := '{default}'
);

Application Layer: Resilience and Caching

Applications running on the cloud must be designed to tolerate temporary connection outages. This means using the Circuit Breaker pattern and Retry with Backoff. Also, to reduce dependence on the connection, use caching. For example, if a cloud application needs a product list that changes once an hour, cache it in Redis and update it from the internal source once an hour. This drastically reduces the number of requests traversing the connection.

Security at the Hybrid Cloud Boundary

When your internal network connects to the cloud, the attack surface grows. Take several essential measures seriously:

Segmentation and Micro-segmentation

Divide your internal network into separate segments. Sensitive databases should be in a separate VLAN and only accessible through a Jump Server. On the cloud side, use Security Groups that only open necessary ports. For example, if a cloud application only needs port 5432 on the internal database, no other port should be open from the cloud side to the internal side.

Encryption in Transit and at Rest

All traffic between the two sides must be encrypted with TLS or IPSec. Data stored on both sides must also be encrypted. For encryption keys, use a key management service (KMS) that centrally manages keys and logs access to them.

Monitoring and Alerting

Monitor the traffic passing between the two sides. Unusual data volumes, a high number of failed connections, or unusual time patterns can indicate an intrusion. Tools like Prometheus and Grafana for monitoring and Alertmanager for alerting are common open-source choices.

Practical Scenario: An Online Store with Seasonal Peaks

To make everything tangible, let's design a complete scenario together. Suppose you have an online store whose traffic becomes 20 times higher during special occasions (like Yalda Night or Nowruz).

Proposed Architecture

• On-premises: Main PostgreSQL database, payment service, warehousing, and accounting software.
• Cloud: Nginx web servers, application servers (e.g., Node.js or PHP-FPM), Redis for caching and sessions, and the test environment.

In normal conditions, 2 cloud instances for web and application are sufficient. During the peak, the number of instances automatically scales up to 20 (with Auto Scaling). Cloud applications connect to the internal database through the dedicated connection. To reduce the load on the database, all high-frequency reads (like product lists and prices) are cached in Redis, and only writes (orders) go directly to the database.

Failure Management

If the connection between the two sides goes down, what happens? Cloud applications must be designed to hold orders in a local queue (for example, RabbitMQ on the same cloud instance) and send them to the internal database when the connection is restored. This pattern is called Store and Forward and is critical for resilience in a hybrid cloud.

Common Mistakes in Hybrid Cloud Implementation

In conclusion, let's review the four mistakes I've seen in almost all unsuccessful projects:

1. Ignoring network latency: They assume that because the connection is established, latency doesn't matter. They forget that every request from a cloud application to the internal database traverses the network twice (there and back). If one-way latency is 5 milliseconds, each query takes 10 milliseconds longer. For applications with thousands of queries per second, this number is a disaster.
2. Not testing connection failures: They don't simulate connection outages in the test environment. The day it actually goes down, they realize the cloud applications have completely failed.
3. One-way synchronization: They only synchronize data from internal to cloud and forget that some data (like users' shopping carts) is generated in the cloud and must be sent back to the internal side.
4. No exit strategy: If one day you want to leave the cloud or change providers, how do you get your data back? You should design this from day one, not when you need it.

Conclusion

The hybrid cloud is a mature architecture that allows you to both benefit from the advantages of the public cloud (scalability, variable costs) and keep control of sensitive data in your own hands. The key to success is making informed decisions about where each service runs, carefully designing the network connection and data synchronization, and being prepared for outages. If you take these three pillars seriously, the hybrid cloud becomes one of the most powerful infrastructural tools in your organization. And if you're just starting out, begin with a small, non-sensitive workload, gain experience, and then expand the architecture.