4 ms·

I have been saying this for years - hybrid cloud has always been the way to go. Put your highly variable workloads in the cloud and autoscale. And anything supe

I have been saying this for years - hybrid cloud has always been the way to go. Put your highly variable workloads in the cloud and autoscale. And anything super GPU or compute hungry that are regular workloads should be run yourself. Bonus points if you can autoscale those same on prem workloads into the cloud provider of your choice seamlessly

zmmmmm 4y ago
It's the way to go but the battle you have to fight is maintaining internal competency to host the infra. Especially if you have any kind of security or regulatory overlay its going to mean almost full duplication of a giant stack of processes that parallel each other in cloud / on prem. I think the key as you have outlined is to break out the simple batch compute and CPU/memory intensive or data volume heavy tasks as these are what generate the cloud bills. In general these aren't the focus of your policy constraints, especially if you can claim the data is not "at rest" within these systems.
- steveBK123 4y ago
  It pains me to tell you this, but "simple batch compute and CPU/memory intensive or data volume heavy tasks " were the first ones my firm has, unsuccessfully, tried to move to the cloud, no joke.
markus_zhang 4y ago
From my experience I think maybe internal reporting fits self hosting. You don't need to scale too much, it can tolerate some fails, etc. But I guess it's still complicated when you throw a wrench called BI into the machinery.
- steveBK123 4y ago
  The thing is that self hosting kind of already has cost gates. Whenever I needed to buy another $100K of servers, we had to make a deck and have a skip level meeting 2-3 levels up to explain the capacity planning spend. On the other hand, in AWS, at my last shop.. we were just .. doing stuff. We at one point noticed a non-production RDS instance was going to run us $60k/year. This was for some small part of our processing, that in on-prem land would just occupy a slice of one of our $30k servers. But in cloud, we had the pleasure of $5k/month until we noticed & turned it off. At the scale our estate worked, we had easily 100 entities that could trigger this kind of spend.
steveBK123 4y ago
Yeah also sometimes physical hardware is a constraint on waste. Quality & performance of code often has a way of degrading to the point it saturates the available hardware. In the absence of friction to buy more immediate incremental capacity, teams may never optimize their code.. This may be good when you are "moving fast & breaking things". This may be bad when you are trying to operate an already-scaled business profitably.
captaincaveman 4y ago
I think that is probably the right way to go. We have a put a few things on AWS which really don't fit there too well, all on the benefits of shutting down our on-prem estate, 5 years later we still have an on-prem estate.
- steveBK123 4y ago
  Ah yes. Ours was to be a 2 year migration tour. Then after 2 years, they said 5 more years. I guess we will see what it looks like in 2030. I can tell you 99% of usage is still on-prem today.
  - selimthegrim 4y ago
    I’m sure Gilligan’s Island In The Cloud would have an audience.

zmmmmm 4y ago

It's the way to go but the battle you have to fight is maintaining internal competency to host the infra. Especially if you have any kind of security or regulatory overlay its going to mean almost full duplication of a giant stack of processes that parallel each other in cloud / on prem. I think the key as you have outlined is to break out the simple batch compute and CPU/memory intensive or data volume heavy tasks as these are what generate the cloud bills. In general these aren't the focus of your policy constraints, especially if you can claim the data is not "at rest" within these systems.

steveBK123 4y ago
It pains me to tell you this, but "simple batch compute and CPU/memory intensive or data volume heavy tasks " were the first ones my firm has, unsuccessfully, tried to move to the cloud, no joke.

markus_zhang 4y ago

From my experience I think maybe internal reporting fits self hosting. You don't need to scale too much, it can tolerate some fails, etc. But I guess it's still complicated when you throw a wrench called BI into the machinery.

steveBK123 4y ago
The thing is that self hosting kind of already has cost gates. Whenever I needed to buy another $100K of servers, we had to make a deck and have a skip level meeting 2-3 levels up to explain the capacity planning spend. On the other hand, in AWS, at my last shop.. we were just .. doing stuff. We at one point noticed a non-production RDS instance was going to run us $60k/year. This was for some small part of our processing, that in on-prem land would just occupy a slice of one of our $30k servers. But in cloud, we had the pleasure of $5k/month until we noticed & turned it off. At the scale our estate worked, we had easily 100 entities that could trigger this kind of spend.

steveBK123 4y ago

Yeah also sometimes physical hardware is a constraint on waste. Quality & performance of code often has a way of degrading to the point it saturates the available hardware. In the absence of friction to buy more immediate incremental capacity, teams may never optimize their code.. This may be good when you are "moving fast & breaking things". This may be bad when you are trying to operate an already-scaled business profitably.

captaincaveman 4y ago

I think that is probably the right way to go. We have a put a few things on AWS which really don't fit there too well, all on the benefits of shutting down our on-prem estate, 5 years later we still have an on-prem estate.

steveBK123 4y ago
Ah yes. Ours was to be a 2 year migration tour. Then after 2 years, they said 5 more years. I guess we will see what it looks like in 2030. I can tell you 99% of usage is still on-prem today.
- selimthegrim 4y ago
  I’m sure Gilligan’s Island In The Cloud would have an audience.