By Andi Abes, Chief Product Researcher
To design scalable IT environments, system architects need to be well-versed in core system requirements like scale, high availability, and security.
The public cloud has proven itself instrumental in addressing these concerns by making building blocks like flexible compute capacity, granular security controls at the network and API levels, and fault zone isolation readily available.
Benefits notwithstanding, the cloud is not magic. Failure to consider pricing models can lead to unanticipated cost run-ups. Here are a few recent design mishaps I’ve encountered:
A Costly Scaling Story
With buzzwords like “NoOps” and “Serverless” being all the rage right now, one company thought it would be a good idea to build a new service using AWS Lambda and API Gateway. Their assumption was that AWS would automatically take care of any scaling which turned out to be false. Within two months of being launched, millions of invocations were streaming in continuously causing the cost of providing the new service to skyrocket due to increasing popularity.
A Costly Security Story
At another company, the security team was set on leveraging a more secure cloud deployment by implementing separate account-level boundaries for management, production, and staging accounts. The infrastructure for each account would tie back in with the secure management network, using the appropriate network and peering configurations. However, they failed to consider that all their network traffic was previously free, and network traffic under their new configuration would be treated as internet traffic in terms of incurring NAT charges.
A Costly Availability Story
To provide one last example, a third company storing data in large quantities needed to ensure workload availability even during partial failures. They addressed this requirement with multi-zone backend storage deployment with online replication between zones. This ensured that availability wouldn’t be impacted by localized failures. However, similar to the previous example, they failed to consider how this would drive up their network transit charges.
If you’re looking to get a service out to market quickly, Lambda and API Gateway are excellent choices because they don’t require infrastructure or operational investments. That being said, service charges can rise dramatically as the business scales. As such, rigorous due diligence is a must when considering a “Serverless” IT strategy.
The stories touched upon in this blog should be regarded as cautionary tales to encourage strategic planning, rather than reasons to avoid pursuing the benefits of the public cloud. The sheer variety of building blocks available in the public cloud empowers enterprise architects with the ability to quickly build new iterations.
The decision of which specific building block to use (e.g. Container-Functions or Lambda) should depend on an organization’s unique business needs. These needs may change at different stages of the product lifecycle. Once a product gains traction, lowering COGS must be added to your list of priorities—creating a cost-effecting service offering may require some re-architecting.
To learn more about the various storage options at your disposal, read my “Agility with Accountability” article, which remains quite relevant despite being several years old.
This post originally appeared on the Foggy Software blog.