8 ms·

I have worked with database code that was meant to only work with the database it was running on, and database code that was meant to be agnostic to what databa

by cwyers 8y ago

I have worked with database code that was meant to only work with the database it was running on, and database code that was meant to be agnostic to what database you used. I always thought that the costs of the second were underappreciated relative to their benefits. And unless you're actively maintaining running on more than one database (as in, shipping a product where your users have more than one database) you tend to miss all the implicit ways you come to depend on the implementation you're on -- yes, the syntax may be the same across databases, but performance impacts are different, and so you tend to optimize based on the performance of the database you're on. I suspect the same is true for cloud. Real portability has real costs, and if you aren't incurring all of them up front and validating that you're doing the right things to make it work, then incurring part of them up front is probably just a form of premature optimization. At the end of the day, all else being equal, it's easier to port a smaller codebase to new dependencies than a larger one, and attempting to be platform-agnostic tends to result in more code as you have to write a lot of code that your platform would otherwise provide you.

benjaminwootton 8y ago
The big difference with something like PL/SQL is that it’s a proprietary language, whereas lambda and the other faas options are based on open languages. Makes portability somewhat easier to achieve.
- Cthulhu_ 8y ago
  For sure; the external interface of a lambda is trivial, that is, a single entrypoint function with an 'event'. It's relatively easy to create a simple wrapper around that to make it either provider agnostic or self-hosted.
  - collyw 8y ago
    I haven't used lambda but it sounds remarkably similar to a Django function. In Django urls point to a function. Your request matches that url, that function gets run. Lambda must have some similar sort of mapping of urls to functions, so what exactly are you saving with it? Ok, Django includes an ORM, but if you are using any sort of persistence you will need a database layer as well. Can someone explain what all the fuss is about or what I am missing?
    - cthalupa 8y ago
      If you're dealing purely with web requests, then yeah, API Gateway + Lambda sounds pretty similar to a Django function. But having used both, it's a lot easier and faster to setup API GW and Lambda than it is a Django app. And if you're not dealing with purely web requests, then they're very different. Most of my lambdas trigger off of Kinesis, SNS, and SQS events. Work gets sent to these queues/notification endpoints, and then the Lambda function does work based off the data received there, and scales to handle the amount of data automatically.
k__ 8y ago
This. Funny thing is, the fact alone that you create a provider-agnostic system can give you enough performance or cost penalties that you want to change providers in the first place. You can't use provider specific optimizations, so the provider seems bad and you don't wanna use it.
jasonkester 8y ago
It’s not just portability that’s an issue with lambda. It’s also churn. Running on Lambda, one day you’ll get an email saying that we’re deprecating node version x.x so be sure to upgrade your app by June 27th when we pull the plug. Now you have to pull the team back together and make a bunch of changes to an old, working, app just to meet some 3rd party’s arbitrary timeframe. If you’re running node x.x on your own backend, you can choose to simply keep doing so for as long as you want, regardless of what version the cool kids are using these days. That’s the issue I find myself up against more often when relying on Other People’s Infrastructure.
- simonebrunozzi 8y ago
  Good point, but no. If you have architected your apps properly, decommissioning or sunsetting services or individual components should already have been designed and planned. I know, I know... It's almost never the case.
  - yeahitslikethat 8y ago
    You really just don't have to think like this on the msft stack. I'm so glad I chose msft ASP 20 years ago, instead of php, or RoR or python, or node or any of the myriad other stacks that have come and gone since.
    - jjuel 8y ago
      Do you ever need to update your servers to a newer version like say 2016 or now 2019? There are definitely issues on using say old VB6 libraries when you need to upgrade your severs from 2008 to 2019. Not to mention using those old technologies if you do have a new feature or change you end up with an unmaintainable mess. I am MSFT stack programmer, but to claim there are no issues and you just need to patch a server is flat out wrong.
- benbristow 8y ago
  That's just laziness on your part though. Using an old version of Node is just going to leave you with worse performance and potentially security holes.
marvin 8y ago
Good points, but it remains to be seen whether the portability of large serverless apps is sufficient to prevent the providers from squeezing their customers once they are deeply established. The fact that there’s three major cloud providers (who will at the very least compete on customer acquisition) is a point in favor of this, but it’s definitely an experiment. In my mind, this is as much about negotiating power as it is about technical tradeoffs.
- eloisant 8y ago
  Well, there is a cost to be portable and the cost to adapt an app that's not portable. Whether it's DB independence or cloud provider independence, from my experience it's cheaper to pay the cost of the migration when you know you want to migrate (even if it involves rewriting some parts) rather than paying it everyday by writing portable code. Most of the time the portable code you write becomes obsolete before you want to port it.
  - geertj 8y ago
    > it's cheaper to pay the cost of the migration when you know you want to migrate Agreed, on principle and based on experience. This does require you have reasonable abstractions in place as otherwise you’ll end up refactoring before you can migrate. But that’s a good thing in any case.
hevi_jos 8y ago
There are also a terrible cost of running just on one database, the dependency on just one provider. In business you should never depend on just one provider. This provider could be the best in the world, now, because it has amazing management. But people die, or are hit by a bus, or get crazy after a divorce or just retire and they get replaced by the antitheses. In my personal experience, real portability has great benefits on their own. Design is easier to understand and you constantly find bugs thanks to running your software in different architectures, compilers and so on. At the end of the day, it is the quality of your team. If your team is bad, your software will be bad and vice versa.
AJ007 8y ago
The unifying lesson I've been appreciating after reaching my 30s is that in order to make good decisions, an individual needs to have a very clear understanding of how something works. If you know how something works, then you can foresee problems. You can explain the correct use cases for a particular tool. You know the downsides just as well as the upsides for a particular choice. In software development, a lot of the new stuff that is supposed to solve our problems just shifts those problems somewhere else -- at best. At worst, it hides the problems or amplifies them. This isn't unique to software development, but it seems to be particularly pervasive because so much is invisible at the onset of use. Best advice, be very suspicious when someone can't explain what the bad parts are.

by cwyers 8y ago

benjaminwootton 8y ago

The big difference with something like PL/SQL is that it’s a proprietary language, whereas lambda and the other faas options are based on open languages. Makes portability somewhat easier to achieve.

Cthulhu_ 8y ago
For sure; the external interface of a lambda is trivial, that is, a single entrypoint function with an 'event'. It's relatively easy to create a simple wrapper around that to make it either provider agnostic or self-hosted.
- collyw 8y ago
  I haven't used lambda but it sounds remarkably similar to a Django function. In Django urls point to a function. Your request matches that url, that function gets run. Lambda must have some similar sort of mapping of urls to functions, so what exactly are you saving with it? Ok, Django includes an ORM, but if you are using any sort of persistence you will need a database layer as well. Can someone explain what all the fuss is about or what I am missing?
  - cthalupa 8y ago
    If you're dealing purely with web requests, then yeah, API Gateway + Lambda sounds pretty similar to a Django function. But having used both, it's a lot easier and faster to setup API GW and Lambda than it is a Django app. And if you're not dealing with purely web requests, then they're very different. Most of my lambdas trigger off of Kinesis, SNS, and SQS events. Work gets sent to these queues/notification endpoints, and then the Lambda function does work based off the data received there, and scales to handle the amount of data automatically.

k__ 8y ago

This. Funny thing is, the fact alone that you create a provider-agnostic system can give you enough performance or cost penalties that you want to change providers in the first place. You can't use provider specific optimizations, so the provider seems bad and you don't wanna use it.

jasonkester 8y ago

It’s not just portability that’s an issue with lambda. It’s also churn. Running on Lambda, one day you’ll get an email saying that we’re deprecating node version x.x so be sure to upgrade your app by June 27th when we pull the plug. Now you have to pull the team back together and make a bunch of changes to an old, working, app just to meet some 3rd party’s arbitrary timeframe. If you’re running node x.x on your own backend, you can choose to simply keep doing so for as long as you want, regardless of what version the cool kids are using these days. That’s the issue I find myself up against more often when relying on Other People’s Infrastructure.

simonebrunozzi 8y ago
Good point, but no. If you have architected your apps properly, decommissioning or sunsetting services or individual components should already have been designed and planned. I know, I know... It's almost never the case.
- yeahitslikethat 8y ago
  You really just don't have to think like this on the msft stack. I'm so glad I chose msft ASP 20 years ago, instead of php, or RoR or python, or node or any of the myriad other stacks that have come and gone since.
  - jjuel 8y ago
    Do you ever need to update your servers to a newer version like say 2016 or now 2019? There are definitely issues on using say old VB6 libraries when you need to upgrade your severs from 2008 to 2019. Not to mention using those old technologies if you do have a new feature or change you end up with an unmaintainable mess. I am MSFT stack programmer, but to claim there are no issues and you just need to patch a server is flat out wrong.
benbristow 8y ago
That's just laziness on your part though. Using an old version of Node is just going to leave you with worse performance and potentially security holes.

marvin 8y ago

Good points, but it remains to be seen whether the portability of large serverless apps is sufficient to prevent the providers from squeezing their customers once they are deeply established. The fact that there’s three major cloud providers (who will at the very least compete on customer acquisition) is a point in favor of this, but it’s definitely an experiment. In my mind, this is as much about negotiating power as it is about technical tradeoffs.

eloisant 8y ago
Well, there is a cost to be portable and the cost to adapt an app that's not portable. Whether it's DB independence or cloud provider independence, from my experience it's cheaper to pay the cost of the migration when you know you want to migrate (even if it involves rewriting some parts) rather than paying it everyday by writing portable code. Most of the time the portable code you write becomes obsolete before you want to port it.
- geertj 8y ago
  > it's cheaper to pay the cost of the migration when you know you want to migrate Agreed, on principle and based on experience. This does require you have reasonable abstractions in place as otherwise you’ll end up refactoring before you can migrate. But that’s a good thing in any case.

hevi_jos 8y ago

There are also a terrible cost of running just on one database, the dependency on just one provider. In business you should never depend on just one provider. This provider could be the best in the world, now, because it has amazing management. But people die, or are hit by a bus, or get crazy after a divorce or just retire and they get replaced by the antitheses. In my personal experience, real portability has great benefits on their own. Design is easier to understand and you constantly find bugs thanks to running your software in different architectures, compilers and so on. At the end of the day, it is the quality of your team. If your team is bad, your software will be bad and vice versa.

AJ007 8y ago

The unifying lesson I've been appreciating after reaching my 30s is that in order to make good decisions, an individual needs to have a very clear understanding of how something works. If you know how something works, then you can foresee problems. You can explain the correct use cases for a particular tool. You know the downsides just as well as the upsides for a particular choice. In software development, a lot of the new stuff that is supposed to solve our problems just shifts those problems somewhere else -- at best. At worst, it hides the problems or amplifies them. This isn't unique to software development, but it seems to be particularly pervasive because so much is invisible at the onset of use. Best advice, be very suspicious when someone can't explain what the bad parts are.