Stop us if you’ve heard this one before – “cloud is the wave of the future.” Cliché, yes, but also technically true. But we bring it up because it’s more than just a trendy phrase or a buzzword. For most organizations today, time isn’t just money – it’s the key to faster growth and better product releases.
Hence why the cloud is such a tantalizing proposition. Get rid of your clunky hardware that doesn’t scale and jump on the cloud where the resources are endless and the scaling is infinite. You’ve read hundreds of articles on how “the cloud will help you do [insert your specialization here]” and how it’ll do it cheaper, faster, and better. And these articles might be right to a point.
Being on the cloud means you can more easily move away from a major release schedule into a CI/CD model and focus on incremental updates. On-premises dev creates a lot of barriers and leads to time wasted on smaller tasks – such as simply sharing files – which make it sub-optimal.
Even so, simply moving to the cloud won’t solve all your issues. Poor cloud management will leave you with a massive bill and the same issues you had on-premises, and without any noticeable improvements to show for it. But the proof is in the pudding. So, let’s dive into why you should dive into the cloud now, and why you might be hesitant to do so.
Why you should dive in
We’re not here to tell you the cloud is bad. In fact, there are tons of reasons why you should jump on the train. Let’s break down a few of the bigger ones.
Scale smarter, faster
Dev managers move to the cloud to be free. The ease with which you can spin up or down resources as needed is a major draw for anyone looking to start or maintain a dev project. Instead of having to rely on hardware you have or buying more servers, you can simply spin up or down any number of instances as required. Moreover, the cost of components – especially chips, whose cost is being driven higher by global shortages – means that scaling with hardware is a pricy proposition.
This scalability comes in a few flavors, and each can be incredibly useful. Take autoscaling tools, for instance. Let’s say you have a massive 64-core instance that you use for a wide range of build-related and other resource-heavy processes. What if instead of a single mega instance, you looked at the problem from a different angle? You can configure your cloud scaling to use a cluster of smaller 8-core instances. You can spin up or down more resources on an as-needed basis, which are all cheaper.
Even better, you can add spot instances to the mix in some of these situations to reduce the cost even further. While they’re not as completely reliable as on-demand resources, spot instances can cut down costs even further when you need to scale up for a short time or for a specific task that doesn’t require constant uptime. The best part about all this? They don’t have to be permanent resources. You can remove them as soon as you’re done, and not have to keep paying maintenance costs.
Low/no-maintenance environments
Another of the highly extolled virtues of cloud environments and computing, in general, is that they cut down on maintenance costs. This is true – if there isn’t any hardware in your office, you’re not really paying to maintain it. But that doesn’t mean there aren’t other maintenance costs, even if they aren’t financial.
Tools like Jenkins are awesome, but they require constant tinkering and updating to work the way you want them. If you’re running a CI/CD pipeline, the last thing you want or need is to have to devote constant time to keeping your settings just right. On the other hand, tools like Azure DevOps come pre-configured and are much easier to manage. If you’re looking for low maintenance, this type of cloud model might be a better fit.
Automation for days
We’re still not at fully automated pipelines, but the access to cloud tools we have today gets us close. Although zero-touch isn’t a thing (yet), most cloud platforms let organizations improve on their existing automation capabilities by reducing friction even further. It starts with moving entire environments onto the cloud and providing toolkits that are cloud-native. This reduces the number of failure points related to hardware that could impact an entire production pipeline.
Let’s visualize that with an example. Say you’re running a pipeline in Jenkins using on-premises infrastructure. You can automate your way through known errors and issues including dependencies and syntax errors, but once the node machine you’re using to run Jenkins goes down, so does your entire pipeline. Instead of simply switching to another instance, you need to resolve the hardware issue – calling IT, getting it fixed, redeploying the machine, and more – before you can keep working. With Cloud? Simply switch to a fallback or another Jenkins ec2 instance.
And yet…
For all the cloud’s benefits, it can quickly rack up costs if you’re not careful. Autoscaling can be a major asset for your DevOps team, but it can lead to carelessness and some unpleasant surprises. The same goes for easy access to resources. It’s tempting to simply “add more” as needed, but some teams are not always as diligent about spinning down resources as they are about spinning them up.
A 2021 report by Anodot found that 77% of enterprise-level respondents had been surprised by their cloud costs, while 70% of all respondents noted that cloud costs were a day-to-day consideration. More importantly, it’s not always the engineers or devs who notice the costs, and costs can really spiral on heavy days.
Even making some decisions to make services better can lead to some unexpected (and shocking) revelations down the road. For the leaked username and password repository HaveIBeenPwned (a white hat site), it came down to misconfiguring a maximum cache size setting that resulted in an A$11,000 cloud bill.
For others, it boils down to overestimating the resources needed, and not making proper adjustments once the right level has been found. Whatever the case may be, cloud bills can end up being much more sizeable than you might think and should give you pause when considering whether a digital transformation is the right move for your DevOps or dev projects.
So, should you move to the cloud or not?
Well, it depends. There are undoubtedly advantages to moving your dev to the cloud. However, if you’re not doing it for the right reasons, and with the right infrastructure in place, you might be setting yourself up for disappointment.
There are a few reasons why you might be thinking about making the switch. The first is to jump on the bandwagon. You’ve heard all the awesome things about cloud and you’re thinking, “well, why not?” And you might catch lightning in a bottle. However, in this case, you’re not really thinking of a solution to a problem, but rather trying to fit a problem into a solution you want.
On the other hand, if you’ve considered the options and are prepared to support it (financially, with the right infrastructure) you definitely should consider it. You also don’t have to fully commit to the cloud 100%. In fact, many organizations today – even those who are “all-in” on the cloud – use hybrid models that combine on-prem compute resources with cloud instances to help them. This way, they have more control over their costs, using the cloud in “bursts” that are easier to manage and control costs.
Before you make the leap, think about what you really need, and what you want to get out of your cloud investment.
