Cloud has many unseen connections and complexities that make it hard to operationalize.

The 3 Dimensions Of Cloud Configuration Complexity (Part 2)

cloudcoreo Jason Needham 0 Comments

If you’re like most organizations moving to the cloud, your cloud infrastructure is expanding rapidly and you’re utilizing more cloud services than you ever imagined. Understanding and operationalizing cloud is extremely hard because cloud configuration is complex. In Part 1 of this series, we discussed the first dimension of cloud complexity: More Services and Inter-Dependencies. Today, we’re going to dive into the second dimension: More Dynamic Applications.

Complexity #2:  More Dynamic Applications

As digital transformation spreads across all industries, we’ve all come to expect more from modern day applications. Applications now need to scale infinitely, be ultra-fast and never go down, and this requires a new approach to building and managing applications and infrastructure.

The Old Days of Static Application Architecture

Just a few short years ago, applications were run on data center infrastructure owned and managed by siloed IT teams. It wasn’t uncommon to walk into a data center and see thousands of servers, 50 load balancers and firewalls all running at 5% capacity. Millions of dollars of infrastructure sat idle, waiting for a traffic spike. And when you needed more infrastructure capacity, you filed a ticket with IT and waited patiently.

And when data centers were still the norm, the application team’s job was to code the application and lean on the networking and IT team to take care the rest. The standard practice was to deploy a 3 tier application architecture consisting of a web, app and database tiers. Each layer and machine was explicitly configured and defined.

Today’s Dynamic Applications

In order to achieve the scaling, speed, and up-time needed for modern applications, companies today are building dynamic applications that depend on cloud infrastructure. Using cloud instead of data centers enables companies to only pay for what they use, but still have instant access to scale up to using more servers, load balancers, and firewalls to handle traffic spikes. No more idle infrastructure.

The move to cloud also allows for infrastructure built from individual services, where each service can scale up or down as needed to dynamically accommodate your application’s needs in real-time. No more filing a ticket with IT and waiting. If development teams need more capacity or need to add a new service, they can log into the AWS console and make the change instantly.

Every level of sophistication you add involves adding another layer that requires additional configuration. Now, imagine you have 5, 10, or 100 applications and you get a sense of the building complexity ahead of you.
Sophistication = More and More Configuration

As you climb the curve to create these smarter, auto-scaling, resilient applications, the engineering and operational costs continue to increase. Your new, shiny, sophisticated application is just the opening act. Soon you must scale and expand that application to a new region, replicate the environment to dev, and test and streamline the CI/CD pipeline. Every level of sophistication you add involves adding another layer that requires additional configuration.

Now, imagine you have 5, 10, or 100 applications and you get a sense of the building complexity ahead of you as your portfolio of cloud applications increases.

Deploying Consistently in the Cloud

It’s really hard to deploy consistently in the cloud. There are plenty of cloud templating and automation systems out there, but I still hear way too many stories of people going around their automation tools to get simple things done, either because they can’t do everything they need to with the tool or because the tool doesn’t accommodate certain changes to existing configurations. This is especially true when it comes to cloud infrastructure.

The reality is that automating deployment is not optional but required—the transient nature of the resources, the need to scale, and the sheer numbers of objects involved mean that manual, console, or scripting approaches simply will not work, especially when uptime and other SLAs are taken into consideration.

And when you’re forced go around your templating or automation tool to make changes to your cloud, you no longer have a single source of truth for what’s running in the cloud. We’ve talked to many companies who have cobbled together multiple tools and custom scripts to continuously check the state of their cloud deployments in order to understand what’s actually going on. These “cloud archeology” projects suck up time and resources that could be saved by deploying consistently.

While our Cloud Scan can alert when we find something in your account that shouldn’t be there, our platform goes beyond that. CloudCoreo provides you with reusable cloud reference designs that can model your entire cloud infrastructure environment, making it easy to deploy and maintain the latest cloud native applications.

Next time we’ll dig into Complexity #3: Growing Cloud Teams.

Leave a Reply

Your email address will not be published. Required fields are marked *