6 ms·

I can't agree with this at all. It is entirely practical to configure bare metal or virtualized systems yourself. There are so many wonderful tools to do whatev

I can't agree with this at all. It is entirely practical to configure bare metal or virtualized systems yourself. There are so many wonderful tools to do whatever you want. It will cost less and is usually more performant, especially when you avoid the biggest cloud players.

ClumsyPilot 5y ago
Its certainly possible, but it requires a level of discipline and commitment thats usually missing at larger organisarions. In some firms they still struggle with basics, like staff with 200k salary get a terrible slow pc/ crap monitors, etc.
- dsr_ 5y ago
  There are no slow desktop computers in 2022. There is a lot of slow software running on fast computers.
  - ClumsyPilot 5y ago
    Haha, you ain't seen nothing yet! An mayor accounting firm stulkl has some devs on ancient macbooks with HDDs!
TameAntelope 5y ago
Good lord I could not more strongly think the opposite. It’s a massive resource sink for anything of even modest scale, and in my experience it’s literally been 10x the overall cost, with many, many fewer 0s of uptime guaranteed.
- Underphil 5y ago
  I think the truth is somewhere in-between (hence the articles proposal of a hybrid approach). That said it's not just the budget for hardware to take into consideration but the often ignored costs like man hours, support contracts etc. It also ignores security. Many security departments would much prefer the risk of having a dedicated cloud provider take that on, rather than a bunch of local sysadmins who will come and go.
- otabdeveloper4 5y ago
  Just learn Ansible already, it will take you at most one day.
  - TameAntelope 5y ago
    I'm not sure how learning Ansible (which I already do know) is going to help troubleshoot or actually maintain the deployed services. The problem is not deployment or orchestration (though that is one of them), the problem is building a team with the necessary expertise to support what could be a gigantic variety of tools and technologies at an expert level.
    - nirvdrum 5y ago
      Isn't that true of cloud providers, too? I'll use AWS as an example because that's where I have the most experience. There's a dizzying number of services, some of which have a high degree of overlap. Someone needs to understand them to make an informed choice as to what to use. Every place I've been at using AWS has had to deal with undocumented API issues and responses that the docs say are impossible, but happen. There are performance pitfalls that require in-depth knowledge of the product to avoid, but usually you don't find out until it's too late. Adopting many of the cloud native services isn't just a technology swap (your RDBMS knowledge isn't going to help much with DynamoDB). There's a cottage industry helping people just understand their bills and how to reduce costs. And for non-trivial deployments, you often have to learn orchestration tools like CloudFormation or Terraform. I'm at a place that uses GCP now and very little of that AWS knowledge I've accumulated is applicable here. Cloud platforms/services have a lot going for them, but I think they've become complex monsters that don't really save people as much time as they think. If you're just pushing buttons on the EC2 console, then it's faster than provisioning an Ubuntu server with Ansible for sure. But, those toy deployments aren't indicative of the actual effort to manage a production system. At least in my (mostly start-up) experience with AWS going back to 2009.
      - acdha 5y ago
        > Isn't that true of cloud providers, too? I'll use AWS as an example because that's where I have the most experience. There's a dizzying number of services, some of which have a high degree of overlap. Someone needs to understand them to make an informed choice as to what to use. Every place I've been at using AWS has had to deal with undocumented API issues and responses that the docs say are impossible, but happen. There are performance pitfalls that require in-depth knowledge of the product to avoid, but usually you don't find out until it's too late. Adopting many of the cloud native services isn't just a technology swap (your RDBMS knowledge isn't going to help much with DynamoDB). There's a cottage industry helping people just understand their bills and how to reduce costs. And for non-trivial deployments, you often have to learn orchestration tools like CloudFormation or Terraform. It's true to some extent but I would typically characterize it as having DIY add additional layers you have to be concerned with. For example, I've seen more problems with SANs in some weeks than I've had total using EBS since the late 2000s (repeat for dodgy network cabling, server firmware causing issues, etc.). The other thing to consider is what the alternatives are: for example, the reason why some of your RDBMS knowledge isn't relevant to DynamoDB is because it's a NoSQL database – if you wanted a SQL database, RDS is going to be at least an order of magnitude less time than running your own, especially if you are concerned with performance or reliability. If you've determined that NoSQL is a good fit for your application, that means that the relevant comparison is how much it costs to run DynamoDB versus, say, MongoDB. > I'm at a place that uses GCP now and very little of that AWS knowledge I've accumulated is applicable here. My experience has been the opposite. There are some differences but an awful lot of the principles transfer well to the other major cloud platforms and a solid foundation will make it easier for you to transition between the major cloud providers more easily than on-premise. > If you're just pushing buttons on the EC2 console, then it's faster than provisioning an Ubuntu server with Ansible for sure. But, those toy deployments aren't indicative of the actual effort to manage a production system. It's definitely not trivial but I certainly have no desire to go back to running a VMware cluster, either. I still have memories of being on the phone with their support team explaining how the flaws in their the design of their cluster health-check system lead to a big outage.
- b3lvedere 5y ago
  That's where hybrid comes in so, you don't make yourself completely dependent on big cloud. Of course it's cheaper, because it's mass production. With hybrid you can use any cloud you want, but when it starts doing things you don't agree on, you can revert back to your own systems. Use the force, but have alternatives ready.
ehnto 5y ago
It's a golden era for tooling, if we could do it before it should be even easier now. I think we are in a risk avoidance rut. "No one ever got fired for picking AWS".
silvexis 5y ago
Does that include your salary? How about power, and cooling, and the so many very wonderful things it takes to run a data center.
- jacob019 5y ago
  It is not a binary choice between AWS/GCP/Azure and running your own data center.
- echelon 5y ago
  At some level of scale, it makes sense to hire your own platform team and do it all in house. At the other end, it also works for turtle mode / lifestyle / small businesses. The place for expensive cloud is when you're growing fast and need to spin up infra in a hurry. When you can't be bothered to configure software outside of your core competency.
  - endemic 5y ago
    At a previous gig, they were moving from on-prem to cloud for accounting purposes.
  - scarface74 5y ago
    So has Netflix, Disney+, Intuit, Capital One not reached that scale?
    - echelon 5y ago
      Netflix has quite a bit of their own hardware at the edge [1]. Disney literally just started and are rapidly growing. I don't know anything about Intuit or Capital One. Do they make you wear a suit and tie while working on Oracle databases? (I kid.) [1] https://www.theverge.com/22787426/netflix-cdn-open-connect https://www.theverge.com/22787426/netflix-cdn-open-connect
      - scarface74 5y ago
        Netflix has their CDNs at the edge. Their core infrastructure is on AWS, Disney+ technologically is an outgrowth of the BamTech acquisition which has one of the best regarded streaming technologies.
judge2020 5y ago
> especially when you avoid the biggest cloud players. I find it hard to find a balance between the OVH model of 'purchase a server for a year with discounts for a 12/24 year commitment' and AWS where you can purchase a single hour of bare metal compute for cheap. I would say DigitalOcean fills this, but it's not like they've committed to bare metal, and I imagine they'll continue to look into expanding their suite of managed offerings like Apps[0] (which I think is heroku-esque auto scaling for containers) since the margins on these have to be way higher than their VPS offerings. 0: https://www.digitalocean.com/products/app-platform https://www.digitalocean.com/products/app-platform
hw 5y ago
Have worked on a few SaaS apps that are built on just a couple of Linode/DigitalOcean VMs and bare metal DBs. Costs on AWS would have been 3-4x more. It isn't difficult writing Chef scripts or building a postgresql cluster with auto failover. Unfortunately now finding engineers who can work outside of the big 3 cloud providers are rare. The lock-in is actually industry wide, not just from a resourcing point but also if you want to be taken seriously from an investor perspective. And of course with VC money you can just throw a chunk of it on AWS, but if you are bootstrapped it’s a different story Having said that, eventually there will be a need to move to cloud once you are about to hit a certain scale or have more compliance and security requirements
- ignoramous 5y ago
  > And of course with VC money you can just throw a chunk of it on AWS Don't think VCs are much enthused about AWS either: https://a16z.com/2021/05/27/cost-of-cloud-paradox-market-cap-cloud-lifecycle-scale-growth-repatriation-optimization/ https://a16z.com/2021/05/27/cost-of-cloud-paradox-market-cap...
  - 8note 5y ago
    That explains a lot of blockchain enthusiasm. Get somebody else to worry about paying for the cloud costs
- pjmlp 5y ago
  Enterprises are also doing this to themselves with the usual trend to hire only in X, so if they want people skilled in cloud native with 5 years experience in production, that is what they will get.
  - MonaroVXR 5y ago
    What about training people to get better?
    - pjmlp 5y ago

ClumsyPilot 5y ago

Its certainly possible, but it requires a level of discipline and commitment thats usually missing at larger organisarions. In some firms they still struggle with basics, like staff with 200k salary get a terrible slow pc/ crap monitors, etc.

dsr_ 5y ago
There are no slow desktop computers in 2022. There is a lot of slow software running on fast computers.
- ClumsyPilot 5y ago
  Haha, you ain't seen nothing yet! An mayor accounting firm stulkl has some devs on ancient macbooks with HDDs!

TameAntelope 5y ago

Good lord I could not more strongly think the opposite. It’s a massive resource sink for anything of even modest scale, and in my experience it’s literally been 10x the overall cost, with many, many fewer 0s of uptime guaranteed.

Underphil 5y ago
I think the truth is somewhere in-between (hence the articles proposal of a hybrid approach). That said it's not just the budget for hardware to take into consideration but the often ignored costs like man hours, support contracts etc. It also ignores security. Many security departments would much prefer the risk of having a dedicated cloud provider take that on, rather than a bunch of local sysadmins who will come and go.
otabdeveloper4 5y ago
Just learn Ansible already, it will take you at most one day.
- TameAntelope 5y ago
  I'm not sure how learning Ansible (which I already do know) is going to help troubleshoot or actually maintain the deployed services. The problem is not deployment or orchestration (though that is one of them), the problem is building a team with the necessary expertise to support what could be a gigantic variety of tools and technologies at an expert level.
  - nirvdrum 5y ago
    Isn't that true of cloud providers, too? I'll use AWS as an example because that's where I have the most experience. There's a dizzying number of services, some of which have a high degree of overlap. Someone needs to understand them to make an informed choice as to what to use. Every place I've been at using AWS has had to deal with undocumented API issues and responses that the docs say are impossible, but happen. There are performance pitfalls that require in-depth knowledge of the product to avoid, but usually you don't find out until it's too late. Adopting many of the cloud native services isn't just a technology swap (your RDBMS knowledge isn't going to help much with DynamoDB). There's a cottage industry helping people just understand their bills and how to reduce costs. And for non-trivial deployments, you often have to learn orchestration tools like CloudFormation or Terraform. I'm at a place that uses GCP now and very little of that AWS knowledge I've accumulated is applicable here. Cloud platforms/services have a lot going for them, but I think they've become complex monsters that don't really save people as much time as they think. If you're just pushing buttons on the EC2 console, then it's faster than provisioning an Ubuntu server with Ansible for sure. But, those toy deployments aren't indicative of the actual effort to manage a production system. At least in my (mostly start-up) experience with AWS going back to 2009.
    - acdha 5y ago
      > Isn't that true of cloud providers, too? I'll use AWS as an example because that's where I have the most experience. There's a dizzying number of services, some of which have a high degree of overlap. Someone needs to understand them to make an informed choice as to what to use. Every place I've been at using AWS has had to deal with undocumented API issues and responses that the docs say are impossible, but happen. There are performance pitfalls that require in-depth knowledge of the product to avoid, but usually you don't find out until it's too late. Adopting many of the cloud native services isn't just a technology swap (your RDBMS knowledge isn't going to help much with DynamoDB). There's a cottage industry helping people just understand their bills and how to reduce costs. And for non-trivial deployments, you often have to learn orchestration tools like CloudFormation or Terraform. It's true to some extent but I would typically characterize it as having DIY add additional layers you have to be concerned with. For example, I've seen more problems with SANs in some weeks than I've had total using EBS since the late 2000s (repeat for dodgy network cabling, server firmware causing issues, etc.). The other thing to consider is what the alternatives are: for example, the reason why some of your RDBMS knowledge isn't relevant to DynamoDB is because it's a NoSQL database – if you wanted a SQL database, RDS is going to be at least an order of magnitude less time than running your own, especially if you are concerned with performance or reliability. If you've determined that NoSQL is a good fit for your application, that means that the relevant comparison is how much it costs to run DynamoDB versus, say, MongoDB. > I'm at a place that uses GCP now and very little of that AWS knowledge I've accumulated is applicable here. My experience has been the opposite. There are some differences but an awful lot of the principles transfer well to the other major cloud platforms and a solid foundation will make it easier for you to transition between the major cloud providers more easily than on-premise. > If you're just pushing buttons on the EC2 console, then it's faster than provisioning an Ubuntu server with Ansible for sure. But, those toy deployments aren't indicative of the actual effort to manage a production system. It's definitely not trivial but I certainly have no desire to go back to running a VMware cluster, either. I still have memories of being on the phone with their support team explaining how the flaws in their the design of their cluster health-check system lead to a big outage.
b3lvedere 5y ago
That's where hybrid comes in so, you don't make yourself completely dependent on big cloud. Of course it's cheaper, because it's mass production. With hybrid you can use any cloud you want, but when it starts doing things you don't agree on, you can revert back to your own systems. Use the force, but have alternatives ready.

ehnto 5y ago

It's a golden era for tooling, if we could do it before it should be even easier now. I think we are in a risk avoidance rut. "No one ever got fired for picking AWS".

silvexis 5y ago

Does that include your salary? How about power, and cooling, and the so many very wonderful things it takes to run a data center.

jacob019 5y ago
It is not a binary choice between AWS/GCP/Azure and running your own data center.
echelon 5y ago
At some level of scale, it makes sense to hire your own platform team and do it all in house. At the other end, it also works for turtle mode / lifestyle / small businesses. The place for expensive cloud is when you're growing fast and need to spin up infra in a hurry. When you can't be bothered to configure software outside of your core competency.
- endemic 5y ago
  At a previous gig, they were moving from on-prem to cloud for accounting purposes.
- scarface74 5y ago
  So has Netflix, Disney+, Intuit, Capital One not reached that scale?
  - echelon 5y ago
    Netflix has quite a bit of their own hardware at the edge [1]. Disney literally just started and are rapidly growing. I don't know anything about Intuit or Capital One. Do they make you wear a suit and tie while working on Oracle databases? (I kid.) [1] https://www.theverge.com/22787426/netflix-cdn-open-connect https://www.theverge.com/22787426/netflix-cdn-open-connect
    - scarface74 5y ago
      Netflix has their CDNs at the edge. Their core infrastructure is on AWS, Disney+ technologically is an outgrowth of the BamTech acquisition which has one of the best regarded streaming technologies.

judge2020 5y ago

> especially when you avoid the biggest cloud players. I find it hard to find a balance between the OVH model of 'purchase a server for a year with discounts for a 12/24 year commitment' and AWS where you can purchase a single hour of bare metal compute for cheap. I would say DigitalOcean fills this, but it's not like they've committed to bare metal, and I imagine they'll continue to look into expanding their suite of managed offerings like Apps[0] (which I think is heroku-esque auto scaling for containers) since the margins on these have to be way higher than their VPS offerings. 0: https://www.digitalocean.com/products/app-platform https://www.digitalocean.com/products/app-platform

hw 5y ago

Have worked on a few SaaS apps that are built on just a couple of Linode/DigitalOcean VMs and bare metal DBs. Costs on AWS would have been 3-4x more. It isn't difficult writing Chef scripts or building a postgresql cluster with auto failover. Unfortunately now finding engineers who can work outside of the big 3 cloud providers are rare. The lock-in is actually industry wide, not just from a resourcing point but also if you want to be taken seriously from an investor perspective. And of course with VC money you can just throw a chunk of it on AWS, but if you are bootstrapped it’s a different story Having said that, eventually there will be a need to move to cloud once you are about to hit a certain scale or have more compliance and security requirements

ignoramous 5y ago
> And of course with VC money you can just throw a chunk of it on AWS Don't think VCs are much enthused about AWS either: https://a16z.com/2021/05/27/cost-of-cloud-paradox-market-cap-cloud-lifecycle-scale-growth-repatriation-optimization/ https://a16z.com/2021/05/27/cost-of-cloud-paradox-market-cap...
- 8note 5y ago
  That explains a lot of blockchain enthusiasm. Get somebody else to worry about paying for the cloud costs
pjmlp 5y ago
Enterprises are also doing this to themselves with the usual trend to hire only in X, so if they want people skilled in cloud native with 5 years experience in production, that is what they will get.
- MonaroVXR 5y ago
  What about training people to get better?
  - pjmlp 5y ago