Microsoft must be minting money from their subscription and Azure services. We replaced three servers with Office 365 online and Azure virtual machines and Azure AD. It has several advantages but cost is not one. Anyone that says moving to the cloud saves you money is likely wrong.
If you're just replacing hardware, yeah, cost isn't an advantage. Because you still have your datacenter (or not enough hardware to have ever required one), you still have your IT department (or not enough systems to have ever required one), you still have to have your devops team (or not enough software/instances to have ever require one), etc.
The advantage of a lot of these is that you don't need any of that. You can have just a dev team, nothing else, and be up and running at any scale. At that point cost comparisons may come out in favor of a cloud solution (or at any rate are so close that the tradeoffs become acceptable, hence their popularity)
> You can have just a dev team, nothing else, and be up and running at any scale.
Has anyone done this in practice at significant scale? Every shop I know of with a big cloud deployment has armies of devops people managing the deployment, and further reserve armies on pager-duty standby in case something blows up. They're certainly doing different things than if you had an in-house datacenter (less hardware maintenance, more cloud orchestration), but I'm not convinced the sysadmin/devops headcount has actually gone down.
There are plenty of examples at this point. A few I can think of off the top of my head -
TwitPic relied on it and operated as basically a one or few person shop the entire time. At the peak, before Twitter came up with their own solution, it was a relatively large service.
Instagram, Imgur, and Reddit all had/have (Instagram of course moved to FB) small teams operating at vast scale with the help of AWS.
Slack has probably benefited a lot from leaning on AWS for scaling purposes, given their rapid growth. I'd place a bet that they have managed to achieve their scale with a relatively small team managing their infrastructure.
You mean Imgur and Reddit that keep going down and have always been notoriously bad at staying up? Not a good example at all.
Also Twitpic didn't reduce their sysops, they simply kept it low, AWS didn't do that, a server which serves much more complex stuff and many more people than twitpic can be run by one person, see stackoverflow.
There are a lot of people out there who don't realize what can be done with one or two dedicated servers and one or a handful of good developers without ever mucking around with cloud. Cloud can just add yet another point of failure to a small business if it wasn't worth it in the first place.
If you're just using a cloud provider as a remote VM farm, you'll still need devops, sure.
If you're using an automatic container scaling solution, such as AWS' Elastic Beanstalk, you can still benefit from devops, but I'd argue you don't need it; all the difficulty resides in structuring your application to be able to handle that environment, a problem for your software devs. The devops burden is low, and the time to communicate what a developer needs to the devops is likely going to trump the time taken for the developer to just do it.
If you're looking to use a containerless solution using cloud resources (like AWS' Lambda, API Gateway, and Dynamo to create a CRUD app), you don't need devops. All your difficulty resides in reducing and/or handling state between functions (well, and any other shortcomings in the actual implementation of the service); again, a software problem.
Basically, Amazon, at least (what I have the most experience with) seems to be looking to remove the need for devops by creating standard workflows and mechanisms to bind services together with arbitrary code, and to be able to inherently scale out. The remaining devops burden is sufficiently small, and so tightly integrated with the nature of the software involved, that it's oftentimes more effective to just have the devs handle it. While sufficient amounts of code might turn that into a devops role, what I meant by scaling out is a particular app handling a given amount of load. In a classical datacenter environment, moving from an app on one box to an app that spans many is something both the software devs and devops have to concern themselves with, but in the cloud it's mostly just a dev consideration; if the app is written to handle multiple copies of itself, spinning up those extra copies should be close to if not actually trivial. That was all that I was saying; the move from one to many doesn't require devops any longer, as "how do I make sure all of these boxes are set up properly, get deployed onto, are kept in sync, load is shared between them, etc" are problems that cloud providers have provided tools to solve, and what they leave out doesn't require dedicated devops to address.
I'm not saying you can't run a large business in the cloud, what I'm skeptical of is whether you can run a large business in the cloud without devops staff, having only developers while the cloud 100% takes care of devops for you.
That's not how I interpreted the comment you responded to. I thought it meant that you didn't mean IT staff, which is true. When you use cloud services, someone else is yanking dead drives and replacing them, someone else has a 24/7 on-call rotation for dealing with power outages and fiber cuts, someone else is responsible for hardware at all levels and lower-level software stuff. That's how I understood that comment.
Now you're talking about DevOps, which is short for Development Operations, which is a developer role, not an IT role. DevOps people automate your buildchain and that kind of stuff. No one is saying that using cloud services means you don't need DevOps, though there are some cloud services that will handle at least part of what is traditionally in the realm of DevOps for you.
Hiya. One of the authors of the article here. We also reported this week that Azure alone likely did about $400m in revenue for Microsoft in June quarter, versus for Amazon on $1.8 billion. http://www.bloomberg.com/news/articles/2015-10-23/microsoft-...
Not alone there, Microsoft is especially expensive for what you actually get but the more common players such as AWS and Rackspace are highly cost ineffective in many situations. I really wish people would stop calling it 'the cloud' and call it what it is 'outsourced hardware'.
And a whole bunch of other capabilities. My company couldn't exist if we had to buy & configure our own servers, storage, switching, load balancers, databases, monitoring &c. Characterising the AWS & Azure clouds as "outsourced hardware" demonstrates a real lack of awareness of the services that are available. As a third-party offering, they are about as far from old-style mainframe bureau computing as you can get, in every dimension from the architectural to the commercial.
Cloud computing means the entire DC is programmable, and I use it as such.
Moreover the unprecedented level of automation means I can spend a lot more time on creating customer value rather than faffing around with admin. The shift I've seen in the last three decades* has been phenomenal. Teams aren't smaller but they are vastly more productive.
If you host your own servers or even PaaS wherever, and you don't have an API and automation framework then yes - you will see benefits from having those things provided to you. If you already have these things and you're not spending a lot of time to make sure they continue to exist then you have a lot more freedom than locking into the tools that your 'cloud' provider has given you.
What lock-in? I'm deploying standards-based applications to standards-compliant platforms. Cloud services are simply saving us heaps of time & money. There's no loss of freedom, far from it; the disposability of cloud infrastructure provides enormous opportunity for adaptation and change.
In 100% of my experience to date, "cloud lock-in" is a myth trotted out by server huggers and hardware salesmen. Some SaaS providers may be data prisons, sure, but that's a different conversation.
If the economics of establishing and operating off-cloud resources ever made sense for us, we'd go for it, but it looks increasingly unlikely.
One example of that I've seen have spent significant time on tools like cloudformation can only (as far as I know) be used on AWS. Another would be where when you need decent storage performance - we have several cases where we use 20-40K IOP/s quite easily and doing that kind of work on the current cloud offerings is very expensive and usually involves significantly increase complexity if say you need this in your database layer as you suddenly have the need to scale horizontally while maintaining consistency and durability which is difficult. We can provision 6TB of networked 1M 4K random read IOP/s storage in a highly redundant, load balanced form that's easy to upgrade and scale for less than $500/month and it has little to no management overhead. Now while this may not be what your average startup requires it opens up a world of opportunity to how and what you do with your data.
Edit: I should note that we do, where appropriate use 'cloud' services including Rackspace, AWS and Azure where appropriate. Azure has had significant performance issues and has a lot of provable downtime especially due to internal network routing and DNS problems that they fail to acknowledge and we've found their support to be a joke if you know what you need / are doing, even their own O365 service has weekly outages that can take several minutes to resolve. Rackspace's support has been good but they do have a lot of small outages again often network related. AWS' has been alright be very costly unless you're doing either very small deployments or at the other end of the scale massive, horizontally scalable deployments, however their storage performance is woeful. For our mission critical or high performance deployments using our internally hosted platform is significantly fast and almost always cheaper. Our uptime across the platform is fantastic and it generally 'just works' while we watch our cloud hosted services suffer from inconsistent performance and service 'blips'.
Huh? Networked I/O at 1M random iops for $500/month? I feel like at least one of these numbers is off. Can you detail your setup a bit more? How many machines or drives are you striped across and how much of your 10gige link are you assuming you can dedicate to this?
(I'm genuinely curious but I feel like there's a missing upfront cost that's not being included here)
True for cloudformation , when spinning up multicloud systems it pays to invest in a tool like terraform.Currently we are running a hybrid Google Cloud AWS deployment and it helps to keep the infrastructure consistent.
Ever used spot instances? If you use "cloudy" strategies and shop your work to the cheapest AZ's, and only run the jobs when the spot price is right, you can run some pretty nice instances on AWS for cheaper than any other provider. However, if you just want a rack of servers running 24/7, regardless of utilization, you might as well go back to the colo.
Compared to what? Running a rack of servers? Sure. Running a 3 datacentre presence with low latency interconnect and enough spare capacity to deal with failure? I'm not so sure.
Some times people do, often they don't. We learnt that dealing with 3rd party vendors is a very time consuming and costly ordeal, especially when you realise that they don't care about your business, only about your money.
