5 ms·

> A lot of org move to cloud based hosting because it enable them to go way further in FinOps / cost control I think a lot of orgs move to cloud simply because

> A lot of org move to cloud based hosting because it enable them to go way further in FinOps / cost control I think a lot of orgs move to cloud simply because it's popular and gartner told them so. But taking a step away from that, it's really about self-service. When the alternative is logging a ticket for someone to manually misconfigure a VM and then fail to send you the login credentials, then your delivery is slow. When you're chasing revenue, going slow means you're leaving money on the table. When you're a big bureaucratic org, it means your middle managers can't claim to have delivered a whole bunch of shit. Nobody likes being held up, but that's what infrastructure teams historically do.

sofixa 3y ago
> I think a lot of orgs move to cloud simply because it's popular and gartner told them so. Nah, I think it's mostly about the second part of your comment. Everyone hates waiting for months to get a VM or a database or a firewall rule because the infrastructure/DBA teams are stuck ten years in the past and take pride in their artisanal infrastructure building. So moving to the cloud eliminates a useless layer of time wasting,
- MaKey 3y ago
  The layer will still be there, because those teams are now managing some cloud infrastructure central to the organization.
- nikau 3y ago
  It also allows management to hide bad decisions and poor planning. Project is a dud? just nuke the cloud project and no more charges for it. Project is poorly architected and running like a dog? throw more resources at it. Both of the above are harder to hide when you have to order equipment for on prem.
  - ownagefool 3y ago
    If you're running an internal cloud, you can likely absorb that. I think comes down to a couple of things: - Small orgs don't have the resources to run internal clouds, nor should they be doing so. This limits the pipeline of available candidates. - Large orgs promote the wrong people to management, and they make decisions based on their mental model of the world that was developed 20 years ago. They're filled with people who don't understand the difference between cloud and virtualization. - Large consultancies make more money by throwing raw numbers at the problem rather than smart automation. i.e. it's easier for IBM to bill T&M and a whole project wrapper to patch the server than automate it. - Finance & HR teams want you to bend to their ways of working rather than the opposite. Of the rest, you get into many of them are simply in ops because they're less skilled software developers, or they're now being asked to assure security, and that scares them so they try to lock everything down.
  - yau8edq12i 3y ago
    > Project is a dud? just nuke the cloud project and no more charges for it. How is that a negative? Not every project is going to be successful. That's just a basic fact of life. That you don't have to deal with the sunk cost fallacy and just pull the plug is a good thing. > Project is poorly architected and running like a dog? throw more resources at it. Another positive...?! You can continue to serve your clients and maintain a revenue stream while you work on a better architecture. Instead of failing completely. And once you need less ressources, you easily scale down.
- sgarland 3y ago
  If only that were the case. Even when everything is in IaC and 100% cloud-native, I’ve still seen dev teams bypass the approved methods because ClickOps is easier.
- steveBK123 3y ago
  If your on-prem team can't spin up a VM same day, then firing them is probably higher ROI than "going to cloud". Further, a lot of the shops "going to cloud" because their infra team is slow.. then hide cloud behind their infra team. A prior 200+ dev shop went from automated on-prem VM builds happening within hours from when you raise a ticket, to cloud where there was a slack channel to nag&beg for an EC2 which could take a day to a week. This was not a temporary state of affairs either, it was allowed to run like this for 2 years+. Oh and, worth mentioning, CTO there LOVED him some Gartner.
  - marcus0x62 3y ago
    I've never seen an IT team that couldn't spin up a VM in minutes. I have seen a bunch of teams that weren't allowed to because of ludicrous "change control" practices. Fire the managers that create this state of affairs, not the devops folks, regardless of whether you "go cloud" or not.
    - steveBK123 3y ago
      Teams are what they DO, not what they CAN DO.
      - marcus0x62 3y ago
        Ok, but I’m not sure what that has to do with what I posted.
    - sofixa 3y ago
      I've met multiple customers where time to get a VM was in the weeks to months. (To be fair, I'm at a vendor that proposed IaC tooling and general workflows and practices to move away from old school ClickOps ticket-based provisioning, so of course we'd get those types of orgs). And more often than not, it had nothing to do with managers, but with individual contributors resisting change because they were set in their ways and were potentially afraid for their jobs. Same applies for firewall changes btw.
- sebazzz 3y ago
  That time wasting is back in the same form or another. For instance, at my side they enable *all* the Azure Application Gateway, even those rules that Microsoft says not to enable - causing even simple OpenID redirects from Microsoft AzureID (Microsoft login) to the application to get captured in AAG and fail.
- jjav 3y ago
  > waiting for months to get a VM or a database or a firewall rule because the infrastructure/DBA teams are stuck.. You still have to go through your devops (or equivalent) team to make any network configuration/permission changes. Whether that change is implemented by a local firewall rule or some AWS configuration change is not very important. It's not like you're going to have developers changing AWS access permissions directly. Maybe in a few employee startup, but in any regulated & audited company, you must have separation of duties and audited change control process.
photonthug 3y ago
> I think a lot of orgs move to cloud simply because it's popular This can be rational and not just following the leader. In particular.. many devs might think that working with an org that does On-prem is bad for their career, and they might be right. So from an org POV you can't hire good engineers if you're perceived as a dinosaur. This actually might be enough to send you towards the cloud even if the price by itself makes no sense
- Radim 3y ago
  I've experienced the opposite too: orgs looking at down on cloud-only devs. The idea being that devs who lean on cloud excessively do that to masks their lack of fundamentals, which will cause costly fuck ups no matter what technology they use, cloud or on-prem. Maybe directionally similar idea to hiring ex-Googlers? Some orgs also don't like those. Specific mindset, specific toolbox.
  - shermantanktop 3y ago
    It is absolutely true that some devs have the AWS product set as the tech toolkit they know best. Whatever their fundamental skills are, the most important way they add value is by optimizing things like lambda startup time or EC2 CPU utilization. Does this allow them to mask deep problems with fundamentals? I guess it could, but that sounds a bit gatekeep-y to me.
    - photonthug 3y ago
      Sort of, but IDK, If you have specific needs this might be a somewhat reasonable heuristic for hiring. Devs who came up building software more or less from scratch really do have a different skillset than ones who stick to working in service-rich environments because there's a significant difference between glueing services together vs building out those same services. For example something like using a paginated API is quite a bit easier than designing/implementing one. A developer who is skilled and methodical about reading and understanding service-level documentation may not actually be able to step through debugging in a REPL, and vice versa. (Not to say that either kind of person cannot learn the other persons tricks, but as far as the differences in what they already know, those can be pretty significant.) Assuming someone only has one of these skillsets, the most valuable one totally depends on the situation. On the one hand it's pretty cool that service-familiarity tends to be language-agnostic, but it's less cool when your S3-API expert barely understands the basics of tooling in the new language.
ok123456 3y ago
There's also now regulatory capture. Your bare-metal or VPS solution won't be "FEDRAMP" approved, even though there are fewer moving parts to secure.
mx_03 3y ago
I have worked in places where adding a new server is a bureocratic nightmare at best. Granted I dont think thats the norm, but also host your webserver yourself is not as user friendly as AWS. People always forget that.

sofixa 3y ago

> I think a lot of orgs move to cloud simply because it's popular and gartner told them so. Nah, I think it's mostly about the second part of your comment. Everyone hates waiting for months to get a VM or a database or a firewall rule because the infrastructure/DBA teams are stuck ten years in the past and take pride in their artisanal infrastructure building. So moving to the cloud eliminates a useless layer of time wasting,

MaKey 3y ago
The layer will still be there, because those teams are now managing some cloud infrastructure central to the organization.
nikau 3y ago
It also allows management to hide bad decisions and poor planning. Project is a dud? just nuke the cloud project and no more charges for it. Project is poorly architected and running like a dog? throw more resources at it. Both of the above are harder to hide when you have to order equipment for on prem.
- ownagefool 3y ago
  If you're running an internal cloud, you can likely absorb that. I think comes down to a couple of things: - Small orgs don't have the resources to run internal clouds, nor should they be doing so. This limits the pipeline of available candidates. - Large orgs promote the wrong people to management, and they make decisions based on their mental model of the world that was developed 20 years ago. They're filled with people who don't understand the difference between cloud and virtualization. - Large consultancies make more money by throwing raw numbers at the problem rather than smart automation. i.e. it's easier for IBM to bill T&M and a whole project wrapper to patch the server than automate it. - Finance & HR teams want you to bend to their ways of working rather than the opposite. Of the rest, you get into many of them are simply in ops because they're less skilled software developers, or they're now being asked to assure security, and that scares them so they try to lock everything down.
- yau8edq12i 3y ago
  > Project is a dud? just nuke the cloud project and no more charges for it. How is that a negative? Not every project is going to be successful. That's just a basic fact of life. That you don't have to deal with the sunk cost fallacy and just pull the plug is a good thing. > Project is poorly architected and running like a dog? throw more resources at it. Another positive...?! You can continue to serve your clients and maintain a revenue stream while you work on a better architecture. Instead of failing completely. And once you need less ressources, you easily scale down.
sgarland 3y ago
If only that were the case. Even when everything is in IaC and 100% cloud-native, I’ve still seen dev teams bypass the approved methods because ClickOps is easier.
steveBK123 3y ago
If your on-prem team can't spin up a VM same day, then firing them is probably higher ROI than "going to cloud". Further, a lot of the shops "going to cloud" because their infra team is slow.. then hide cloud behind their infra team. A prior 200+ dev shop went from automated on-prem VM builds happening within hours from when you raise a ticket, to cloud where there was a slack channel to nag&beg for an EC2 which could take a day to a week. This was not a temporary state of affairs either, it was allowed to run like this for 2 years+. Oh and, worth mentioning, CTO there LOVED him some Gartner.
- marcus0x62 3y ago
  I've never seen an IT team that couldn't spin up a VM in minutes. I have seen a bunch of teams that weren't allowed to because of ludicrous "change control" practices. Fire the managers that create this state of affairs, not the devops folks, regardless of whether you "go cloud" or not.
  - steveBK123 3y ago
    Teams are what they DO, not what they CAN DO.
    - marcus0x62 3y ago
      Ok, but I’m not sure what that has to do with what I posted.
  - sofixa 3y ago
    I've met multiple customers where time to get a VM was in the weeks to months. (To be fair, I'm at a vendor that proposed IaC tooling and general workflows and practices to move away from old school ClickOps ticket-based provisioning, so of course we'd get those types of orgs). And more often than not, it had nothing to do with managers, but with individual contributors resisting change because they were set in their ways and were potentially afraid for their jobs. Same applies for firewall changes btw.
sebazzz 3y ago
That time wasting is back in the same form or another. For instance, at my side they enable *all* the Azure Application Gateway, even those rules that Microsoft says not to enable - causing even simple OpenID redirects from Microsoft AzureID (Microsoft login) to the application to get captured in AAG and fail.
jjav 3y ago
> waiting for months to get a VM or a database or a firewall rule because the infrastructure/DBA teams are stuck.. You still have to go through your devops (or equivalent) team to make any network configuration/permission changes. Whether that change is implemented by a local firewall rule or some AWS configuration change is not very important. It's not like you're going to have developers changing AWS access permissions directly. Maybe in a few employee startup, but in any regulated & audited company, you must have separation of duties and audited change control process.

photonthug 3y ago

> I think a lot of orgs move to cloud simply because it's popular This can be rational and not just following the leader. In particular.. many devs might think that working with an org that does On-prem is bad for their career, and they might be right. So from an org POV you can't hire good engineers if you're perceived as a dinosaur. This actually might be enough to send you towards the cloud even if the price by itself makes no sense

Radim 3y ago
I've experienced the opposite too: orgs looking at down on cloud-only devs. The idea being that devs who lean on cloud excessively do that to masks their lack of fundamentals, which will cause costly fuck ups no matter what technology they use, cloud or on-prem. Maybe directionally similar idea to hiring ex-Googlers? Some orgs also don't like those. Specific mindset, specific toolbox.
- shermantanktop 3y ago
  It is absolutely true that some devs have the AWS product set as the tech toolkit they know best. Whatever their fundamental skills are, the most important way they add value is by optimizing things like lambda startup time or EC2 CPU utilization. Does this allow them to mask deep problems with fundamentals? I guess it could, but that sounds a bit gatekeep-y to me.
  - photonthug 3y ago
    Sort of, but IDK, If you have specific needs this might be a somewhat reasonable heuristic for hiring. Devs who came up building software more or less from scratch really do have a different skillset than ones who stick to working in service-rich environments because there's a significant difference between glueing services together vs building out those same services. For example something like using a paginated API is quite a bit easier than designing/implementing one. A developer who is skilled and methodical about reading and understanding service-level documentation may not actually be able to step through debugging in a REPL, and vice versa. (Not to say that either kind of person cannot learn the other persons tricks, but as far as the differences in what they already know, those can be pretty significant.) Assuming someone only has one of these skillsets, the most valuable one totally depends on the situation. On the one hand it's pretty cool that service-familiarity tends to be language-agnostic, but it's less cool when your S3-API expert barely understands the basics of tooling in the new language.

ok123456 3y ago

There's also now regulatory capture. Your bare-metal or VPS solution won't be "FEDRAMP" approved, even though there are fewer moving parts to secure.

mx_03 3y ago

I have worked in places where adding a new server is a bureocratic nightmare at best. Granted I dont think thats the norm, but also host your webserver yourself is not as user friendly as AWS. People always forget that.