Technologies like virtualization and containerization have gained significant traction over the last decade as foundational tools for modern application development. As companies like Amazon (AWS), Microsoft (Azure), and Google (Google Cloud) started to invest in the hardware and software infrastructure required to support access to these virtualized resources, “the cloud” was born.
Networking in and with the cloud involves managing the interconnections of a wide array of devices, services, and applications: VPC containers, gateways, load balancers, controllers, firewalls, routers, switches, servers, clients, IoT endpoints, controllers, service meshes, load balancers, firewalls, edge services, probes, and more, not to mention the many application integrations. These distributed networks present unique challenges but, if correctly managed, can provide highly scalable, robust, and available applications with a competitive ROI.
With over two decades of experience in networking at scale, I’ve had the privilege of working with on-prem, hybrid cloud, and multi-cloud networks and transitioning between these architectures. In this series, I will first explain what I see as the main promises, both fiscal and technological, of using the cloud, and what costs these promises can cover up.
Proponents of cloud architectures maintain that their managed infrastructures keep personnel and networking costs down, all the while promoting high-velocity software development. So, the logic goes, cloud networks are cheaper to build, operate, service, and secure.
With functions, instances, clusters, and connections disappearing and reappearing in mere moments, many integral cloud network components (service meshes, API gateways, controllers, VPCs, etc.) have strong automagic components that abstract the pain of an ephemeral network away from the network engineer. This managed networking allows for more network elasticity, and provides an easy way to store, backup, and secure data, all while reducing costs with more granular, on-demand pricing that eliminates idle or over-used resources.
Security, maintenance, and advancement of hardware are also abstracted away from cloud customers, reducing CAPEX and IT personnel costs.
Agile software development is a byproduct of allowing software development teams to iterate quickly in their architectural choices to best fit their business demands. The virtualization available via cloud services enables this agility by allowing engineers to deploy services with highly customized, decoupled architectures. These cloud-based architectures can be updated regularly and independently of their larger application context, especially with the help of CI/CD tools, removing many common deployment bottlenecks from the development cycle.
This accelerated delivery of software changes in the cloud allows for faster turnover of features, bug fixes, and security updates, and is more likely to drive customer adoption, satisfaction, and ultimately, revenue generation.
I just covered what I consider to be some of the common, high-level cost reduction promises of cloud providers and proponents. But moving to the cloud can’t be a perfect, pain-free solution, can it?
Unfortunately, cloud provider marketing tends to leave out some significant production realities for teams considering the move to cloud-centric development.
In a word, cloud-based development is complex. The myriad of services, applications, devices, regions, policies, access privileges, protocols, security threats, architectures, and deployment strategies makes the scale of complexity in cloud networks a truly unique challenge.
While cloud providers and associated SaaS companies do their best to abstract away a lot of the pain of this complexity, this can make cloud-native organizations strongly dependent on the fiscal and engineering choices of the service providers.
This research paper from 2016 tracked pricing strategies of cloud businesses and clearly illustrates why runaway cloud spend is such a threat for engineering teams. With so many concurrent pricing models at play, keeping track and optimizing for cost is a tall order.
Network engineers often have to take into account a cocktail of variable pricing strategies, including but not limited to:
For distributed networks at scale, monitoring becomes a daunting expense if not handled well.
Consider the massive amounts of data, for every instance, with multiple copies, and often millions of data points between metrics, labels, traces, flow logs, etc., and the costs that this data incurs:
Cloud-native development is rife with dependencies: the cloud providers, the SaaS and open source development, deployment, and monitoring tools.
For simple, standalone applications, the cloud can offer quick wins and cost savings:
As applications and their networking demands become more complex, the cloud can present high costs that are difficult to predict, control, or optimize. But, with network observability principles and strategies, the cost of these complexities can be managed and ultimately provide significant improvements to your organization’s bottom line.
In Part II of this series, we examine the case study of Company X, where I worked for ten years and helped manage migrations to and from the cloud.
I share what I learned about how complex cloud networks can put a strain on an organization when not properly implemented, and the lessons I was able to take from responding to those challenges.