Businesses Moving From Amazon's Cloud To Build Their Own 121
itwbennett writes "There are rumblings around this week's OpenStack conference that companies are moving away from AWS, ready to ditch their training wheels and build their own private clouds. Inbound marketing services company HubSpot is the latest to announce that it's shifting workloads off AWS, citing problems with 'zombie servers,' unused servers that the company was paying for. Others that are leaving point to 'business issues,' like tightening the reins on developers who turned to the cloud without permission."
Re:Nor surprising and won't matter. (Score:5, Interesting)
Re:The obvious next step... (Score:4, Interesting)
Why is there *always* a snarky comment along these lines whenever someone talks about not using a "public" cloud provider - cloud when talked about in these ways does not mean "someone else owns the hardware", it means "an infrastructure setup which means I do not have to care about the infrastructure when deploying applications", whether that be owned by someone else or an internally provided solution.
The old manner of inhouse application infrastructure involved one or more application server, one or more database server, and the related network and service architecture specifically required to handle redundancy and failover - but the point is, you had to care about that service architecture when dealing with your app! Which server had spare resource to act as a failover for another application (which invariably meant you ended up with two servers allocated for the job anyway, the main and a dedicated backup or two servers which took requests on a round robin manner), which server was not to be used for these purposes, which applications do not live together etc etc.
Today, the goal is to have a "large number of essentially commodity hardware servers" acting on a level which you can forget about for most solutions (there are always going to be situations where heavily tailored hardware solutions will still exist) - where you can treat the hardware as what it should be, a resource to be used and allocated as required.
Virtualisation was the first step (in modern terms, not talking about mainframes here), and cloud takes the aspect of virtualisation several steps down the road.
This has got sod all to do with the "cycle", and everything to do with "computing as a resource".
Re:Nor surprising and won't matter. (Score:2, Interesting)
we use Azure for a lot of things in my particular department because it helps us bypass our IT department. Sometimes we need to set stuff up really fast and only have it last for a short amount of time. It takes our IT department about a week to open ports on our firewall or map a machine to an IP....when we have 2 days to get something working this doesn't work. As far as cost goes...it isn't all that much more expensive than handling the hardware ourselves. I can also, on the fly, scale things up as I need to. It's a lot easier than buying ram...shutting down the server...getting someone to put the RAM in since I don't have access to NOC. Works perfectly for our needs. I can also run a ton of test web sites for free with Azure and then move them to production as I need to. If they stay under a certain barrier then I don't get charged for them at all since the first like 5 gig of traffic is free once I move it to a dedicated resource. Trying to do this traditionally wouldn't work for us at all...and would make things even worse.
Your mileage may vary.
Re:Nor surprising and won't matter. (Score:4, Interesting)
The defining factor is whether you can keep more than one IT guy busy full time. If you can, then you hire at least two, one senior and one junior to at least fight fires when he's sick. If you're keeping at least two IT buys busy full time, you're going to be paying for them whether they work for you or not, but if they do work for you then you can fire them, so you have some control over what they do. If they'll just be placed with someone else if you don't like them, they're not going to work as hard for you. You need as much control as you can get over your own IT department. It's daft to contract out anything so critical when you're only adding to the likelihood of leaks and malfeasance.
cowboys like you (Score:5, Interesting)
I've reined in cowboys like you for years, from one fortune 500 to another. Arrogant jackasses that can't be bothered with change management, best practices, version control, documentation, pesky things like policies, regulations and laws. Self righteous developers that can't see past their own nose too see how thier actions or inactions affect those around them.
Every single time they think they are above these things and that they know better than the industry around them. They never realize why something that works in their special environment works perfectly fine where they have the rights of a God but has all kinds of mysterious errors in production where there they are brought back down to earth. They then chafe when their development environment is set up identical to production, yet it is amazing how quickly previous mysterious bugs that plagued production and caused incredible operational costs suddenly get fixed. They of course never have to clean up multi-million dollar messes, talk to regulatory agencies, sit down with lawyers to plan how to mitigate their mess or have a face to face with an angry Attorney General.
I've only won this argument and helped companies save millions by reining in the cowboys like yourself a couple dozen times. Probably something to do.with cleaning up large multi-million dollar messes more than once.
Random pricing (Score:4, Interesting)
Plus as a human I really like being able to reach out and touch my machines, even if I have to fly 5 hours to do it. So the flexibility of the cloud sounds really cool where the pricing is not so flexible. It would be nice to spool up an instance of a machine that isn't going to do much most of the time that doesn't actually use up a whole machine. But then when one machine starts to get pounded to give it some more juice. Plus upgrading your hardware would be much more of a dream. You move your most demanding servers to your hottest hardware and slide the idle servers over to the older crap. Plus restores and redundancy are a dream.
Then you still have the option to fully dedicate a machine in "realspace" to a demanding process. While VM does not have much overhead it does have some. So taking a server(s) that is being pushed to the maximum and sliding it onto bare metal will then allow your hardware to be used to maximum efficiency.
Then by having no real cost overhead to having more near idle machines spool up your developers can play interesting games. Maybe they want to see what your software will do with 20 MongoDB servers running instead of the current 3; or 200.
This all said, I am a fan of Linode; where I can predict my pricing very well.
Re:Nor surprising and won't matter. (Score:5, Interesting)
neither does amazon unless you pay them a lot more $$$
Depending on your needs, setting up geographical redundancy with Amazon can be extremely cheap -- if you just want a cold or warm site to fail over to, you don't need to keep your entire infrastructure running at the secondary site, just replicate the data, and then spin up the servers over there when you need to fail over.
That's what my company does - we have about a dozen servers to run our website, but the secondary site has only a couple micro instances to receive data. When we need to failover, we just tell one of those servers to wake up the rest of the infrastructure and update the databases from the snapshots that have already been transferred over, including repointing DNS to the backup site. We could make the failover fully automatic, but are afraid of "split brain syndrome" leading to the failover site taking over when the primary is still fine so it's still a manual process. Our backup site is never more than 15 minutes out of date from production.
This has worked well in testing - we've done some "live" late-night failovers and it's relatively seamless -- since it's so cheap to set up the backup site (essentially we just pay for the cost of storage at the backup site), we're going to set up another region overseas for extra redundancy.
Re:Nor surprising and won't matter. (Score:5, Interesting)
Depending on your needs, setting up geographical redundancy with Amazon can be extremely cheap
And history has shown that you pay for what you get.
Right, if you cheap out and pay for a single availability zone in a single region, when that AZ or Region goes down, your site is down.
If you pay for multi-AZ and Multi-region deployments you get much better availability.
Just like Amazon says.
Over the past 2 years, Amazon has been more reliable than the coloc we moved away from, mostly due to the triple (!) disk failure that took out our SAN RAID array - one disk failed, and while we were waiting for the replacement, another disk went down, after we replaced those two, another disk went down while rebuilding the RAID-6 array.
With AWS, an entire region can go offline and we can bring up the backup site on the other side of the country (or, starting next month, we could bring up our Ireland region).
All this for less than half the cost we were paying for the coloc + equipment maintenance.