In May of 2010, I wrote my first article dedicated to explaining the benefits of cloud computing (check out that dated graphic on that page). I updated that article in August of 2012. Now, it’s time for another update, or really, more of an addendum. The cloud industry has been unfolding for quite some time now and it’s clear that it’s not a “flash in the pan” or some trendy thing that will die. In fact, it’s more relevant today than ever before! In addition, there are more players and new technologies. And, more importantly, the value & benefits continue to grow.
New businesses and complete industries have been born from the cloud (without which they may never have gotten off the ground). Service based businesses that are almost 100% dependant on web and mobile technologies to survive explode in size like the big bang. These companies don’t have time to hire an infrastructure staff or even wait for the concrete to dry on a data center (even if they did have the capitol). Companies like Uber, Airbnb and others may not have been able to fund or survived the proof of concept phase to get where they are today had they been required to build the infrastructure and operate all of the systems necessary to deliver their service.
Cloud benefits more than just startups. To stay competitive, companies are moving to the cloud to lower costs and take advantage of all the soft value benefits to stay competitive and grow their businesses vertically and horizontally.
My original article viewed benefits of cloud mainly through the lense of software-as-a-service (SaaS) at the time. I later dove into platform as-a-service (PaaS) value, and also covered infrastructure as-a-service (IaaS). The benefits in my earlier article still apply so so there’s no reason to re-write it.
What follows should append what we already know at this point (assuming you have read that article).
You can only get it in the cloud
I wanted to start with the most shocking realization that I’ve had. I attended Google’s cloud conference and then published my observations on this BLOG, leading off with one of the strengths of Google’s cloud being their machine learning and big data capabilities. It wasn’t until Miha Kralj from Accenture mentioned that many of the newest technologies are being developed for the cloud first, and sometimes only for the cloud that it came together for me (I’m slow). You can’t go out and purchase Google’s epic replicated uber scalable database, Cloud Spanner (Beta as of this writing), nor will you be able to in the near future. You have to go to the cloud to get it. The same for Amazon’s Aurora DB (built on-top of Open Source MySQL and a version for PostgreSQL). Oh, and forget “serverless”, you have to build your own... but wait, then it’s not really serverless is it? :)
Sure, many of the services at AWS and Google are built on open source (and some not) but the secret sauce for scalability, redundancy and ease of management are not available for purchase on a DVD or any other way. In the area of big data and machine learning, I think the leading edge will always be in the cloud, which is OK. Really, if you think about it, big data is perfect for the cloud, where going really big is their business.
Lock-in
Some will say that this just makes cloud sticky, and that is ‘lock-in”, and lock-in is really bad. In reality, this is no different to platforms and technologies in the past. You’ll have to get over it if you want to leverage the latest tech and stay competitive. And oh, by the way, there’s always lock-in. For example, owning data centers and compute equipment is lock-in. Don’t think so??? Go out and buy some new servers this month and then tell your finance department you want the latest technology next year and you are going to toss the current gear (that you just bought) in the dumpster and move to the new stuff. Unless you can show some big ROI and take a few lumps, you are locked into that stuff until it’s fully depreciated... and don’t get me started about all that software you bought with a super low 5 year maintenance agreement. Lock-in is everywhere but you can go about it smartly and choose the lock-in where it makes sense. Now that we have multiple clouds that are starting to compete, we can get smart about some of our choices that make it easier to move to another cloud if that time comes. I want to touch on that “multi-cloud” topic but I’ll save that for my next article.
Stay on the best in class technology
I just mentioned that owning your own data center and associated equipment is lock-in. This sort of lock-in holds you back. At AWS 2015, Dorion Carroll, Zynga’s CIO, discussed always running two or three technology classes behind when they moved off of AWS to their own data center. Dorion mentioned that by the time Zynga moved to their own data center, AWS had already revisioned their technology a few times and Zynga was locked-in to their choice. In addition, now that Dorion has moved back to AWS, he doesn’t have to own and manage an IT R&D department for all of his infrastructure. AWS does all of the infrastructure R&D and testing for what the next technology should be for compute, storage, network and more. Now that Zynga is back on AWS, when there is a technology rev in servers, they just move with almost no cost. And from what I’ve seen, if you don’t need to switch to the latest tech, you reap the benefit of a price reduction by running on the older models. Dorion still needs to have some R&D but it’s higher up in the value chain.
Living in the cloud changes your business culture
Removing the constraints of time and quick scalability, the cost to experiment and take a chance on a new business idea gets cheaper. Many ideas are squashed at companies because of the cost to experiment because a failure meant they ended up with a pile of unused equipment. Also, before cloud, companies had to be selective on what equipment they chose because of the time involved. With the cloud, the time to deploy is in minutes, not months. Experimental failures result in lessons learned for the next experiment, not a bunch of useless hardware. CIOs tell me their companies think differently after moving to the cloud.
Cost Transparency
People make better decisions if they know what the costs are. For IT groups that that haven’t moved, their consumers usually have no idea what the total cost of ownership is. All of the companies I’ve spoken to, as well as companies I’ve worked at are are highly overprovisioned. If you roll your own data center, you have to be over provisioned to support peak & emergency demand, but there are other factors at play.
- Application teams always demand hardware that will support peak demand and a lot more. This is because it’s painful to miss calculate the amount of compute or storage an app will need, and as Mark Morgan says “no one wants to be the guy that gets woken up at 2AM to fix a poorly performing app.”. It’s even more painful to go back to the boss or the CFO and ask for more $$$. I’ve never seen an environment that rewarded teams for optimized system utilization, only solution delivery and availability. Because of this, most data centers are way over provisioned. In the cloud, if you underprovision, infrastructure as code can take over and auto-scale your environment just when it’s needed. When demand tails off, the infrastructure will automatically shrink along with associated costs. App owners are willing to reduce compute sizes because they know they can get it again later when needed.
- Teams will have multiple development environments, test environments, and performance environments, etc, and never really understand the cost of doing this.
- Nothing ever gets turned off. This is a big issue in some companies. I’ve seen instances where over 30% of running VMs could have been shut down and returned to the pool but weren’t. If the costs were shown back to the owners, they could more easily be incented to do the right thing and turn stuff off or deprovision when no longer needed. Well run organizations turn off environments or developer environments as soon as they are not being used but there’s a lot of overhead costs to get there and rarely are cost transparency tools helping drive that. Some companies make it so hard to get compute, developers don’t want to turn it back in to avoid the hassle and risk of getting it the next time. Going to the cloud can eliminate this behavior. In the cloud, provisioning is simpler and getting transparency to costs is easy, which should drive better behaviors.
- Virtual machines (VM) running on a clusters are seen as “sunk cost” like the hardware they are running on. As you should know by now, there are real hidden and on-going costs to running a VM farm. On-prem solutions don’t make it easy to turn VMs off when they aren’t in use. Sure, your initial cost for an VM cluster has already been made but not every project needs all of its environments running all the time. Most companies can’t afford to have every last application under development all the time. These VMs could be shut down, possibly avoiding another cluster purchase later, but it’s normally not self-service, nor is it easy to govern & automate.
- When I refer to costs, it’s not just compute and storage and labor. Network load balancers, databases and other assets are all part of the total cost of ownership (TCO). Without cost transparency, these all go un-noticed and normally way overprovisioned.
- Having a good configuration management database (CMDB) is hard to keep accurate. Without governance, process, and technology, and on-prem cost transparency is very difficult if not impossible without a well managed CMDB. In addition, keeping the CMDB up to date is expensive, time consuming and the least glamors job in IT.
If done right, running in the cloud can deliver total cost transparency. The most obvious is SaaS since the bill is typically tied to implementations or consumption, By moving your infrastructure to the cloud, it’s much easier to tie service costs to applications. There are several third party apps for AWS that use the tags on your resources to help you keep track of your total costs. In addition, by using infrastructure as code, companies can automate the tagging of all the resources for all of the environments they spin up. Furthermore, bounding applications within a sub-account for billing will catch just about everything that is used by an application. The only thing you need to account for over the direct costs are centralized shared services like IAM (identity and access services), dedicated network links, security, and management labor. This is leaps and bounds easier than working to implement soul crushing process to maintain a CMDB and then go and implement a full TBM or IT financial suite to pull it all together.
Speaking of automation, I’ve seen teams automate the monitoring and shutting down of underutilized resources and kill the cost of a derelict fleet. Not only are teams rewarded for only provisioning just what they need, they see the direct result immediately on the bill.
Not only does the cost transparency from the cloud drive better behavior, but the tooling in the cloud enables the automation of that transparency and cost savings.
Zero downtime upgrades and patching
In the cloud, you can easily afford to spin up a completely new environment for your upgrade or patching. Although many companies can apply “rolling updates” to a redundant infrastructure, it’s hard, takes a lot of coordination, and is fraught with issues. These days, IT rarely has enough spare infrastructure laying around to spin up a redundant deployment to cut over to once all the final testing is complete. In the cloud it’s standard behavior and if you implement all of your infrastructure as code, it’s easier. The bump in cost is only during the time where both environment are running. Once you’ve cut over to the new environment, the old one is shutdown. I know what you’re thinking, “What about the database?”. You may need to limit writes to the DB, depending on your architecture, but the cloud allows you to replicate your data tier and continue replicating, the updates on your current system and then cut over to the new DB when ready. In this case you have downtime, it’s just a lot smaller.
More consistent environments
“Infrastructure as code” is the new mantra in the cloud. Manually setup up infrastructure via a console and then going in to finish the install, configuring and tuning the system is so 1990s. Today, all of this is done in code and approached like any other software development project. Teams write, test, and check-in the code to do this like any other project. When the infrastructure code is ready, all of the various environments can be built. Teams constantly test their deployments like any other application until they get to production. Because all of this is done with code all of the environments should be completely in sync. If a team finds a problem, they just change the code and re-build all the environments.
Attract and retain the best talent
It engineers want to stay marketable. It’s hard to attract the best if your technology is still considered mainframeish. Technologist can see where things are going and know that if they want to stay marketable, they should develop their cloud skills. The bonus here is that a good portion of your staff won’t be resistant to the change, they will embrace it in order to build their skills for the future.
Next up.... Multi-cloud, everyone's doing it but why, and what are the considerations.
-- Chris Claborne
(aka Christian Claborne)
-- Chris Claborne
(aka Christian Claborne)
No comments:
Post a Comment