Many organizations are “lifting and shifting” their existing applications into the cloud. Because they’re not building them around cloud tools and techniques, they end up spending more money than they need to. Running a virtual machine (VM) in a cloud service is very expensive — in fact, it’s one of the most expensive ways to use the cloud. Organizations can get the same amount of compute for a serverless application for a third to a quarter of the cost. Yes, there will be costs associated with rearchitecting the application, but it’s an investment that will quickly pay for itself.

When organizations move to the cloud, they often use the services they’re familiar with in the on-premises environment. Unfortunately, it’s very expensive to implement those services in the cloud, and they don’t scale very well. An example is the hub-and-spoke routing system we discussed in the last article. Organizations usually end up with a hub-and-spoke model because they’re trying to route traffic through a legacy firewall that’s running as a VM. A more cost-effective solution is to use the native firewalling capabilities that are built into the cloud service or leverage host-based controls, which are more appropriate for cloud-scale appliances anyway.

Load balancing is similar to firewalling. Organizations that use legacy load balancers in the cloud need VMs to sit behind them. They have the cost of the VMs and they’re stuck in the hub-and-spoke routing model. There are a number of cloud-native services that can perform load balancing and other roles. In addition to saving money, these services interact with other cloud components and offer techniques that aren’t available to legacy appliances. For instance, cloud-native load balancers will increase or decrease the number of servers that support a service based upon demand.

Organizations often try to bolt on third-party software to run backup services, which consume a lot of VM instances and don’t use storage effectively. For example, organizations end up paying for a complete image for every version they want to keep, and for storage at the source, transfer site and destination. Also, the customer pays for traffic to and from the third-party site. Cloud-native tools offer the ability to take point-in-time snapshots that are layered on top of each other. A small delta file is saved, not a complete copy of the image. Cloud-native services don’t charge redundantly for storage or the bandwidth needed to move the data among multiple sites. Finally, there’s less risk of error — administrators don’t have to babysit the backup process. If something fails, the cloud provider fixes it.

Some cloud providers do things better than others, so it doesn’t always make sense to try to remain cloud-agnostic. It’s usually more cost-effective to target builds at a particular environment and leverage that cloud’s utilities to reduce overall operational expenses. It does increase development costs and can increase development timelines, but overall operating costs come down significantly.

Most organizations are consuming services from multiple cloud providers, and one of the biggest expenses is the cost of shifting data among these clouds. There are services that provide API-level control to directly connect clouds. Instead of paying the public transit rates, the customer pays for private interconnect rates that are not only cheaper but faster. The easiest way to think of them is as dark fiber connections between cloud tenants that can be turned on when needed using APIs and scaled on demand.