5 ms·

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

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.
      - naniwaduni 4y ago
        Strong "forgotten how to count that low" vibes from this one.
  - tpxl 4y ago
    > There will be substantial amounts of code you are writing to provision, set up, maintain, scale, and troubleshoot all of those things. And the amount of infra code you have to write to do that in AWS is any less? No, it's just as much, except more arcane. > 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. Scaling a RESTful webserver is an exercise in slapping a load balancer in front of it and running a few more instances. Not exactly rocket science. > Same with the care and feeding of RabbitMQ and Kafka Same on AWS, except now you are at the mercy of someone else's whims to see this works when it fails.
    - moduspol 4y ago
      > And the amount of infra code you have to write to do that in AWS is any less? No, it's just as much, except more arcane. It's substantially less, and declarative. It also includes stuff commonly pushed to phase 2 in on-prem deployments, like TLS between entities, proper IAM, and built-in metrics/logging. > Scaling a RESTful webserver is an exercise in slapping a load balancer in front of it and running a few more instances. Not exactly rocket science. If it's stateless, yes, though I was just responding to an example. Not all technical problems are so simple. > Same on AWS, except now you are at the mercy of someone else's whims to see this works when it fails. The business is always at the mercy of someone "else," whether it's you, the person who replaced you, or AWS. And AWS is way better at keeping S3 running at scale and maintaining this stuff over time than your average IT / DevOps employee. Same with Lambda, Kinesis, DynamoDB, SQS, etc. Unless you've got special requirements, you're wasting time and resources reinventing the wheel.
      - tpxl 4y ago
        > It's substantially less, and declarative There are declarative ways to manage bare metal machines, such as terraform, nix and puppet. > And AWS is way better at keeping S3 running at scale and maintaining this stuff over time than your average IT / DevOps employee Yeah no, the outages we faced _because_ of AWS were way, way worse than what we faced with our average IT/DevOps employees at my old jobs. This keeps getting repeated and it's going to keep being wrong.

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.
    - naniwaduni 4y ago
      Strong "forgotten how to count that low" vibes from this one.
- tpxl 4y ago
  > There will be substantial amounts of code you are writing to provision, set up, maintain, scale, and troubleshoot all of those things. And the amount of infra code you have to write to do that in AWS is any less? No, it's just as much, except more arcane. > 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. Scaling a RESTful webserver is an exercise in slapping a load balancer in front of it and running a few more instances. Not exactly rocket science. > Same with the care and feeding of RabbitMQ and Kafka Same on AWS, except now you are at the mercy of someone else's whims to see this works when it fails.
  - moduspol 4y ago
    > And the amount of infra code you have to write to do that in AWS is any less? No, it's just as much, except more arcane. It's substantially less, and declarative. It also includes stuff commonly pushed to phase 2 in on-prem deployments, like TLS between entities, proper IAM, and built-in metrics/logging. > Scaling a RESTful webserver is an exercise in slapping a load balancer in front of it and running a few more instances. Not exactly rocket science. If it's stateless, yes, though I was just responding to an example. Not all technical problems are so simple. > Same on AWS, except now you are at the mercy of someone else's whims to see this works when it fails. The business is always at the mercy of someone "else," whether it's you, the person who replaced you, or AWS. And AWS is way better at keeping S3 running at scale and maintaining this stuff over time than your average IT / DevOps employee. Same with Lambda, Kinesis, DynamoDB, SQS, etc. Unless you've got special requirements, you're wasting time and resources reinventing the wheel.
    - tpxl 4y ago
      > It's substantially less, and declarative There are declarative ways to manage bare metal machines, such as terraform, nix and puppet. > And AWS is way better at keeping S3 running at scale and maintaining this stuff over time than your average IT / DevOps employee Yeah no, the outages we faced _because_ of AWS were way, way worse than what we faced with our average IT/DevOps employees at my old jobs. This keeps getting repeated and it's going to keep being wrong.