kosmin - Fotolia


Learn from Amazon, Google when you build a private cloud

Private cloud planners can learn much from the public cloud examples of Amazon and Google, says expert Tom Nolle. Here are the lessons to learn.

The best reference for anything technical is a previous implementation. For cloud computing, the examples of Amazon and Google should be gold standards to follow when you build a private cloud. Cloud planners and architects should understand the public cloud's basic structure, select the special elements needed to apply this structure to a private cloud, and address special issues of "application tenancy."

Everyone probably realizes that public cloud services are giant shared data center complexes. You allocate a resource like a VM or container to a user when they subscribe, and the user fills that virtual resource with an application or component, which then becomes part of the user's IT. Underneath, it's much more complicated.

The big issue is addressing. In a data center, applications and components run inside an address space on one or more subnetworks. Most companies assign public IP addresses to their servers and applications. Amazon and Google build cloud services through sophisticated virtual networking as much as through physical hardware.

Inside an Amazon or Google cloud, users are assigned addresses from a "private" IP address space whose addresses cannot be routed on the Internet. Most home and small business users get such an address from their ISP, and use the Network Address Translation (NAT) standard to map requests from home devices to websites. Amazon and Google use a more sophisticated public and private address mapping system. Amazon calls its approach "elastic IP addresses;" Google uses the project codename "Andromeda" to describe its approach.

In both cases, the goal is to build applications inside a sandbox where all the interfaces and addresses are not reachable by default. Interfaces that have to be exposed are mapped to a traditional public IP address, which can then be registered with a Domain Name Server or other directory for use by client devices or other applications.

The use of private IP addresses for user cloud services means that the cloud's own infrastructure is isolated from the services, and services are partitioned from each other. The public cloud's multi-tenancy support is created largely through this address management, and private cloud users can take advantage of the virtual network approach to ensure that users (or hackers) can't access applications except through the specific interfaces they intend to expose.

Another aspect of Amazon and Google public cloud services to consider when you build a private cloud is policy-based management. A large cloud provider wouldn't normally task a European data center to host an application used in the western U.S.  Even in private clouds, data paths should be kept short where possible, and pieces of an application that are supposed to be redundant shouldn't be hosted so that they depend on common resources. Obviously, there will be situations where suboptimal assignment is needed to obtain service, but optimization of resources is a key element in cloud success.

Policy management of resource assignment and connectivity requires a policy tool, policy encoding of the requests for hosting or connection, and policy encoding of the available resources. Technical support specialists at public cloud providers like Amazon and Google know that accurate coding of both requests and resources is critical, or they will risk failing to meet service requests or assign suboptimal resources to fulfill requests. Both will likely increase costs and may impact application performance.

Cloud providers have customized software and hardware to manage their infrastructure, tools not available to end users. Fortunately, it's possible to get the critical pieces of cloud provider address and policy management from commercial sources, although careful discussion with vendors will be necessary.

Address management in the cloud is often described as an application of NAT, but NAT tools are not sufficient. Some good articles are available on this topic and data center switching and application delivery controller vendors can help set up proper address management systems for you. Be sure to look for both address and port mapping capability, and be aware that container-based cloud systems may require more careful address management than VM-based systems.

OpenStack has a number of related projects that can be used to simplify deployment and connectivity. Group-Based Policies (GBP) uses intent modeling principles to define dependencies, security constraints and network service chaining. By working within a user-defined group structure, GPB can simplify the application of deployment and connection policies and reduce both ongoing effort and errors. Check with your OpenStack vendor too; most will have a recommended set of policy tools, and many will offer address management and connectivity control as well.

The final point planners who build a private cloud should consider about Amazon and Google cloud implementations is that basic question of multi-tenancy. A public cloud has to isolate tenants from each other or risk creating unsolvable security and compliance problems for users. Tenancy management in a private cloud seems silly -- by definition your company is all that's "in there" -- but the value of "application tenancy" is worth exploring.

Applications and their associated users often need the same level of separation and protection as public cloud users do. Everyone understands that payroll and personnel applications demand security, but nearly every business application has to limit access to validated users. Today, application security normally controls authentication and sign-on, not "access" in a direct sense, which is very different from the public cloud. Amazon and Google would separate applications onto private subnetworks; why should private clouds do less? Your own private cloud application security measures could benefit from an injection of public cloud thinking.

This may be the most profound lesson public cloud providers can teach enterprises that build a private cloud. The requirements are not as different as you would think, and if private clouds draw on the architecture-level application partitioning that public clouds naturally present, compliance and security can be stronger and the path to hybrid clouds -- which virtually every cloud user will eventually travel  -- will be easier.

Next Steps

The private side of a hybrid cloud architecture

Extending a private cloud to a hybrid cloud

Dig Deeper on Cloud architecture design and planning