3 ms·

"maintenance and operational burden" in the cloud is way higher than renting a box somewhere and forgetting about it. I can't understand why people keep using

"maintenance and operational burden" in the cloud is way higher than renting a box somewhere and forgetting about it. I can't understand why people keep using this as an argument against anything else other than cloud while playing catch-up with the rain of changes and suffering from fomo of last week's new stuff from cloud. Heck, when did infrastructure became like js landscape?

philliphaydon 6y ago
Renting a box and forgetting about it is how you get hacked. There is more maintenance and operational burden with self hosting vs cloud. But going cloud doesn't mean there's no longer any burden.
- joana035 6y ago
  > Renting a box and forgetting about it is how you get hacked. You get hacked in any compute model if you don't know what you doing. > There is more maintenance and operational burden with self hosting vs cloud. Renting a box is closer to dedicated hosts than to self hosting, which are two very different things. > But going cloud doesn't mean there's no longer any burden. Exactly, and it starts with the complexity and confusion that the cloud became. Then with vendor specific stuff that you don't need, such IAM, and then when you think everything is alright, you notice your bandwidth is caped after 1 hour running your ec2, that your port 25 is magically broken (docs were updated years later after much complains), everything is a slow black box. Cloud is like chopping your both legs and being happy with it.
  - philliphaydon 6y ago
    > Cloud is like chopping your both legs and being happy with it. No it's not lol
EdwardDiego 6y ago
I disagree, managed K8s and managed Kafka are both far nicer to work with than doing it yourself. Of course, you have to accept the costs and the limitations to use it.
- ldng 6y ago
  Neither k8s nor Kafta are clouds. They are tools you can use on premises or on droplets if you wish to.
  - EdwardDiego 6y ago
    Sure, but they are managed products provided by cloud providers, and far simpler to administer than their bare metal counterparts.
didibus 6y ago
Doing OS updates, configuring load balancers, DB backups, setting up firewall rules and OS user accounts, ssh access, archiving logs, configuring monitoring and alarms, assigning DNS, handling deployments, etc. I don't know, as an application developer, I'd rather not waste my time with stuff like that if I can avoid it.
- joana035 6y ago
  You forgot to mention IAM roles and policies. > I don't know, as an application developer, I'd rather not waste my time with stuff like that if I can avoid it. Believe or not there are other roles besides "developer" within technology related jobs. The problem of cloud is that the heavy majority of supporters just echo the usual "scale", "maintenance" arguments without even willing to learn what those things are to the fundamental level. "You have to scale", said the developer that switch his ec2 from one type into the next, more expensive one, "now I have two vCPU, great!" And the people who knows how the real world of infrastructure is doesn't buy this cheap arguments, but are outnumbered by the louder major group. That is freaking depressing!
  - didibus 6y ago
    > Believe or not there are other roles besides "developer" within technology related jobs I would assume much of AWS, at least the services I mentioned, are targetted at application developers though. So if you say running your own box is easier or better for running your application, you'd need to convince an application developer that it is. And as an application developer myself, like I said, I don't find it so. Targeting Lambda for example is much simpler. If I need a DB, using RDS or DynamoDB or S3 is much simpler than spinning and maintaining my own instance on my own box. If I need to publish notifications, well I don't even want to think what I'd need to do to replace SNS or SQS. If I want to have application logs and have them archived for some longer period of time, and make sure they don't fill up my box's hard drive to the max, I can just use CloudLogs. Etc. So again, you'd need to convince me it can be more convenient and less maintainance for me to use my own box instead of using those AWS services. That's even before we talk about availability and scale.

philliphaydon 6y ago

Renting a box and forgetting about it is how you get hacked. There is more maintenance and operational burden with self hosting vs cloud. But going cloud doesn't mean there's no longer any burden.

joana035 6y ago
> Renting a box and forgetting about it is how you get hacked. You get hacked in any compute model if you don't know what you doing. > There is more maintenance and operational burden with self hosting vs cloud. Renting a box is closer to dedicated hosts than to self hosting, which are two very different things. > But going cloud doesn't mean there's no longer any burden. Exactly, and it starts with the complexity and confusion that the cloud became. Then with vendor specific stuff that you don't need, such IAM, and then when you think everything is alright, you notice your bandwidth is caped after 1 hour running your ec2, that your port 25 is magically broken (docs were updated years later after much complains), everything is a slow black box. Cloud is like chopping your both legs and being happy with it.
- philliphaydon 6y ago
  > Cloud is like chopping your both legs and being happy with it. No it's not lol

EdwardDiego 6y ago

I disagree, managed K8s and managed Kafka are both far nicer to work with than doing it yourself. Of course, you have to accept the costs and the limitations to use it.

ldng 6y ago
Neither k8s nor Kafta are clouds. They are tools you can use on premises or on droplets if you wish to.
- EdwardDiego 6y ago
  Sure, but they are managed products provided by cloud providers, and far simpler to administer than their bare metal counterparts.

didibus 6y ago

Doing OS updates, configuring load balancers, DB backups, setting up firewall rules and OS user accounts, ssh access, archiving logs, configuring monitoring and alarms, assigning DNS, handling deployments, etc. I don't know, as an application developer, I'd rather not waste my time with stuff like that if I can avoid it.

joana035 6y ago
You forgot to mention IAM roles and policies. > I don't know, as an application developer, I'd rather not waste my time with stuff like that if I can avoid it. Believe or not there are other roles besides "developer" within technology related jobs. The problem of cloud is that the heavy majority of supporters just echo the usual "scale", "maintenance" arguments without even willing to learn what those things are to the fundamental level. "You have to scale", said the developer that switch his ec2 from one type into the next, more expensive one, "now I have two vCPU, great!" And the people who knows how the real world of infrastructure is doesn't buy this cheap arguments, but are outnumbered by the louder major group. That is freaking depressing!
- didibus 6y ago
  > Believe or not there are other roles besides "developer" within technology related jobs I would assume much of AWS, at least the services I mentioned, are targetted at application developers though. So if you say running your own box is easier or better for running your application, you'd need to convince an application developer that it is. And as an application developer myself, like I said, I don't find it so. Targeting Lambda for example is much simpler. If I need a DB, using RDS or DynamoDB or S3 is much simpler than spinning and maintaining my own instance on my own box. If I need to publish notifications, well I don't even want to think what I'd need to do to replace SNS or SQS. If I want to have application logs and have them archived for some longer period of time, and make sure they don't fill up my box's hard drive to the max, I can just use CloudLogs. Etc. So again, you'd need to convince me it can be more convenient and less maintainance for me to use my own box instead of using those AWS services. That's even before we talk about availability and scale.