4 ms·

20 years in this field has taught me that (1) we move on to new technologies more often because we don't understand the current ones than because the current on

by gdulli 9y ago

20 years in this field has taught me that (1) we move on to new technologies more often because we don't understand the current ones than because the current ones are flawed, (2) we fail to weigh the costs and risks and setback of moving to new technologies, and (3) we don't realize that we're conserving overall complexity and flawedness, just moving it around.

jacques_chester 9y ago
> we don't realize that we're conserving overall complexity and flawedness, just moving it around. I broadly think so too: https://news.ycombinator.com/item?id=5262556 https://news.ycombinator.com/item?id=5262556 Though the shifting sands of the economics of compute, disk and network tend to favour this or that approach as time goes on. So while FaaSes are just CGI, they aren't just CGI; but we can at least try to be non-doomed with regards to repetition of history.
keymone 9y ago
(4) new tech is sexy, old tech is all cranky old guys, like 30+, yuk.
- dsparkman 9y ago
  Problem is that these young whippersnappers don't even realize that there is nothing "new" about this tech stack. You can recreate the new sexy with 30 year old tech. You are talking about a load balancer that is redirecting requests to individual cgi-scripts based on the url. They have just given up knowing how to setup and configure physical servers.
  - laurentl 9y ago
    > They have just given up knowing how to setup and configure physical servers. Or they know how complex and error-prone it can be, and decided to spend their time on other things. It’s good to know how that stuff works, how to configure a LB, install nginx, rack a server... the way being able to do long divisions by hand is good to know. But when you’re crunching numbers all day, it’s easier to use a calculator.
    - dsparkman 9y ago
      More like learning to use a slide rule :) You still have to learn how to setup a load balancer (API Gateway), firewall (IAM, API Gateway), Server Config (CloudFormation, API Gateway, S3, etc) and so on. And those are Vendor specific. Move to Azure or GC and you have a whole new set of "serverless" servers to learn to configure. About the only thing you have really given up is knowing where your machines are physically.
      - scarface74 9y ago
        You've also given up having to buy machines, predict resources, over provisioning to meet peak demand, server maintenance for databases, caching, web servers, etc. If I want to load test something for a day and spin up 20 EC2 instances and spin them down, I can do that with a script. Then I can see where my bottlenecks are and provision instances, load balancers, increased disk IOPS, etc. as appropriate and tear everything down I don't need.
        dsparkman 9y ago
        Apples to Apples. Your 20 EC2 instances are just 20 VPS at any VPS provider located geographically where you want to deploy them. Also with a script. You still have not gained anything from your vendor lock-in. IaaS has been around since the 90s.
        scarface74 9y ago
        And what about the load balancers, the databases instances, the queuing system, the global CDN, the caching servers, etc? I could script my own strategy for autoscaling that integrates with metrics from the running instances, but why would I when I click on a few buttons and have autoscaling based on CloudWatch metrics, the size of the SQS queue, CPU usage etc? But as far as "vendor lock-in", it's like developers wrapping database access up into a repository pattern just in case we want to change databases. In the real world, hardly anyone takes on massive infrastructure changes to save a few dollars. On the other hand, there are frameworks like Serverless and Terraform to build infrastructure in a cloud vendor neutral method.

by gdulli 9y ago

jacques_chester 9y ago

> we don't realize that we're conserving overall complexity and flawedness, just moving it around. I broadly think so too: https://news.ycombinator.com/item?id=5262556 https://news.ycombinator.com/item?id=5262556 Though the shifting sands of the economics of compute, disk and network tend to favour this or that approach as time goes on. So while FaaSes are just CGI, they aren't just CGI; but we can at least try to be non-doomed with regards to repetition of history.

keymone 9y ago

(4) new tech is sexy, old tech is all cranky old guys, like 30+, yuk.

dsparkman 9y ago
Problem is that these young whippersnappers don't even realize that there is nothing "new" about this tech stack. You can recreate the new sexy with 30 year old tech. You are talking about a load balancer that is redirecting requests to individual cgi-scripts based on the url. They have just given up knowing how to setup and configure physical servers.
- laurentl 9y ago
  > They have just given up knowing how to setup and configure physical servers. Or they know how complex and error-prone it can be, and decided to spend their time on other things. It’s good to know how that stuff works, how to configure a LB, install nginx, rack a server... the way being able to do long divisions by hand is good to know. But when you’re crunching numbers all day, it’s easier to use a calculator.
  - dsparkman 9y ago
    More like learning to use a slide rule :) You still have to learn how to setup a load balancer (API Gateway), firewall (IAM, API Gateway), Server Config (CloudFormation, API Gateway, S3, etc) and so on. And those are Vendor specific. Move to Azure or GC and you have a whole new set of "serverless" servers to learn to configure. About the only thing you have really given up is knowing where your machines are physically.
    - scarface74 9y ago
      You've also given up having to buy machines, predict resources, over provisioning to meet peak demand, server maintenance for databases, caching, web servers, etc. If I want to load test something for a day and spin up 20 EC2 instances and spin them down, I can do that with a script. Then I can see where my bottlenecks are and provision instances, load balancers, increased disk IOPS, etc. as appropriate and tear everything down I don't need.
      - dsparkman 9y ago
        Apples to Apples. Your 20 EC2 instances are just 20 VPS at any VPS provider located geographically where you want to deploy them. Also with a script. You still have not gained anything from your vendor lock-in. IaaS has been around since the 90s.
        scarface74 9y ago
        And what about the load balancers, the databases instances, the queuing system, the global CDN, the caching servers, etc? I could script my own strategy for autoscaling that integrates with metrics from the running instances, but why would I when I click on a few buttons and have autoscaling based on CloudWatch metrics, the size of the SQS queue, CPU usage etc? But as far as "vendor lock-in", it's like developers wrapping database access up into a repository pattern just in case we want to change databases. In the real world, hardly anyone takes on massive infrastructure changes to save a few dollars. On the other hand, there are frameworks like Serverless and Terraform to build infrastructure in a cloud vendor neutral method.