4 ms·

Ahhh... maybe. > There's some sort of folk wisdom that the lowest layer of cloud services is a pure commodity service. > Cloud vendors might be pretty happy m

Ahhh... maybe. > There's some sort of folk wisdom that the lowest layer of cloud services is a pure commodity service. > Cloud vendors might be pretty happy making money just in the lowest layer. Margins aren't so bad and vendor lock-in is still pretty high. It may be folk wisdom, but big customers look at stuff like storage and CPU pricing when picking a vendor, because they need lots of storage and CPU. These services, in turn, are priced close to the actual cost of the underlying storage and CPU because of the high volume of storage and CPU involved. I have worked at cloud vendors. Margins aren't great. Cloud vendors are always asking questions like, "How does vendor X sell this for so cheap? We can't make a profit at that price! How can we make our costs for X lower?" The lock-in is seen as a way to sell the higher-level services. However, the high-level services, the stuff that start-ups compete with, also face competition with open-source projects. Things that used to be SaaS are now DIY with open-source projects running on IaaS. Ten years ago you had no Kubernetes, and you didn't have columnar storage out of the box on PostgreSQL. Cassandra was immature. Nowadays, open-source software running on IaaS has killed the need for bigger segments of the SaaS market, assuming you have enough expertise in-house to run it.

pierremenard 5y ago
> assuming you have enough expertise in-house to run it. Most small to mid-sized companies would almost always opt to pay a bit more for a managed offering and not have to bring in expertise in-house for things that are not their core competency.
- klodolph 5y ago
  For a small company, that's sensible. For a mid-size company, I think it's short-sighted. I'd argue that mid-size tech companies need the expertise that comes with running more of their own stack. If you don't have the expertise, then you're going to be dealing more with support engineers to solve your problems, and you won't have as much insight into your tech stack as you'd want. There's a big difference between the experience of opening a support ticket to fix a problem with your database and paging one of your salaried engineers to fix it--someone who actually runs the service to begin with.
  - ethbr0 5y ago
    How are mid-sized companies going to afford to retain that expertise, once they've trained it? Or, to put it another way, mid-sized company X can never pay as much as hyperscale company Y for Z expertise. Because utilization at mid will always be less than at hyper. I'm all for retaining inhouse expertise, but it's fundamentally a return-on-capital optimization problem, albeit one where your capital asset has the ability to walk out the door. So inhousing core, using managed everything else is a more reasonable bargain.
    - zrm 5y ago
      > Because utilization at mid will always be less than at hyper. Will it? Economies of scale have diminishing returns. If you have one engineer who is 20% busy, your engineer cost per unit will be five times higher than a company five times your size who keeps that one person 100% busy. If you have four engineers who are all 100% busy, compared to a company 250 times your size with 1000 engineers, your cost per unit is equivalent.
      - mellavora 5y ago
        Hey, your math makes sense, and is a good illustrative example, but in the real world if you schedule has your engineers 100% busy, then you have no slack to handle emergencies/unexpected events. I'd target 60-70% utilization of engineer time. The remaining 30-40% is for stuff which can be dropped when needed (refactoring, non-critical/experimental projects, personal learning, ...). And if you have good engineers, they probably have a really good idea of how to prioritize for filling that 30-40% so as to move the company forward.
        klodolph 5y ago
        The same applies to machines! There is an inverse relationship between resource utilization and queue length, under reasonable assumptions. If you think of low CPU utilization as "wasted" CPU and try to fill it up, you can completely kill your service's ability to quickly respond to requests. I like to make this analogy when talking to people who feel like they are not working hard enough. If you fill up an engineer's time with high-priority work, you get the same problem as if you fill up a machine's CPU with high-priority tasks... you get a system that cannot respond quickly, a system that spends a lot of time overloaded. It's a fun exercise to try and calculate the relationship between utilization and expected queue length. Plus, those batch jobs are still important, they're just not as time-sensitive.
- jokethrowaway 5y ago
  You think hiring AWS engineers is cheaper than hiring some old style sysadmin that can manage any servers? Most likely you'll end up spending less in ops. The only problem may be finding talent, as everyone goes the AWS way so they can charge more.

pierremenard 5y ago

> assuming you have enough expertise in-house to run it. Most small to mid-sized companies would almost always opt to pay a bit more for a managed offering and not have to bring in expertise in-house for things that are not their core competency.

klodolph 5y ago
For a small company, that's sensible. For a mid-size company, I think it's short-sighted. I'd argue that mid-size tech companies need the expertise that comes with running more of their own stack. If you don't have the expertise, then you're going to be dealing more with support engineers to solve your problems, and you won't have as much insight into your tech stack as you'd want. There's a big difference between the experience of opening a support ticket to fix a problem with your database and paging one of your salaried engineers to fix it--someone who actually runs the service to begin with.
- ethbr0 5y ago
  How are mid-sized companies going to afford to retain that expertise, once they've trained it? Or, to put it another way, mid-sized company X can never pay as much as hyperscale company Y for Z expertise. Because utilization at mid will always be less than at hyper. I'm all for retaining inhouse expertise, but it's fundamentally a return-on-capital optimization problem, albeit one where your capital asset has the ability to walk out the door. So inhousing core, using managed everything else is a more reasonable bargain.
  - zrm 5y ago
    > Because utilization at mid will always be less than at hyper. Will it? Economies of scale have diminishing returns. If you have one engineer who is 20% busy, your engineer cost per unit will be five times higher than a company five times your size who keeps that one person 100% busy. If you have four engineers who are all 100% busy, compared to a company 250 times your size with 1000 engineers, your cost per unit is equivalent.
    - mellavora 5y ago
      Hey, your math makes sense, and is a good illustrative example, but in the real world if you schedule has your engineers 100% busy, then you have no slack to handle emergencies/unexpected events. I'd target 60-70% utilization of engineer time. The remaining 30-40% is for stuff which can be dropped when needed (refactoring, non-critical/experimental projects, personal learning, ...). And if you have good engineers, they probably have a really good idea of how to prioritize for filling that 30-40% so as to move the company forward.
      - klodolph 5y ago
        The same applies to machines! There is an inverse relationship between resource utilization and queue length, under reasonable assumptions. If you think of low CPU utilization as "wasted" CPU and try to fill it up, you can completely kill your service's ability to quickly respond to requests. I like to make this analogy when talking to people who feel like they are not working hard enough. If you fill up an engineer's time with high-priority work, you get the same problem as if you fill up a machine's CPU with high-priority tasks... you get a system that cannot respond quickly, a system that spends a lot of time overloaded. It's a fun exercise to try and calculate the relationship between utilization and expected queue length. Plus, those batch jobs are still important, they're just not as time-sensitive.
jokethrowaway 5y ago
You think hiring AWS engineers is cheaper than hiring some old style sysadmin that can manage any servers? Most likely you'll end up spending less in ops. The only problem may be finding talent, as everyone goes the AWS way so they can charge more.