#calculating and testing depreciation in capex | Explore Tumblr posts and blogs

mikegchambers · 8 years ago

Text

The cloud is on and the meter’s running — avoid the sticker shock of ‘pay as you go’

Getting a handle on the actual costs of cloud computing can be elusive and frustrating until your learn the basics of cost control

Cost is often the major driver for many cloud migrations but it’s usually poorly understood in the beginning. It’s fine for startups to demonstrate the value of cloud when they’re coming from nothing, but when you’re dragging 20 years of data centers and legacy software behind you, it’s not always clear what the price tag will be.

Fret not, let’s keep the line on the chart going up and to the right!

“Which is the cheapest cloud?”

This FAQ is similar to asking an attorney “do I have a case?”, or asking a doctor “is it serious?”. The answer depends on knowing which of the cloud services you will use and how you’ll use them — and even then, comparing the costs between cloud providers is difficult.

In their pricing tables, cloud providers are screaming to make you see pennies per hour, per IOP, by ingress, egress, region, zone … you name it. There are even JavaScript calculator that will make you feel really good about the cost.

Upon first glance it’s just so cheap, it feels like shopping a hundred years ago — your dollar is going really far. For cloud novices, some napkin math quickly reveals that their entire infrastructure can be run for just $20 a month with change left over for coffee. Wow, the CFO is going to love you.

Let’s burst this bubble quickly

For any serious cloud application, you have no idea what it’s going to cost until you start using it. No idea. First, different vendors have wildly different ways of measuring and charging that seem obvious at first — but you’ll quickly find the monthly bills are like deciphering Egyptian hieroglyphics.

I’ve always found that Google Cloud is particularly painful in this regard. I’ve been using it for ages and I still don’t understand their charging model. Take a look at my recent statement for a personal test environment that isn’t even doing very much:

… see — bird, ankh, scarab, Batman symbol. It makes the additional charges on my cell phone bill look like common sense. And because Google’s environment features a ton of ‘managed services’, I can’t even begin to tell you where some of this usage is coming from.

The first thing to know is that the cloud doesn’t cost pennies.

So clearly this isn’t ideal — what can we do? First, don’t panic and don’t pay attention to the “we bill by the second” promises you’ll hear. Also realize that AWS didn’t become a $15 billion annual business by charging you pennies.

When you’re first starting out on your cloud journey, I would recommend this approach to billing:

Find a sales person at your favorite cloud vendor and ask for some credits for a test drive. Then ask for some more. You’d be surprised what you can negotiate here since it’s hyper-competitive right now.

Run small-scale projects for 1–3 months to get a sense of the actual bills you can expect. Pick simple projects where you have more control.

Employ third-party apps where appropriate to find waste, use monitoring tools to keep a watchful eye on usage, and start tracking costs in your own spreadsheets to get an understanding of how this all works.

Set up alarms in case it goes wildly wrong. If your daily budget averages $100, set an alarm for 25% overage. Don’t get a bill for $2000 and wonder why a week later.

Anytime you do get a surprise bill, go back to the friendly sales person and ask for a refund or credit — I’ve never known them to refuse, especially when you’re in the adoption phase.

When you have more permanent levels of resources in place, take advantage of committed use discounts available, which can save 50–90% depending on the resource type and vendor.

When you have non-critical workloads — such as overnight processing that’s not time critical — take advantage of spot instances (see below).

So the cheapest vendor is … ?

T0 answer the original question…. it depends. For machine learning applications (heavily GPU-biased) with petabytes of data, Google Cloud might be the way to go. For a more traditional Microsoft business application in the cloud, Azure could be the answer. In my line of work, I’ve tended to find AWS pricing the most consistently reasonable — but that’s just me.

Also, pricing in the cloud is dropping all the time — AWS has had 52 consecutive price cuts the last time I checked. Although, occasionally second-tier players spring head-scratchingly-odd increases on their users. The net effect is that your provider of choice now may not be the most competitive long-term. So you’ll need to constantly monitor pricing options to get the best deal, and decide if switching over is worth the effort.

“Why is this so expensive?!”

Part of the cloud migration rite of passage for many companies is suddenly realizing that something is wrong. Very, very wrong. Your friendly cloud salesmen promised you low cost, you promised your boss cost savings, he promised you a promotion and you promised your kids a trip to Disney World. Suddenly the invoices start arriving, promises are evaporating and getting a photo with Mickey Mouse is looking further away than ever. Sadness ensues.

Unfortunately, just because you understand on-premise doesn’t translate to an automatic grasp of the labyrinthine world of cloud billing. Here are some of the most common gotchas that ensnare cloud newbies:

You have too much infrastructure. The high-availability, infinitely-scalable promise of cloud is alluring but for every region you enable and every level of redundancy you add, the cloud faucet is turned on just a little bit more. And this is a metered service so the bill goes upwards. Always balance your actual needs and tolerance for outages (RTO and RPOs, remember those?) with the cost of building cathedrals of virtual infrastructure.

Cloud is like unlimited Christmas lights: it’s fun all month until you get the electric bill.

You did a lift and shift. When you shift a poorly written application from on-premise, you now have a poorly performing application in the cloud. There’s some appalling software out in the wild and you’ll need to fix it before you jam it into AWS. There’s no magic bullet for crap.

You have inefficient code that isn’t taking advantage of cloud alternatives. Some examples I’ve seen include scripts that fiddle with data somehow — ETL scripts in Perl, PHP, Python — that have been obviated by much, much better cloud replacements like Data Pipeline or third party options. Make sure you find and drown these, many of which can be identified by looking at the ‘last modified’ date on the filename. They worked well in their day but inefficiency is expensive in the cloud.

Your developers embraced DevOps too well. Servers are popping up like mushrooms, they’re building out the virtual data centers of their dreams, and they love — just love — the sorts of tools they never had before. They’re so happy. Unfortunately, ka-ching, that’s the sound of Jeff Bezos’ cash register again.

You use 95% of all your on-premise servers consistently all the time. The classic capacity usage chart below is a major selling point for cloud. But there are some use-cases where you are happily running at full capacity constantly and there’s no waste or overage. While there are still benefits to switching to the cloud in this case, saving money isn’t likely to be one of them.

“Up and to the right”.

You have a load of pirated software or unpaid licenses. Some IT departments are more like the Black Pearl than the QE2. I’ve seen this before so it’s worth mentioning that licensing is expensive when legal. *Crickets*

You don’t really fully understand cloud — and that’s okay. Nobody does at the beginning but you’re getting there so hold on! There is a learning curve that everyone goes through and we’ve all faked it until we made it, one way or another. AWS had over a 1000 product releases last year and I can talk knowledgeably about 10 of them. Welcome to the club.

AWS On-demand, Spot, and Reserved Instances — in 1 minute

Few companies use all three instance categories properly so here’s the world’s fastest primer on the differences:

On-demand is the cloud you were promised. You want a server, request it, and it’s there. This is the most expensive option.

Spot instances are available when Amazon has too much capacity and they auction off the excess. You can bid on these instances and if you win you get some cheap compute. These are short-lived instances (think hours not days) that are more suited to workloads needing bursts of extra CPU time. Spot is often the cheapest option but you can’t run a large percentage of your platform on it in most cases.

Reserved instances are guaranteed for your usage but require a 1 or 3-year commitment from you. These are much cheaper than on-demand but you are guaranteeing usage (you can trade out of these arrangements but it’s still a contractual cost).

Other providers have similar approaches. Basically, as you slide from immediacy and convenience towards guaranteed usage, it gets cheaper.

Spot instances for the win.

Effects on The Financials

If you’ve ever worked in enterprise IT, you’ll be familiar with the CapEx vs OpEx battle that accountants get so excited about. The short version is that capital expenditure — which is buying hardware in our space — is good since it creates a tax write-off for a depreciating asset, whereas operating expenses can only be written off in the tax year they were incurred. Although I’m no expert in this area (seriously), I’ve noticed a tendency to write off servers over, say, 3 years and then not replace them for, say, ever. Accountants love this stuff.

Back in the non-accounting reality, if you’re managing on-premise IT infrastructure, your cost accounting is really tricky to the point of being imaginary. For instance, let’s say you are responsible for an inventory management system and a logistics platform. What is the percentage of hardware cost you assign to each system? And if you have personnel supporting both, how do you work out their cost? What about the data center real estate, property taxes, air conditioning and security?

As you drill down the physical stack, it’s gets progressively harder to figure out the costs of your operation, especially when a third system is added. And a fourth. And there’s so much overlap at different levels. Ultimately you create a model that satisfies accounting but isn’t particularly accurate or helpful.

Traditional IT cost accounting: bad for margaritas.

In the cloud world, this is very different since it’s a metered service where you pay for what you use. In the same way you can calculate the amount of electricity used by a given store, piece of equipment or assembly line, you can attribute cloud costs by product, vertical, service or any other metric.

The method gives you a precise accounting for the cost of a development environment, cluster, region or tier. And since you can tag resources, you can apply internal categories — departments, silos or project codes — that make it very easy to compare apples to apples.

TL;DR Summary — Quick!

Here a five quick takeaways for getting a handle on the actual costs of cloud computing:

Cloud is not free or cheap. But it can be engineered to be much cheaper than on-premise once you have some practice.

There are accounting implications when switching over. Accountants will freak out, but our IT brethren will generally be happier.

There’s a process of fine-tuning the cost that takes time. Don’t be surprised if it’s more expensive at the beginning, but dramatically cheaper later on.

Cloud provides more transparency into the actual cost of running infrastructure. Don’t forget to include buildings and personnel cost when comparing like-for-like.

There is a steep learning curve generously peppered with road bumps. This is normal for any massively disruptive technology that turns our world upside down.

If you enjoyed this, click the heart icon below!

The cloud is on and the meter’s running — avoid the sticker shock of ‘pay as you go’ was originally published in A Cloud Guru on Medium, where people are continuing the conversation by highlighting and responding to this story.

from A Cloud Guru - Medium http://ift.tt/2pAhEju

#A Cloud Guru - Medium

0 notes