From: cross@spitfire.i.gajendra.net   
      
   In article <10f4n8c$25lkk$1@dont-email.me>,   
   Simon Clubley   wrote:   
   >On 2025-11-12, Dan Cross  wrote:   
   >> In article <10esrru$1qu6$1@dont-email.me>,   
   >> Simon Clubley   wrote:   
   >>>On 2025-11-07, Dan Cross  wrote:   
   >>>> As for the cloud, the number of organizations moving back   
   >>>> on-prem for very good reasons shouldn't be discounted.   
   >>>   
   >>>Yes, and I hope the latest batch of critical system movers do not   
   >>>repeat those same mistakes.   
   >>   
   >> I'm not sure what mistakes you're referring to, but let's hope   
   >> that system maintainers make fewer mistakes generally.  :-D   
   >   
   >I was referring to the mistake of getting rid of your local systems,   
   >and local systems knowledge, in favour of moving everything into the   
   >public clouds and outsourcing your local systems knowledge and   
   >development to third party vendors.   
   >   
   >This works for some people, but not for others, and there appears to have   
   >been quite a drive by senior management in general of inappropriate   
   >movement away from local control and knowledge so that it "becomes someone   
   >else's problem".   
   >   
   >The problem is that it isn't someone else's problem, it's still their   
   >problem, as more than a few people have found out the hard way, promptly   
   >followed by spending more money to move things back in house again.   
      
   Ah, ok.  Yes, I agree; discarding local domain knowledge is   
   rarely --- if ever --- a good idea.   
      
   It seems axiomatic that movement of systems should be done with   
   care, and only after evaluating whether such a move is a good   
   idea holistically.  Clearly, a lot of people moved "to the   
   cloud" who either did no such analysis, or did not account for a   
   number of variables if they did.   
      
   On the one hand, I kind of get that: there are a lot of unknowns   
   when doing such things, and those may not be discovered until   
   after the fact.  On the other hand, once you've been around for   
   a while, you know this is the case and should anticipate it.   
      
   Among the arguments for the cloud are that provisioning,   
   building, and maintaining datacenters is one of the core   
   competencies of the hyperscalars.  And that is true; the Googles   
   and Amazons and Microsofts of the world do this better than   
   anybody else.  So you get tremendous economies of scale with   
   respect to hardware and its maintenance if you leverage renting   
   capacity from them.  Further, you get to skip all of the capital   
   expenses of building out your own infrastructure.  Yay!  And   
   elasticity is attractive: you don't have to provision for (read:   
   always pay for) your peak usage; you can adjust over time and   
   that can save.   
      
   But your workload is _your_ workload.  The cloud provider   
   doesn't have any insight into your requirements there, really,   
   and if you're not a sufficiently large customer, they won't   
   really care all that much either.  At Google, we certainly made   
   a good-faith effort, but some things just weren't worth it from   
   the perspective of deciding where to spend engineering   
   resources.  I used to joke that we were sort of like the spacing   
   guild from "Dune": the Atreides and Harkonnen's could have jobs   
   running on the same machine and never know it.  However, none of   
   that is an excuse to throw away knowledge of your own workload.   
      
   But just like renting instead of owning a home, you're subject   
   to the landlord raising the rent on you.  And once you hit a   
   certain scale, the economies of scale argument begins to break   
   down.  Hence, re-homing back on-prem in a lot of cases.   
      
   Provided you still know how to run your own stuff, of course.   
      
   	- Dan C.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)