5 ms·

> Unfortunately, much of the current literature around serverless architecture focuses solely on its benefits. This article suffers from the same problem thoug

> Unfortunately, much of the current literature around serverless architecture focuses solely on its benefits. This article suffers from the same problem though. Where are the downsides? What about production debugging? Moving complexity from inside of services to service interoperability? Vendor lock-in? Lack of human support? Etc.

scarface74 7y ago
Vendor lock-in from serverless -- It's not the boogeyman that many people make it out to be. Two broad use cases for serverless -- event based triggers and APIs. With event based triggers you're already locked in by the events you're subscribing to and as far as API's, at least with AWS, if you're using proxy integration, you can use your standard Node/Express, C#/WebAPI, Python/Flask, etc. framework. You add a few lines of code for the lambda proxy but you can use the same code without any changes with your standard web servers. With AWS, you also have "serverless Docker" with Fargate and you use standard Docker containers. Production debugging? The same issues and solutions with any micro-service implementation. The solution usually being a common logging infrastructure. On a broader scale, "vendor lock in" is severely overrated. Despite all of the "repository patterns that will let us hypothetically move our million dollar Oracle implementation to MySql", it rarely happens and often you end up with sub optimal and more expensive/harder to maintain solutions by not going all in on your vendor's of choice solution.
- closeparen 7y ago
  > The same issues and solutions with any micro-service implementation. The solution usually being a common logging infrastructure. A mature service mesh will let privileged users get inside containers to attach profilers and debuggers, manually as needed or systematically through performance monitoring tools, in situ or with temporary exclusion from the load balancer pool. It's also sometimes necessary to correlate issues with host-level metrics to understand weirder bottlenecks and tail latency issues. > it rarely happens The credible threat of it happening keeps prices low enough to make it unnecessary.
  - scarface74 7y ago
    The credible threat of it happening keeps prices low enough to make it unnecessary. As far as vendor lock in, in general not just with respect to the cloud, there are so many path dependencies and the risk of disruption versus the reward is so rarely worth it, it hardly ever happens. How much would Oracle or Microsoft have to raise their prices on their database products for instance to make it worthwhile for a large enterprise company to move away from them to an open source alternative?
    - wstrange 7y ago
      A lot of CIOs would dearly love to move away from Oracle. The cost of rewriting software that was not designed to be portable is immense. Oracle knows this, and keeps the pain just below the threshold where porting to postgres or mysql is cost effective. I agree with the general sentiment that optimizing for extreme portability does not make sense- but there is a balance that needs to be struck. Designing your apps to be relatively SQL agnostic, or at least isolating those dependencies, makes a lot of sense.
      - scarface74 7y ago
        And even if you do have a policy of “designing your apps to be SQL agnostic” and you have had that policy for 5 years over dozens of apps. Would you trust your policy enough that you would change your connection string from pointing to Oracle to pointing to MySQL and hope everything would work? What about all of the programs that you used that depended on Oracle specific drivers. Even in a perfect world where everything was using standard SQL, would the regression testing and migrations be something you would want to tackle as a CTO? Would you be willing to take the reputational risks of something going wrong?

scarface74 7y ago

Vendor lock-in from serverless -- It's not the boogeyman that many people make it out to be. Two broad use cases for serverless -- event based triggers and APIs. With event based triggers you're already locked in by the events you're subscribing to and as far as API's, at least with AWS, if you're using proxy integration, you can use your standard Node/Express, C#/WebAPI, Python/Flask, etc. framework. You add a few lines of code for the lambda proxy but you can use the same code without any changes with your standard web servers. With AWS, you also have "serverless Docker" with Fargate and you use standard Docker containers. Production debugging? The same issues and solutions with any micro-service implementation. The solution usually being a common logging infrastructure. On a broader scale, "vendor lock in" is severely overrated. Despite all of the "repository patterns that will let us hypothetically move our million dollar Oracle implementation to MySql", it rarely happens and often you end up with sub optimal and more expensive/harder to maintain solutions by not going all in on your vendor's of choice solution.

closeparen 7y ago
> The same issues and solutions with any micro-service implementation. The solution usually being a common logging infrastructure. A mature service mesh will let privileged users get inside containers to attach profilers and debuggers, manually as needed or systematically through performance monitoring tools, in situ or with temporary exclusion from the load balancer pool. It's also sometimes necessary to correlate issues with host-level metrics to understand weirder bottlenecks and tail latency issues. > it rarely happens The credible threat of it happening keeps prices low enough to make it unnecessary.
- scarface74 7y ago
  The credible threat of it happening keeps prices low enough to make it unnecessary. As far as vendor lock in, in general not just with respect to the cloud, there are so many path dependencies and the risk of disruption versus the reward is so rarely worth it, it hardly ever happens. How much would Oracle or Microsoft have to raise their prices on their database products for instance to make it worthwhile for a large enterprise company to move away from them to an open source alternative?
  - wstrange 7y ago
    A lot of CIOs would dearly love to move away from Oracle. The cost of rewriting software that was not designed to be portable is immense. Oracle knows this, and keeps the pain just below the threshold where porting to postgres or mysql is cost effective. I agree with the general sentiment that optimizing for extreme portability does not make sense- but there is a balance that needs to be struck. Designing your apps to be relatively SQL agnostic, or at least isolating those dependencies, makes a lot of sense.
    - scarface74 7y ago
      And even if you do have a policy of “designing your apps to be SQL agnostic” and you have had that policy for 5 years over dozens of apps. Would you trust your policy enough that you would change your connection string from pointing to Oracle to pointing to MySQL and hope everything would work? What about all of the programs that you used that depended on Oracle specific drivers. Even in a perfect world where everything was using standard SQL, would the regression testing and migrations be something you would want to tackle as a CTO? Would you be willing to take the reputational risks of something going wrong?