HALP! We need the update in production now!
HALP! Things aren’t working like they did in development!
Last minute updates, broken applications and more put a lot of pressures on IT teams today. To help with the flood of constant IT requests, IT teams often look to automate infrastructure and application deployment. Automation helps IT teams to increase speed and consistency, and often results in infrastructure deployments as code.
In reality, infrastructure as code solves infrastructure challenges only through coding —requiring cloud specific expertise. Infrastructure should be deployed for the purpose of code — as an ends to a mean. To truly solve the business challenges attributed with deploying usable applications, you need a tool that flips the current infrastructure focus on it’s head and puts the application at the center of the discussion.
In fact, according to Gartner, the software-defined architecture for application services is one of the biggest coming trends in computing (Gartner top 10 technology trends). Tools like CliQr do this by defining all aspects of the application, including infrastructure requirements. This allows you to mix and match reusable services through an abstracted drag and drop interface that doesn’t require you to code at all.
Your organization may have a lot of people who can code, but I bet you their time isn’t cheap and they’ve other things they could be doing other than learning another paradigm. At the end of the day, infrastructure as code is code and requires expert knowledge. Custom, cloud specific properties and parameters will be needed to get a desired end result.
The better method is to abstract the entire underlying infrastructure away into an easy-to-use drag-and-drop interface of whitelisted services. Some companies like AWS are starting to move this way, but their functionality is limited. They also often act just as a UI for code rather than an abstraction. For a better demonstration, we’ve made a video comparison of just how long it takes to deploy an application using both methods.
The video here shows CloudFormation on the left and CliQr on the right. I’m simply creating a 2-teired, auto-scaling application from scratch. Note that because I didn’t have the skill or time, I started from a publicly available template that AWS has published.
Once it’s time to deploy that application, odds are that you would like to have some sort of governance and policy to control cost and ensure good corporate citizenship. Being able to auto-scale, time-based terminate, define resource/cost limits, or understand estimated cost are important to ensure that your spending is kept in line. Without these kinds of features, infrastructure as code tools keep you in the dark as to what your current utilization is and what kind of bill you should expect to see at the end of the month. By keeping the focus on the application level with all other objects below it, CliQr is able to save you money by down-sizing or terminating lightly or not used applications.
In a best-case scenario, your company will only ever need to deploy these applications to one cloud, within one of that cloud’s regions, and never plans to change vendors—but that’s not very realistic. You see, when deploying infrastructure as code through something like CloudFormation, the code you’re creating is locking you into specific infrastructure on a specific cloud. If you want to deploy elsewhere or utilize on-premise resources, you have to duplicate your efforts by coding in a second tool specific to that cloud as well as maintain a second set of code templates. With an application-defined tool where the application requirements drive the output, the description of the application and its requirements are cloud agnostic so that the same profile can work on any cloud.
What it comes down to is that infrastructure as code tools are good for a single purpose—getting you spend more by making it a little easier to deploy the same infrastructure over and over. These tools won’t decrease your cloud spend, they won’t free up your developer’s time, and they won’t keep you from being locked in to one cloud vendor. So let’s up-level the conversation and talk about abstracting infrastructure rather than coding it. To see how you can abstract your infrastructure, check out some of our videos on YouTube or request a demo.