This blog is part two of a three-part blog series on “Why Public Cloud Over Private Cloud” READ PART one HERE and part three HERE.
In the previous blog post we ended on the idea of developing micro-services each with their own bounded context, and the benefits associated with it, along with some challenges for horizontal scaling of the workload. Before we go into further discussion on Why Public Cloud Over Private Cloud, I first wanted to circle back to some legacy concepts around compute, network and storage virtualization and how public cloud should treat these assets very differently.
Some Common Challenges:
Storage:
-
- With on-premise solutions, we often see automation of compute, network and storage performed by the virtualization teams within IT. Sometimes the storage is only partially automated, having a storage team allocate a portion of physical storage and allowing the virtual teams to abstract this into virtual slices. Since both the compute and storage are still backed by physical resources, the ability to scale is limited and therefore needs to be controlled than what might be done in a public cloud environment.
- In the public cloud, storage is much more fluid. When we design new micro-services and move data into a tightly bounded context, we need to be more fluid with how we store data, create new types of databases from SQL to highly distributed no-sql, graph, in memory, clustered, and even data lakes for improved AI/ML. The numerous public cloud data-based services offer great flexibility that can never be achieved on-premises.
Networking:
-
- Networking teams are similar, often with a mix of blended solutions from physical networking gear either being manually configured or using automation to simplify everyday configuration tasks, but still controlled through submitting requests and gaining approval before the automation occurs. Virtual networking overlay solutions are used to carve off areas for specific workloads, but it all routes through a physical layer still controlled through traditional processes.
- In the cloud, we use virtualized networks from inception, but we’re able to take it beyond what we might do on-premises. Every account in a cloud will have at least one virtual private cloud or VPC, which is its own networked environment. It is a best practice to create hundreds of different accounts to provide not only network segmentation between lines of business, but even between applications and micro-services.
Security:
-
- Firewalling is often just at the network segmentation boundaries for North-South traffic, with little internal firewalling. Modern implementations leverage firewalls for east-west traffic across internal network segments and can use tagging to automate rule policies to control data access. This improved security posture helps but rarely delivers micro-segmentation level security across all the applications and services running.
- Micro-segmentation in the cloud takes security to a new level, providing firewalling and routing between every hop. As microservices grow, providing explicit routing controls and firewalls dictating what service can talk to one another, locking down data to a service, using unique encryption keys for every service and separate individual load balancing are just a few of the most common services that will create a more tightly optimized and secure environment.
Computing:
-
- Virtualization of computing resources has been around for 20 years, with many technologies to assist in automating the request of new resources. Often the request process is still through a self-service catalog, which is an improvement over manual requests but falls short of infrastructure as code. Some newer solutions do extend the ability of compute provisioning to a CI/CD pipeline but are still constrained by the physical limitations for scale and therefore gamble that teams use these services at a predictable rate. The problem is the unpredictable nature of live events.
- The 2021-22 Log4J vulnerability is a perfect example when teams had to patch 2,3,4 times as new vulnerabilities were discovered. Having every team redeploy every app could not be handled with on-premise resources for most organizations and required updates against live workloads.
- In the public cloud with hyper scaling, they could deploy whole new versions of their app, fully patched, and tested before directing traffic to it, all the while having the previous version still running.
- Containerization is another form of compute virtualization. Being lightweight, it improves density efficiencies and improves startup times when scaling. It is very appealing for micro-services workloads that need to scale elastically. However, this leads to management challenges as more micro-services are designed with async characteristics to be event driven, not pre-launched. The runtime nature is often difficult to predict and therefore difficult to effectively manage a fully dynamic fleet of clusters. It will run fine until there is a scenario where it does not.
- Outperforming a DDOS (Distributed Denial of Service) attack
- Scaling during a stock market event
- Scaling when workers move to remote access overnight
- Scaling news outlets when a large event happens
- Scaling to support mass redeployments during an emergency vulnerability
- Dynamic Scaling for batch operations
- Dynamic Scaling for event based processing
- Virtualization of computing resources has been around for 20 years, with many technologies to assist in automating the request of new resources. Often the request process is still through a self-service catalog, which is an improvement over manual requests but falls short of infrastructure as code. Some newer solutions do extend the ability of compute provisioning to a CI/CD pipeline but are still constrained by the physical limitations for scale and therefore gamble that teams use these services at a predictable rate. The problem is the unpredictable nature of live events.
These concepts tend to fall significantly short of what a public cloud implementation can achieve. For “Private Clouds” (from here referred to as “PC”), companies still have limited resources and control what is provisioned, when, where and how. Since “PC” does not have unlimited resources, companies still treat resources as pets, using static IP addresses and modifying load balancers such as F5’s to route to the new resources. For deployed virtual machines, companies still manage these resource as legacy systems, logging in to update, patch or troubleshoot, which means maintaining users and passwords for access. Even with tools such as Puppet, Chef or Ansible, these solutions try to automate many of the human touch points, but still require these systems be updated in place adding risk.
Any time a traditional system is touched, it leaves the organization at greater risk for mistakes, failed patches, and downed systems. It also opens new attack vectors having systems with SSH or RDP enabled, and logins for access is an increased risk which can often be eliminated in a native cloud implementation.
I hope you’re enjoying the discussion. Please feel free to ask questions or leave comments, I’m always happy to continue the discussion. Check back often for the next installment in this series “Why Public Cloud Over Private Cloud” where we’ll dive into more detail on various public cloud applications and services.
