Modernizing Enterprise Java

From Public to Private. Why Clouds?

The differences between public clouds, private clouds, hybrid clouds, and multiclouds were once easily defined by location and ownership. Today, these two are no longer the only relevant drivers for the classification of clouds. Let’s start with a more comprehensive definition of the different target environments and why they are used. 

A public cloud environment is usually created from resources not owned by the end user that can be redistributed to other tenants. Private cloud environments solely dedicate their resources to the end user, usually within the user’s firewall, data center, or sometimes on premises. Multiple cloud environments with some degree of workload portability, orchestration, and management are called hybrid clouds. Decoupled, independent, and not connected clouds are commonly referred to as multiclouds. Hybrid and multicloud approaches are mutually exclusive; you can’t have both simultaneously because the clouds will either be interconnected (hybrid cloud) or not (multicloud).

Deploying applications to a cloud, regardless of the type of cloud, is becoming more common across enterprises as they seek to improve security and performance through an expanded portfolio of environments. But security and performance are only two of many reasons to move workloads into hybrid or multicloud environments. The primary motivation for many is the pay-for-what-you-use model. Instead of investing in costly on-premises hardware that is hard and expensive to scale out, clouds offer resources when you need them. You don’t have to invest in facilities, utilities, or building out your own data center. You do not even need dedicated IT teams to handle your cloud data center operations, as you can enjoy the expertise of your cloud provider’s staff.

For developers, the cloud is about self-service and flexibility. You don’t have to wait for environments to be promoted, and you can choose infrastructure components (e.g., databases, message brokers, etc.) as the need arises to free you from unnecessary wait times and ultimately speed up development cycles. Beyond these primary advantages, you can also find custom features for developers in some cloud environments. OpenShift, for example, has an integrated development console that provides developers with direct edit access to all details of their application topology. Cloud-based IDEs (e.g., Eclipse Che) provide browser-based access to development workspaces and eliminate local environment configuration for teams.

Additionally, cloud infrastructures encourage you to automate your deployment processes. Deployment automation enables you to deploy your software to testing and production environments with the push of a button—a mandatory requirement for Agile development and DevOps teams. You’ve seen a need for 100% automation already when you’ve read about microservices architectures. But automation goes well beyond the application parts. It extends to the infrastructure and downstream systems. Ansible, Helm, and Kubernetes Operators help you. We talk more about automation in Chapter 4, and you’ll use an Operator in Chapter 7.

What “Cloud Native” Means

You’ve probably heard of the cloud native approach for developing applications and services, and even more so since the Cloud Native Computing Foundation (CNCF) was founded in 2015 and released Kubernetes v1. Bill Wilder first used the term “cloud native” in his book, Cloud Architecture Patterns (O’Reilly). According to Wilder, a cloud native application is architected to take full advantage of cloud platforms by using cloud platform services and scaling automatically. Wilder wrote his book during a period of growing interest in developing and deploying cloud native applications. Developers had various public and private platforms to choose from, including Amazon AWS, Google Cloud, Microsoft Azure, and many smaller cloud providers. But hybrid-cloud deployments were also becoming more prevalent around then, which presented challenges.

The CNCF defines “cloud native” as:

“Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach. These techniques enable loosely coupled systems that are resilient, manageable, and observable. Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil.” 

—CNCF Cloud Native Definition v1.0

Similar to cloud native technologies are the Twelve-Factor Apps. The Twelve-Factor Apps manifesto defines patterns for building applications that are delivered on the cloud. While these patterns overlap with Wilder’s cloud architecture patterns, the Twelve-Factor methodology can be applied to apps written in any programming language and use any combination of backing services (database, queue, memory cache, etc.).