5 ms·

You have some really good points, but your premise is simply not based in reality. You're painting the picture as if AWS is the 2nd version of the IBM saying:

by mbesto 5y ago

You have some really good points, but your premise is simply not based in reality. You're painting the picture as if AWS is the 2nd version of the IBM saying: "No one ever got fired for using AWS". This is simply not true...at least not the part where "IBM" (i.e. AWS now) is somehow inferior to the competition. > If you are large enough to need to build your own datacenter instead of renting floorspace for pennies on the dollar from Switch or Equinix (although Equinix is kind of pricey) or Windstream or insert provider - then the datacenter is a rounding error in your 10-year IT budget. Then you clearly don't understand the TCO of using a data center vs cloud. The datacenter cost itself isn't the cost - the people who operate it are. On a computing resource basis can you operate SQL Server on a rack in Equinix for cheaper than that in AWS? Sure, but who is going to pay for the person to patch it every week, or upgrade it to the latest version, or upgrade the SAN disk, or upgrade the hardware every 3 years, etc. etc. Let's take this a step further - who is going to hire these people? And fire them? And train them? These are all transactions costs that get hidden in the "$0.20/hr cost" of spinning up an EC2 instance. If you think cloud computing it's just about a lift and shift from a traditional data center, then you don't understand how to calculate TCO. P.S. - For the record, many large internal IT groups do in fact do simple lift and shifts from traditional data centers and don't fully realize the value of cloud computing resources. However, these companies will usually mature eventually and evolve services to ones that are more advantageous (i.e. setup SQL Server on EC2 and the migrate to RDS). AWS (et al) have the ability to do this with ease.

pbalau 5y ago
> On a computing resource basis can you operate SQL Server on a rack in Equinix for cheaper than that in AWS? Sure, but who is going to pay for the person to patch it every week, or upgrade it to the latest version, or upgrade the SAN disk, or upgrade the hardware every 3 years, etc. etc. Let's take this a step further - who is going to hire these people? And fire them? And train them? These are all transactions costs that get hidden in the "$0.20/hr cost" of spinning up an EC2 instance. Who cares? This is IT and is not relevant. And they have Brent and he will solve everything.
stuff4ben 5y ago
Surely for any company of size you understand there will still be people managing the AWS infra. Having tens to hundreds of small dev groups go at it willy nilly is a recipe for disaster and overspending. Someone still has to patch the server instances, manage the people who access it, train them on how to use AWS, etc. Those costs don't go away because you've moved to the cloud.
- mbesto 5y ago
  > Those costs don't go away because you've moved to the cloud. Sure, but you can go from "I have 5 people managing my 150 instances of SQL Server" to "I have 1 AWS sys admin". The point wasn't that the costs are eliminated, it's that they are baked in.
- NineStarPoint 5y ago
  Generally at big companies you needed people to manage the infrastructure, and people to manage the layer on top of that infrastructure though. With clouds you can consolidate those groups into one group that is smaller. I think Cloud still costs more overall, never been convinced it actually saves money. I do think it tends to increase developer velocity though, and that can be worth it.
acdha 5y ago
> If you think cloud computing it's just about a lift and shift from a traditional data center, then you don't understand how to calculate TCO. This is especially true for more than basic services. If all you need is a bunch of Linux servers, sure, you can find people who will keep them patched for you without too much trouble (although it'll almost certainly turn that “rounding error” into a serious number) but once you start building things which are higher level with legitimately hard problems to solve and need to have good solutions for all of the monitoring, security, ops, etc. needs that staffing becomes harder and you're going to have to sell your executives on the idea that the best use of your expensive A-team is cloning S3, Lambda, etc. when you can get that benefit immediately without a massive up-front payment and have the same people working on a strategic benefit.
- ryanjkirk 5y ago
  > cloning No need to clone; all of this already exists. Take a look at CNCF.
  - acdha 5y ago
    I'm trying to be charitable here, can you expand on that and explain why that's not an invalid comparison? For example, the word immediately after your quote was “S3”. That's not something the CNCF can solve for you since one of those is a service and the other is an application you can run — at the very least you need an _extensive_ ops and security if you're relying on it as much as S3 – and, assuming you're talking about Rook, you're comparing it to one of the largest, highest-scaling services in existence but here's what you're on the hook to do if you do it yourself: * Kubernetes * High-level storage services: Ceph, Cassandra, NFS * Lower-level storage for whatever you pick for the previous point Each of those, and the combined service you build, needs staffing for operations, monitoring, security, etc. support. If you follow any security standards or are in a regulated industry, you're on the hook for documenting compliance on all of those, too, especially if you need to be able to demonstrate things like immutability. You certainly can do this but that's a number of full-time jobs requiring expertise. If you have enough storage usage you can potentially justify the savings over the rates you'd be able to negotiate but that's a big up-front cost which you hope but are not guaranteed to recoup.
jjoonathan 5y ago
You still need the IT team to babysit the AWS infrastructure. I've seen this "even a lift-and-shift reduces TCO" argument before, but it only ever works if you pretend that AWS lives up to its zero-management hype. Maybe, for someone, it does. Not for any deployment I've seen. This never prevents management from pretending, of course. EDIT: ah, I've seen that the argument has retreated to "it reduces IT headcount." Again, maybe for someone, but I have yet to see it actually work, and every time management has just hustled the TCO calculation.
- acdha 5y ago
  > You still need the IT team to babysit the AWS infrastructure. … it only ever works if you pretend that AWS lives up to its zero-management hype. Who is saying zero-management? If you have a consultant lying to you, that's not a cloud problem and I've heard the same people lie about all kinds of on-premise services as well. What I've heard the major cloud providers say is true: you need _less_ staff and you can spend time on different things, which has been generally true. For example, instead of needing to configure a bunch of network hardware (which is a distinct skill you need to hire) you can have a general devops person use Terraform to manage routes, firewall rules, etc. without also needing to be a Cisco expert and spending time operating the underlying hardware. The key question to ask is where your infrastructure was to start with. If you have an A-grade ops team, a lift-and-shift will probably not be much of a cost savings because you presumably already have economies of scale working in your favor, unless you have enough bursty workloads to pay for it that way. The catch is that most places do not have that high-end ops capacity so what you're really doing is taking your limited IT capacity and reclaiming the time which is currently going into things like managing Dell firmware updates.
ryanjkirk 5y ago
> who is going to pay for the person to patch it every week, or upgrade it to the latest version, or upgrade the SAN disk, or upgrade the hardware every 3 years, etc. etc. Let's take this a step further - who is going to hire these people? And fire them? And train them? These are all transactions costs that get hidden in the "$0.20/hr cost" of spinning up an EC2 instance. You're implicitly arguing that NoOps is not only a functional model, but also scalable and much less costly than having a {Dev|Sec}Ops staff. The last time this was publicly debated between Adrian Cockcroft and John Allspaw, it was immediately obvious to everyone that there is no such thing as NoOps. You can have developers support their own apps in production on the cloud, but that takes away time from developers and comes with its own set of downsides (most prominently, a disinterest in what they consider mundane or boring). Once your developers are spending, in aggregate, more than 40 hours a week do ops work, you'll gain efficiency by hiring a DevOps Engineer whose entire career focus is all the things developers aren't typically great at. I've seen this in-person as an employee at medium, large, and a Fortune 50 business. I haven't yet seen a single app, not even serverless, that requires zero maintenance. I have also seen highly-distributed, performant apps run on cheap hardware with no SAN or VMware to drive up the cost and complexity. That same app, made up of mostly microservices, was much more expensive to run on on the cloud. You might want to stop throwing around terms like TCO when you also clearly don't understand how to calculate it. I'm starting to be of the mindset that us-east-1 is already "Too Big To Fail". I guarantee you that conversations are being had in boardrooms right now about how to reduce dependency on that region, if not AWS entirely.
- mbesto 5y ago
  > You're implicitly arguing that NoOps is not only a functional model, but also scalable and much less costly than having a I'm not. You implied too much. > You might want to stop throwing around terms like TCO when you also clearly don't understand how to calculate it. I do. I never said that people were completely eliminated (see one of my child comments). Everything you implied was that "well devs are doing the effort and that doesn't get calculated". That wasn't my argument - you just added that nuance as a retort. > I guarantee you that conversations are being had in boardrooms right now about how to reduce dependency on that region, if not AWS entirely. I guarantee you they are not. Also, how many data center providers let you simply spin up your whole environment into another region, point n click, and complete it in hours? Source - work with 100+ companies with PE folks that sit on boards.
tw04 5y ago
>Then you clearly don't understand the TCO of using a data center vs cloud. The datacenter cost itself isn't the cost - the people who operate it are. I guess I find that a bit humorous. I've been architecting solutions that span on-premises and cloud for nearly a decade so I'm intimately familiar with both. I don't actually have a horse in the race. You want cloud, buy cloud, you want on-prem, buy on-prem. But the marketing about one-size-fits-all is EXTREMELY tiresome. And the idea that every single business can or should be moving their entire infrastructure to the cloud is as well. The fact you imply that somehow you don't need people to manage the cloud makes me seriously question what at-scale deployments you've been a part of. I have yet to see a single enterprise customer save money on staff by moving to the cloud. More often than not what they end up doing is laying off the "tape jockey" and replacing him with an SRE who costs 3x the salary. Congratulations? Now you're paying more for an SRE, and you're backing up to S3 at about 5x the cost of what you were spending on tape? But I guess the 7 years of backups you're legally obligated to keep are more agile? >If you think cloud computing it's just about a lift and shift from a traditional data center, then you don't understand how to calculate TCO. I don't think the concept of cloud computing is lift and shift and never said it was. But that's not really relevant to OP's question, what is relevant is what's happening on the ground. What's actually happening is that most established businesses "moving to the cloud" are lifting and shifting and finding out the hard way. I'm not saying that's what they should do, I'm not saying that's at all a good idea, I'm telling you that is what is happening. And if you think "well they'll mature into a more cloud friendly model" - you're as delusional as their management. What ACTUALLY happens is after they lift and shift and get a year's worth of those bills, they lift and shift the stuff that never should've been in the cloud in the first place back on-premises. Hopefully by that point they've learned their lesson and have a thoughtful evaluation of their applications: re-home, re-write, leave in place.
- mbesto 5y ago
  > But the marketing about one-size-fits-all is EXTREMELY tiresome. And the idea that every single business can or should be moving their entire infrastructure to the cloud is as well. 100% agree. Didn't mean to imply this. As with anything....it depends.

by mbesto 5y ago

pbalau 5y ago

> On a computing resource basis can you operate SQL Server on a rack in Equinix for cheaper than that in AWS? Sure, but who is going to pay for the person to patch it every week, or upgrade it to the latest version, or upgrade the SAN disk, or upgrade the hardware every 3 years, etc. etc. Let's take this a step further - who is going to hire these people? And fire them? And train them? These are all transactions costs that get hidden in the "$0.20/hr cost" of spinning up an EC2 instance. Who cares? This is IT and is not relevant. And they have Brent and he will solve everything.

stuff4ben 5y ago

Surely for any company of size you understand there will still be people managing the AWS infra. Having tens to hundreds of small dev groups go at it willy nilly is a recipe for disaster and overspending. Someone still has to patch the server instances, manage the people who access it, train them on how to use AWS, etc. Those costs don't go away because you've moved to the cloud.

mbesto 5y ago
> Those costs don't go away because you've moved to the cloud. Sure, but you can go from "I have 5 people managing my 150 instances of SQL Server" to "I have 1 AWS sys admin". The point wasn't that the costs are eliminated, it's that they are baked in.
NineStarPoint 5y ago
Generally at big companies you needed people to manage the infrastructure, and people to manage the layer on top of that infrastructure though. With clouds you can consolidate those groups into one group that is smaller. I think Cloud still costs more overall, never been convinced it actually saves money. I do think it tends to increase developer velocity though, and that can be worth it.

acdha 5y ago

> If you think cloud computing it's just about a lift and shift from a traditional data center, then you don't understand how to calculate TCO. This is especially true for more than basic services. If all you need is a bunch of Linux servers, sure, you can find people who will keep them patched for you without too much trouble (although it'll almost certainly turn that “rounding error” into a serious number) but once you start building things which are higher level with legitimately hard problems to solve and need to have good solutions for all of the monitoring, security, ops, etc. needs that staffing becomes harder and you're going to have to sell your executives on the idea that the best use of your expensive A-team is cloning S3, Lambda, etc. when you can get that benefit immediately without a massive up-front payment and have the same people working on a strategic benefit.

ryanjkirk 5y ago
> cloning No need to clone; all of this already exists. Take a look at CNCF.
- acdha 5y ago
  I'm trying to be charitable here, can you expand on that and explain why that's not an invalid comparison? For example, the word immediately after your quote was “S3”. That's not something the CNCF can solve for you since one of those is a service and the other is an application you can run — at the very least you need an _extensive_ ops and security if you're relying on it as much as S3 – and, assuming you're talking about Rook, you're comparing it to one of the largest, highest-scaling services in existence but here's what you're on the hook to do if you do it yourself: * Kubernetes * High-level storage services: Ceph, Cassandra, NFS * Lower-level storage for whatever you pick for the previous point Each of those, and the combined service you build, needs staffing for operations, monitoring, security, etc. support. If you follow any security standards or are in a regulated industry, you're on the hook for documenting compliance on all of those, too, especially if you need to be able to demonstrate things like immutability. You certainly can do this but that's a number of full-time jobs requiring expertise. If you have enough storage usage you can potentially justify the savings over the rates you'd be able to negotiate but that's a big up-front cost which you hope but are not guaranteed to recoup.

jjoonathan 5y ago

You still need the IT team to babysit the AWS infrastructure. I've seen this "even a lift-and-shift reduces TCO" argument before, but it only ever works if you pretend that AWS lives up to its zero-management hype. Maybe, for someone, it does. Not for any deployment I've seen. This never prevents management from pretending, of course. EDIT: ah, I've seen that the argument has retreated to "it reduces IT headcount." Again, maybe for someone, but I have yet to see it actually work, and every time management has just hustled the TCO calculation.

acdha 5y ago
> You still need the IT team to babysit the AWS infrastructure. … it only ever works if you pretend that AWS lives up to its zero-management hype. Who is saying zero-management? If you have a consultant lying to you, that's not a cloud problem and I've heard the same people lie about all kinds of on-premise services as well. What I've heard the major cloud providers say is true: you need _less_ staff and you can spend time on different things, which has been generally true. For example, instead of needing to configure a bunch of network hardware (which is a distinct skill you need to hire) you can have a general devops person use Terraform to manage routes, firewall rules, etc. without also needing to be a Cisco expert and spending time operating the underlying hardware. The key question to ask is where your infrastructure was to start with. If you have an A-grade ops team, a lift-and-shift will probably not be much of a cost savings because you presumably already have economies of scale working in your favor, unless you have enough bursty workloads to pay for it that way. The catch is that most places do not have that high-end ops capacity so what you're really doing is taking your limited IT capacity and reclaiming the time which is currently going into things like managing Dell firmware updates.

ryanjkirk 5y ago

> who is going to pay for the person to patch it every week, or upgrade it to the latest version, or upgrade the SAN disk, or upgrade the hardware every 3 years, etc. etc. Let's take this a step further - who is going to hire these people? And fire them? And train them? These are all transactions costs that get hidden in the "$0.20/hr cost" of spinning up an EC2 instance. You're implicitly arguing that NoOps is not only a functional model, but also scalable and much less costly than having a {Dev|Sec}Ops staff. The last time this was publicly debated between Adrian Cockcroft and John Allspaw, it was immediately obvious to everyone that there is no such thing as NoOps. You can have developers support their own apps in production on the cloud, but that takes away time from developers and comes with its own set of downsides (most prominently, a disinterest in what they consider mundane or boring). Once your developers are spending, in aggregate, more than 40 hours a week do ops work, you'll gain efficiency by hiring a DevOps Engineer whose entire career focus is all the things developers aren't typically great at. I've seen this in-person as an employee at medium, large, and a Fortune 50 business. I haven't yet seen a single app, not even serverless, that requires zero maintenance. I have also seen highly-distributed, performant apps run on cheap hardware with no SAN or VMware to drive up the cost and complexity. That same app, made up of mostly microservices, was much more expensive to run on on the cloud. You might want to stop throwing around terms like TCO when you also clearly don't understand how to calculate it. I'm starting to be of the mindset that us-east-1 is already "Too Big To Fail". I guarantee you that conversations are being had in boardrooms right now about how to reduce dependency on that region, if not AWS entirely.

mbesto 5y ago
> You're implicitly arguing that NoOps is not only a functional model, but also scalable and much less costly than having a I'm not. You implied too much. > You might want to stop throwing around terms like TCO when you also clearly don't understand how to calculate it. I do. I never said that people were completely eliminated (see one of my child comments). Everything you implied was that "well devs are doing the effort and that doesn't get calculated". That wasn't my argument - you just added that nuance as a retort. > I guarantee you that conversations are being had in boardrooms right now about how to reduce dependency on that region, if not AWS entirely. I guarantee you they are not. Also, how many data center providers let you simply spin up your whole environment into another region, point n click, and complete it in hours? Source - work with 100+ companies with PE folks that sit on boards.

tw04 5y ago

>Then you clearly don't understand the TCO of using a data center vs cloud. The datacenter cost itself isn't the cost - the people who operate it are. I guess I find that a bit humorous. I've been architecting solutions that span on-premises and cloud for nearly a decade so I'm intimately familiar with both. I don't actually have a horse in the race. You want cloud, buy cloud, you want on-prem, buy on-prem. But the marketing about one-size-fits-all is EXTREMELY tiresome. And the idea that every single business can or should be moving their entire infrastructure to the cloud is as well. The fact you imply that somehow you don't need people to manage the cloud makes me seriously question what at-scale deployments you've been a part of. I have yet to see a single enterprise customer save money on staff by moving to the cloud. More often than not what they end up doing is laying off the "tape jockey" and replacing him with an SRE who costs 3x the salary. Congratulations? Now you're paying more for an SRE, and you're backing up to S3 at about 5x the cost of what you were spending on tape? But I guess the 7 years of backups you're legally obligated to keep are more agile? >If you think cloud computing it's just about a lift and shift from a traditional data center, then you don't understand how to calculate TCO. I don't think the concept of cloud computing is lift and shift and never said it was. But that's not really relevant to OP's question, what is relevant is what's happening on the ground. What's actually happening is that most established businesses "moving to the cloud" are lifting and shifting and finding out the hard way. I'm not saying that's what they should do, I'm not saying that's at all a good idea, I'm telling you that is what is happening. And if you think "well they'll mature into a more cloud friendly model" - you're as delusional as their management. What ACTUALLY happens is after they lift and shift and get a year's worth of those bills, they lift and shift the stuff that never should've been in the cloud in the first place back on-premises. Hopefully by that point they've learned their lesson and have a thoughtful evaluation of their applications: re-home, re-write, leave in place.

mbesto 5y ago
> But the marketing about one-size-fits-all is EXTREMELY tiresome. And the idea that every single business can or should be moving their entire infrastructure to the cloud is as well. 100% agree. Didn't mean to imply this. As with anything....it depends.