5 ms·

I would think the biggest concern with "Serverless" would be vendor lock in. If a large portion of your SaaS product is "serverless" it's going to be very diffi

I would think the biggest concern with "Serverless" would be vendor lock in. If a large portion of your SaaS product is "serverless" it's going to be very difficult to move when company A raises their prices, or company B comes in with a much more compelling product or price point. Admittedly I don't know enough about the details to know how big of a deal this could be, or whether there is work toward a universal "serverless" standard. But I don't want Amazon/Google/Whoever suddenly raising their rates 2 years from now causing my startup to go under because the margins are so tight. And for those that say this will never happen, look at what Google just did with their Maps pricing.

taude 8y ago
For a startup, though, if it succeeds, you have to assume that a good portion of the code will eventually be refactored at some point, or retired as the buisiness is flushed out. I have a feeling we'll also see some projects for transferring Lambdas between IaaS providers, including on-Prem at some point. I'd be more concerned about lockin at the DB-level but even that could be accounted for with up-front decisions to not use Dynamo, etc. if you were really concerned.
tnolet 8y ago
Lock in is very easy to avoid. Keep you business logic in separate modules and wrap any specific cloud sdk calls in helper functions. Any major move to a new provider should be much easier. Lock in is often a non-concern if you stick to basic engineering principles.
scarface74 8y ago
The boogie man about serverless is overrated. In the grand scheme of things, at least for AWS, the only thing you do to make your app “serverless” is add a function with two parameters as your entry point. If you’re following standard software engineering principals of keeping your interface and your business logic separate, it’s not that hard. On the other hand, the fear of “vendor lock in” is overrated. You’re always “locked in” to your infrastructure. Companies hardly ever change their infrastructure wholescale. The risk of regressions are too high and it’s usually not worth it. Besides, if you rely on AWS services and are letting AWS do the “undifferentiated heavy lifting”, converting lambdas is the least of your issues. If you are just using AWS to host a bunch of VMs, congratulations, you now have the worse of all worlds. You’re spending more than baremetal and you still have all of the management overhead.
petra 8y ago
>> But I don't want Amazon/Google/Whoever suddenly raising their rates 2 years from now causing my startup to go under because the margins are so tight. What kind of businesses run on very tight margins, that even some increase in the IT bill can cause them to fail ?
- joekrill 8y ago
  > What kind of businesses run on very tight margins, that even some increase in the IT bill can cause them to fail ? Well, Startups! That's sort of common for startups, isn't it? I realize the term is basically being used to describe almost all "small businesses" these days, but I think it's fairly common for startups to have very short runway. That would (ideally) get longer as the startup matures. But I don't think it's uncommon at all.
dyeje 8y ago
There are frameworks like Serverless [1] that allow you to deploy to different public clouds so vendor lock in isn’t a huge issue. [1] https://serverless.com/ https://serverless.com/

taude 8y ago

For a startup, though, if it succeeds, you have to assume that a good portion of the code will eventually be refactored at some point, or retired as the buisiness is flushed out. I have a feeling we'll also see some projects for transferring Lambdas between IaaS providers, including on-Prem at some point. I'd be more concerned about lockin at the DB-level but even that could be accounted for with up-front decisions to not use Dynamo, etc. if you were really concerned.

tnolet 8y ago

Lock in is very easy to avoid. Keep you business logic in separate modules and wrap any specific cloud sdk calls in helper functions. Any major move to a new provider should be much easier. Lock in is often a non-concern if you stick to basic engineering principles.

scarface74 8y ago

The boogie man about serverless is overrated. In the grand scheme of things, at least for AWS, the only thing you do to make your app “serverless” is add a function with two parameters as your entry point. If you’re following standard software engineering principals of keeping your interface and your business logic separate, it’s not that hard. On the other hand, the fear of “vendor lock in” is overrated. You’re always “locked in” to your infrastructure. Companies hardly ever change their infrastructure wholescale. The risk of regressions are too high and it’s usually not worth it. Besides, if you rely on AWS services and are letting AWS do the “undifferentiated heavy lifting”, converting lambdas is the least of your issues. If you are just using AWS to host a bunch of VMs, congratulations, you now have the worse of all worlds. You’re spending more than baremetal and you still have all of the management overhead.

petra 8y ago

>> But I don't want Amazon/Google/Whoever suddenly raising their rates 2 years from now causing my startup to go under because the margins are so tight. What kind of businesses run on very tight margins, that even some increase in the IT bill can cause them to fail ?

joekrill 8y ago
> What kind of businesses run on very tight margins, that even some increase in the IT bill can cause them to fail ? Well, Startups! That's sort of common for startups, isn't it? I realize the term is basically being used to describe almost all "small businesses" these days, but I think it's fairly common for startups to have very short runway. That would (ideally) get longer as the startup matures. But I don't think it's uncommon at all.

dyeje 8y ago

There are frameworks like Serverless [1] that allow you to deploy to different public clouds so vendor lock in isn’t a huge issue. [1] https://serverless.com/ https://serverless.com/