4 ms·

> And don't even get me started on how much work by this time has gone to build the infra-as-code to manage the rube golderg machine, you'll (seriously) have mo

> And don't even get me started on how much work by this time has gone to build the infra-as-code to manage the rube golderg machine, you'll (seriously) have more lines of CDK code than app logic (that was slower to develop & harder to debug than your actual app code per line). Of all the AWS complaints, CDK is one of yours? I absolutely love CDK and its take on infra-as-code where you construct OO constructs imperatively in a sane language (please, please no more YAML-based DSLs...). I've found that CDK is the only one to have given us the code reusability that all of these solutions always promise while still being overtly hackable. Debugging CDK code? What kind of wacky stuff are you trying to do? I don't think I've ever had to debug CDK outside of typical "what IAM action am I missing?" or "how do I click some checkbox in CDK?". I'm curious what you would consider to be better alternatives to CDK.

moduspol 4y ago
CDK code also isn't executed at runtime. Even if it somehow is slower to develop and harder to debug (maybe if you're new to it), it's ideal that you have more of it than actual app code per line. That implies you have substantially less app code than you otherwise would, which (of course) is the entire purpose of these cloud-based abstractions. The amount of app code involved to stitch Kinesis, Lambda, and S3 together is minimal. The amount of app code to solve the same problems without them is orders of magnitude more plentiful and complex, which is why we avoid it.
- tpxl 4y ago
  > The amount of app code to solve the same problems without them is orders of magnitude more plentiful and complex, which is why we avoid it. The amount of application code to write to a filesystem is... zero. The amount of application code required to setup a webserver in Java Spring is... zero. Not sure what Kinesis does, but the amount of application code required to connect to a database is zero (spring), to connect to a rabbitmq/kafka is zero (spring). And the best part is, it is less complex, mostly open source, and locally runnable compared to the Amazon rube goldberg machine.
  - moduspol 4y ago
    There will be substantial amounts of code you are writing to provision, set up, maintain, scale, and troubleshoot all of those things. Whether you call it app code or not, it's something that you (and your team) will be on the hook for building and maintaining over time. Getting your Java Spring web server to scale to thousands of concurrent instances will require a lot of undifferentiated work outside the scope of Java Spring. Same with the care and feeding of RabbitMQ and Kafka. And to suggest that's the approach that's less of a Rube Goldberg machine is... questionable.
    - marginalia_nu 4y ago
      What sort of application are you building where you need a thousand instances of a spring application? Like even hosted on a low powered hardware, Java services can easily deal with order of 100 requests/second. This is home turf, this is what Java is really good at. That 100rps may be lowballing it. So you're what, processing 100k+ API requests per second? I can't imagine that would translate toward any less than a billion users. At that point you are either making good headway toward becoming a new letter in the FAANG acronym and ought to have the budget to run your own data center, or your attention is better put toward optimizing your comically inefficient application.
      - moduspol 4y ago
        Or this Java-based Spring application is one of dozens or hundreds of ones built by different teams, for different customers, or for different purposes. Some of them may even be applications not built in Java or Spring. You're missing the point, though.
      - abofh 4y ago
        What sort of app code are you writing where you can keep data, authentication and user data all on the desktop? Just because you can write a docker-compose.yml (or do without) that describes a system that holds together, doesn't mean the system you've produced stands the chance at SOC2 or whatever standard you hold dear. Having just finished a 27001 audit, I promise, "we rely on AWS for X" went a lot farther than "we have a homegrown system that does X", every single time. AWS - box checked, homegrown? Let's dig in for two more hours. Thousands of instances is easy to need - if you have an active CI/CD lifecycle - you just might not need them all at once. Even just one per PR and it adds up super fast if you've got a competent developer team.
likeabbas 4y ago
I love CDK but it does have issues. Like if you wanted to launch your load balancer in a new AZ you would need to structure the code to carefully create the new infrastructure, pivot your DNS to point to the new load balancer, then you can delete the old infra. It’s more complicated then just adding more subnets unfortunately
specialp 4y ago
I would also be interested in what would be the alternative not in the cloud? AWS deployments can get complicated due to the IAM rules, networking rules, security groups. But if I told someone, bring up a stack like that on bare metal, and make it repeatable what would that be? For those of us that have worked on systems pre-cloud it does feel sometimes that it was easier in the past. But if you went to explain to someone new what to do, you realize how much you are taking for granted the knowledge and effort involved. Also the long term maintenance.

moduspol 4y ago

CDK code also isn't executed at runtime. Even if it somehow is slower to develop and harder to debug (maybe if you're new to it), it's ideal that you have more of it than actual app code per line. That implies you have substantially less app code than you otherwise would, which (of course) is the entire purpose of these cloud-based abstractions. The amount of app code involved to stitch Kinesis, Lambda, and S3 together is minimal. The amount of app code to solve the same problems without them is orders of magnitude more plentiful and complex, which is why we avoid it.

tpxl 4y ago
> The amount of app code to solve the same problems without them is orders of magnitude more plentiful and complex, which is why we avoid it. The amount of application code to write to a filesystem is... zero. The amount of application code required to setup a webserver in Java Spring is... zero. Not sure what Kinesis does, but the amount of application code required to connect to a database is zero (spring), to connect to a rabbitmq/kafka is zero (spring). And the best part is, it is less complex, mostly open source, and locally runnable compared to the Amazon rube goldberg machine.
- moduspol 4y ago
  There will be substantial amounts of code you are writing to provision, set up, maintain, scale, and troubleshoot all of those things. Whether you call it app code or not, it's something that you (and your team) will be on the hook for building and maintaining over time. Getting your Java Spring web server to scale to thousands of concurrent instances will require a lot of undifferentiated work outside the scope of Java Spring. Same with the care and feeding of RabbitMQ and Kafka. And to suggest that's the approach that's less of a Rube Goldberg machine is... questionable.
  - marginalia_nu 4y ago
    What sort of application are you building where you need a thousand instances of a spring application? Like even hosted on a low powered hardware, Java services can easily deal with order of 100 requests/second. This is home turf, this is what Java is really good at. That 100rps may be lowballing it. So you're what, processing 100k+ API requests per second? I can't imagine that would translate toward any less than a billion users. At that point you are either making good headway toward becoming a new letter in the FAANG acronym and ought to have the budget to run your own data center, or your attention is better put toward optimizing your comically inefficient application.
    - moduspol 4y ago
      Or this Java-based Spring application is one of dozens or hundreds of ones built by different teams, for different customers, or for different purposes. Some of them may even be applications not built in Java or Spring. You're missing the point, though.
    - abofh 4y ago
      What sort of app code are you writing where you can keep data, authentication and user data all on the desktop? Just because you can write a docker-compose.yml (or do without) that describes a system that holds together, doesn't mean the system you've produced stands the chance at SOC2 or whatever standard you hold dear. Having just finished a 27001 audit, I promise, "we rely on AWS for X" went a lot farther than "we have a homegrown system that does X", every single time. AWS - box checked, homegrown? Let's dig in for two more hours. Thousands of instances is easy to need - if you have an active CI/CD lifecycle - you just might not need them all at once. Even just one per PR and it adds up super fast if you've got a competent developer team.

likeabbas 4y ago

I love CDK but it does have issues. Like if you wanted to launch your load balancer in a new AZ you would need to structure the code to carefully create the new infrastructure, pivot your DNS to point to the new load balancer, then you can delete the old infra. It’s more complicated then just adding more subnets unfortunately

specialp 4y ago

I would also be interested in what would be the alternative not in the cloud? AWS deployments can get complicated due to the IAM rules, networking rules, security groups. But if I told someone, bring up a stack like that on bare metal, and make it repeatable what would that be? For those of us that have worked on systems pre-cloud it does feel sometimes that it was easier in the past. But if you went to explain to someone new what to do, you realize how much you are taking for granted the knowledge and effort involved. Also the long term maintenance.