7 ms·

"Think of the history of data access strategies to come out of Microsoft. ODBC, RDO, DAO, ADO, OLEDB, now ADO.NET – All New! Are these technological imperatives

by iends 5y ago

"Think of the history of data access strategies to come out of Microsoft. ODBC, RDO, DAO, ADO, OLEDB, now ADO.NET – All New! Are these technological imperatives? The result of an incompetent design group that needs to reinvent data access every goddamn year? (That’s probably it, actually.) But the end result is just cover fire. The competition has no choice but to spend all their time porting and keeping up, time that they can’t spend writing new features. Look closely at the software landscape. The companies that do well are the ones who rely least on big companies and don’t have to spend all their cycles catching up and reimplementing and fixing bugs that crop up only on Windows XP." - Fire And Motion, Joel on Software In my own work with serverless I think about this a lot. In my day job, we built a new service and we pay AWS a few dollars per month to run. It would have cost us around $100 a month in AWS costs. However, the operational complexity is extremely high and we are also coupled to another service via Kinesis. For a billion dollar business, the trade off doesn't seem worth it. I wonder how much of serverless is just AWS firing at Google (and Heroku, DO, etc) and other competitors. It certainly hasn't made my life as a developer easier. It's certainly much cheaper for some use cases but the complexity of the system goes up very quickly, and you're end up having to manage a lot of that complexity using an inferior tool like Cloud Formation (or Terraform).

mattmanser 5y ago
It's like the SPA craze, microservices craze, NoSQL craze or similar things. Appropriate for a small amount of apps, but used inappropriately by a lot more for a while because it's the hot new thing.
- AlphaSite 5y ago
  IMO SPA is the natural consequence of API 1st design, of you can do everything via the API why reimplement it all again for the UI, as much as it sucks in some ways, it can yield really good results.
  - paulryanrogers 5y ago
    I agree this is natural outcome when developer time is precious, though sometimes increases complexity for the user and their browser. And if one doesn't need an API first design then SSR with a robust framework might be cheaper to stand up and maintain.
  - rsj_hn 5y ago
    Because you can never implement everything only via the API, anymore than you can implement everything via SQL queries. The reason why people created custom business logic atop the data model is .... because they need custom business logic atop the data model. Oh, you want to require a captcha before allowing someone to view a record? Well, that's not gonna be in your api. It's business logic sitting ontop of it. The reason people "do" API 1st design is just that they haven't thought these use cases through very well and it all makes sense until you start looking at the details of what your business logic is actually doing. Then it's up to everyone else to either convince the decision makers that no, this really is API first design so they get the buzzword crowd off their back, or they just drop the ability to securely do custom business logic and hope no one notices.
    - robertlagrant 5y ago
      I think you have an overly specific interpretation of "API".
orf 5y ago
> I wonder how much of serverless is just AWS firing at Google (and Heroku, DO, etc) and other competitors. It depends on what you mean by "serverless". Serverless webapps? Sure, maybe a fair bit. But the real killer feature of the Lambda service is that it's a universal extension mechanism for other AWS services. Want to run some shoddy virus scanning whenever an object is added to a bucket for compliance reasons? That's a lambda. Want to manipulate Firehose records before they are sent to the sink? That's a lambda. Want to execute some crazy Python function from an Athena SQL query? You guessed it. That's a lambda. So when you say "It certainly hasn't made my life as a developer easier" it means you haven't needed to do these bespoke gluing together of stuff, because "being able to do this somehow" is infinitely easier than "not being able to do it at all because AWS hasn't exposed an API for this use case".
- crummy 5y ago
  So is the solution to avoid Lambda unless you have to? Don't use it to build regular software, just use it for AWS glue when necessary?
  - orf 5y ago
    That’s the use case where it shines, but it can be an effective part of “regular software” as well. It’s a hammer, and if it’s a good fit for your particular nail is very dependent on it’s shape.
  - rualca 5y ago
    > So is the solution to avoid Lambda unless you have to? Don't use it to build regular software, just use it for AWS glue when necessary? That, and also offload some somewhat computationally expensive background tasks. Instead if screwing up your deployments by ramping up CPU and memory utilization to run a one-off task, just let he service fire a lambda and, if needed, just act when the lambda replies back.
  - Boxxed 5y ago
    Just want to pile-on to the other replies and say yes, absolutely. When you need them as glue they're a great option with basically no alternatives -- also means your lambda functions will be just a handful of lines of code, and then you can get on with your life.
rualca 5y ago
> It's certainly much cheaper for some use cases but the complexity of the system goes up very quickly, and you're end up having to manage a lot of that complexity using an inferior tool like Cloud Formation (or Terraform). The complexity bogeyman is a red herring. What is software development if not a constant fight between increasing complexity and adding features, including making systems more robust and resilient and reliable? Sure, you are free to claim that function-as-a-service paradigm is very complex because the code runs somewhere else, and you have to use a separate workflow than the one you're used to, and that you actually have to write unit tests to have some assurances that stuff does work as expected. But what would be the alternative approach? Would it be simpler to write a full-blown service that polls events and listens to message queues and launches background tasks? Obviously, no. AWS Lambda is a fancy way to let developers develop event-driven systems by just writing tiny event handlers and plug in events. It's no rocket science. In terms of complexity, they pale in comparison with even the tiniest hello world windows GUI app, or even Qt. I'm terms of web services, they are a service where you just have to write the request controller bit after that runs after all auth things passed and request messages were parsed and validated. Considering this, isn't it unreasonable to talk about increasing complexity, when everything was made.far simpler than what it would otherwise be?
- paulryanrogers 5y ago
  For a static site or basic CRUD some alternatives are bog standard HTML, CSS and maybe SSR framework
  - edmundsauto 5y ago
    Wouldn't those be a bad fit for AWS Lambda, even by the opinions of most proponents of the service? IMO, one of the Netlify clones (JAMStack) is the best solution for these, so if you're running your own VPS for a static site, you're also not using the best tool for the job.
    - dragonwriter 5y ago
      > Wouldn't those be a bad fit for AWS Lambda, even by the opinions of most proponents of the service? Static site? Yes. Basic CRUD? Not sure about cost efficiency, but otherwise that’s right in the APIGateway+Lambda wheelhouse.

by iends 5y ago

mattmanser 5y ago

It's like the SPA craze, microservices craze, NoSQL craze or similar things. Appropriate for a small amount of apps, but used inappropriately by a lot more for a while because it's the hot new thing.

AlphaSite 5y ago
IMO SPA is the natural consequence of API 1st design, of you can do everything via the API why reimplement it all again for the UI, as much as it sucks in some ways, it can yield really good results.
- paulryanrogers 5y ago
  I agree this is natural outcome when developer time is precious, though sometimes increases complexity for the user and their browser. And if one doesn't need an API first design then SSR with a robust framework might be cheaper to stand up and maintain.
- rsj_hn 5y ago
  Because you can never implement everything only via the API, anymore than you can implement everything via SQL queries. The reason why people created custom business logic atop the data model is .... because they need custom business logic atop the data model. Oh, you want to require a captcha before allowing someone to view a record? Well, that's not gonna be in your api. It's business logic sitting ontop of it. The reason people "do" API 1st design is just that they haven't thought these use cases through very well and it all makes sense until you start looking at the details of what your business logic is actually doing. Then it's up to everyone else to either convince the decision makers that no, this really is API first design so they get the buzzword crowd off their back, or they just drop the ability to securely do custom business logic and hope no one notices.
  - robertlagrant 5y ago
    I think you have an overly specific interpretation of "API".

orf 5y ago

> I wonder how much of serverless is just AWS firing at Google (and Heroku, DO, etc) and other competitors. It depends on what you mean by "serverless". Serverless webapps? Sure, maybe a fair bit. But the real killer feature of the Lambda service is that it's a universal extension mechanism for other AWS services. Want to run some shoddy virus scanning whenever an object is added to a bucket for compliance reasons? That's a lambda. Want to manipulate Firehose records before they are sent to the sink? That's a lambda. Want to execute some crazy Python function from an Athena SQL query? You guessed it. That's a lambda. So when you say "It certainly hasn't made my life as a developer easier" it means you haven't needed to do these bespoke gluing together of stuff, because "being able to do this somehow" is infinitely easier than "not being able to do it at all because AWS hasn't exposed an API for this use case".

crummy 5y ago
So is the solution to avoid Lambda unless you have to? Don't use it to build regular software, just use it for AWS glue when necessary?
- orf 5y ago
  That’s the use case where it shines, but it can be an effective part of “regular software” as well. It’s a hammer, and if it’s a good fit for your particular nail is very dependent on it’s shape.
- rualca 5y ago
  > So is the solution to avoid Lambda unless you have to? Don't use it to build regular software, just use it for AWS glue when necessary? That, and also offload some somewhat computationally expensive background tasks. Instead if screwing up your deployments by ramping up CPU and memory utilization to run a one-off task, just let he service fire a lambda and, if needed, just act when the lambda replies back.
- Boxxed 5y ago
  Just want to pile-on to the other replies and say yes, absolutely. When you need them as glue they're a great option with basically no alternatives -- also means your lambda functions will be just a handful of lines of code, and then you can get on with your life.

rualca 5y ago

> It's certainly much cheaper for some use cases but the complexity of the system goes up very quickly, and you're end up having to manage a lot of that complexity using an inferior tool like Cloud Formation (or Terraform). The complexity bogeyman is a red herring. What is software development if not a constant fight between increasing complexity and adding features, including making systems more robust and resilient and reliable? Sure, you are free to claim that function-as-a-service paradigm is very complex because the code runs somewhere else, and you have to use a separate workflow than the one you're used to, and that you actually have to write unit tests to have some assurances that stuff does work as expected. But what would be the alternative approach? Would it be simpler to write a full-blown service that polls events and listens to message queues and launches background tasks? Obviously, no. AWS Lambda is a fancy way to let developers develop event-driven systems by just writing tiny event handlers and plug in events. It's no rocket science. In terms of complexity, they pale in comparison with even the tiniest hello world windows GUI app, or even Qt. I'm terms of web services, they are a service where you just have to write the request controller bit after that runs after all auth things passed and request messages were parsed and validated. Considering this, isn't it unreasonable to talk about increasing complexity, when everything was made.far simpler than what it would otherwise be?

paulryanrogers 5y ago
For a static site or basic CRUD some alternatives are bog standard HTML, CSS and maybe SSR framework
- edmundsauto 5y ago
  Wouldn't those be a bad fit for AWS Lambda, even by the opinions of most proponents of the service? IMO, one of the Netlify clones (JAMStack) is the best solution for these, so if you're running your own VPS for a static site, you're also not using the best tool for the job.
  - dragonwriter 5y ago
    > Wouldn't those be a bad fit for AWS Lambda, even by the opinions of most proponents of the service? Static site? Yes. Basic CRUD? Not sure about cost efficiency, but otherwise that’s right in the APIGateway+Lambda wheelhouse.