… and what new cloud providers should consider.
Been there, done that
…have the scars to prove it.
From my last 10 or so years I have worked for many of the major Telcos and a few of the smaller MSP’s, each one has tried in some way to “get into the cloud” and all have failed. While each had their own specific failures, all had a few of the same characteristics that seemed to be repeated.
4 Major Factors of Success
Initially let’s go over what seems to be some clearly outstanding factors of success in the current model of IaaS.
Cost vs Price
From my experience a cloud service is usually judged initially on price, even if not at first, it will eventually be a factor. This very issue came up for an unnamed video service a few years ago when their dev teams started turning in 500k Amex bills from AWS.
YOU MUST be able to architect a solution that provided WIDE margins in the cost per cycle equation. The markets going to squeeze you, it’s better to have juice in that lemon.
Tip: Before you even begin your design, build a Hz/$ calculator, ensure that all elements are accounted for (yes even DC space and cooling). Build 1 rack prototype, test your calculations against the rack, DO NOT EXPECT technology to get cheaper, cloud is all about memory and CPU, and CPU doesn’t get cheaper, you just get more of it. (while that SEEMS counterintuitive, you still have to pay to cool, and power it, and it’s still only a tiny fraction of cost compared to everything else)
Takeaway: If your server has a brand name on it that isn’t yours… You have a 99.999% chance of failure.
Access vs Simplicity
Its reasonable to assume that everyone wants their cloud application to look like their enterprise application… and they do, however there has been a major shift in the way compute is purchased. With this change something was missed, the network.
Allow me to explain:
A few months back a large entertainment firm (the largest actually) finally ended a LONG struggle between old IT and DevOps, old IT bought hardware, then carefully configured the connectivity, ensuring all security issues were considered, and then attached the SAN to the servers and finally releasing said servers to the Dev teams….
… who promptly requested a slew of security expectations and then put their internet platform on the servers, thus rendering all that work pointless. Eventually Devops folks won, and the Old IT was merged into the new way of thinking… now said firm is rebuilding most of its IT as an internal cloud.
Even those that do, would want to automate it, and for good reason, humans are prone to flaws, and while code can be tested to remove the flaws, no one can test out Bobs bad day at the office.
Takeaway: Build a service that is simple to initiate, simple to configure, and above all MUST BE able to automate all reasonable functions of the service with an API. COMPLEX NETWORK conditions will not work well with cloud services.
Think of it like this:
If you can’t explain the network cloud topology without a diagram….. you did it wrong.
Devops vs SecOps
What’s more important? Developers access to the services and their ability to automate them at will, or security?
With the expectation of a few companies (that public cloud will likely never win over)
Devops wins EVERYTIME
Do I mean that security isn’t important? No, that would be crazy. I mean to say that the idea that fort Knox level security in a cloud solution, to the point that a MSP is denying access to the cloud entity in a reasonable way either means that 1) it’s a poorly architected service 2) The security measures are not meaningful and will only cause a prevention of service.
I remind my team, that wire cutters ARE THE BEST firewalls on the market, because the stop every attack. Just cut the line to the router and you are good. However, they are the worst business enablement device a company could have. Security is a balance, access prevention is not security, it is a self-induced Denial of Service Attack.
Takeaway: API access does indeed open the client to some security issues, make sure you have VERY GOOD key auth, and beyond that, make sure your Web gateways are secure. Accessing console or desktops with multiple jump servers IS NOT conducive to a well rendered service. Above all, think of your service as a luxury car dealership, stop making your client feel like he is entering thru the garage door of Billy bob’s autobarn.
Product vs Ecosystem
I remember a few years ago when people made fun of Steve Ballmer for his “developers, developers, developers” rant… man I hate to admit it, but was he right, and in the cloud space it’s never been more true.
Flash Quiz: What came first AWS Marketplace or community AMI Public repos?
That’s right, community AMI or basically images that ran directly on AWS were KEY to making AWS the leader in cloud. AMI packages just worked. Developers didn’t have to think about anything beyond what they were supposed to do, no installer, no network config… just worked.
This led to a HUGE business model where AWS makes 15% (citation needed) and in return does ALL of the retail fulfillment and clearinghouse. What’s more, they also provide a reason to exist as an entity.
With this model what does a company need to successfully launch, sell, and maintain a service?
Well ask druva.com… …Developers, developers, developers
Takeaway: A successful cloud service is much more than just a few servers and a barebones hypervisor, it’s an ecosystem than feeds its own infrastructure, has a purpose outside of itself to sustain its cost, and provides a use model that is focused on its user base. Furthermore, it can’t just exist, it needs to have a reason, and it needs to have a community that WANTS it to exist. While that seems hard, it’s not as hard as it seems.
In the next section we will explore how Telco’s, and MSP’s did not follow that model, and how it failed them.