Hi Rafal,
Firstly, thanks for your comment. It doesn't offend me at all — it's important to constructively debate these issues 🙂
You are right that serverless architectures (currently) do enforce a lock-in moreso than container or VM-based apps/workloads.
I don't think the issue of lock-in with the functions themselves is that big of an issue. By that, I mean that it wouldn't require that much work to refactor the code inside functions from say AWS Lambda to work in Azure Functions as the function signatures are very similar. I wrote about FaaS vendor lock-in here.
However, the main lock-in comes with using the other proprietary services from the same cloud provider that the function calls out to (e.g. S3, DynamoDB, SNS, SQS, etc). Rewriting your app to use other services in the event of migrating to another cloud would be a big job. As a big open-source fan, I would love to see AWS (and the other cloud providers) provide more open-source serverless services, but that's not where we are today.
Ultimately, it really comes down to how much of a risk this lock-in really is to you or your company.
What are the chances that you might need to switch cloud provider at some point in the future? What reasons would trigger this move?
Many container-based solutions I've seen also make use of these proprietary services anyway so it's not solely a serverless issue (albeit it's more prominent there).
Moreover, do the other benefits of getting your app developed faster and cost savings from a paid-for-usage bill and less time spent on traditional ops outweigh this risk? I personally think that in the majority of cases, they do.
Regarding your PaaS vs FaaS question - by PaaS, are you talking about the likes of Heroku, AWS Elastic Beanstalk and Azure Web Apps?
I haven't written an article doing this comparison.
They do share the benefit of being able to get up and running quickly with less server management but I guess I would say the main difference between using these services vs a serverless (FaaS + BaaS) architecture is that when they scale they tend to get very expensive quickly. You hear lots of stories of companies outgrowing Heroku and then moving to EC2 on AWS. This shouldn't happen with serverless.
I'm focused on developing and expanding my knowledge and skills. Enjoying new challenges. I'm assuming that there are no stupid questions, there are only silly answers.
Thanks for your replay. I missed your article about FaaS vendor lock-in. I think it hits the point.
As you wrote, it isn't hard to migrate the function body itself. The real problem is the ecosystem supplied by the cloud provider. As you said, It isn't likely that I’ll have to migrate my solution between cloud providers. But I don't like the feeling that migration could be painful.
Thanks again for sharing your opinion and experience. It was a pleasure to read your article and participate in the discussion.
I’m looking forward to the next article from you.
Hi Rafal,
Firstly, thanks for your comment. It doesn't offend me at all — it's important to constructively debate these issues 🙂
You are right that serverless architectures (currently) do enforce a lock-in moreso than container or VM-based apps/workloads.
I don't think the issue of lock-in with the functions themselves is that big of an issue. By that, I mean that it wouldn't require that much work to refactor the code inside functions from say AWS Lambda to work in Azure Functions as the function signatures are very similar. I wrote about FaaS vendor lock-in here.
However, the main lock-in comes with using the other proprietary services from the same cloud provider that the function calls out to (e.g. S3, DynamoDB, SNS, SQS, etc). Rewriting your app to use other services in the event of migrating to another cloud would be a big job. As a big open-source fan, I would love to see AWS (and the other cloud providers) provide more open-source serverless services, but that's not where we are today.
Ultimately, it really comes down to how much of a risk this lock-in really is to you or your company.
What are the chances that you might need to switch cloud provider at some point in the future? What reasons would trigger this move?
Many container-based solutions I've seen also make use of these proprietary services anyway so it's not solely a serverless issue (albeit it's more prominent there).
Moreover, do the other benefits of getting your app developed faster and cost savings from a paid-for-usage bill and less time spent on traditional ops outweigh this risk? I personally think that in the majority of cases, they do.
Regarding your PaaS vs FaaS question - by PaaS, are you talking about the likes of Heroku, AWS Elastic Beanstalk and Azure Web Apps?
I haven't written an article doing this comparison.
They do share the benefit of being able to get up and running quickly with less server management but I guess I would say the main difference between using these services vs a serverless (FaaS + BaaS) architecture is that when they scale they tend to get very expensive quickly. You hear lots of stories of companies outgrowing Heroku and then moving to EC2 on AWS. This shouldn't happen with serverless.
Thanks for your replay. I missed your article about FaaS vendor lock-in. I think it hits the point.
As you wrote, it isn't hard to migrate the function body itself. The real problem is the ecosystem supplied by the cloud provider. As you said, It isn't likely that I’ll have to migrate my solution between cloud providers. But I don't like the feeling that migration could be painful.
Thanks again for sharing your opinion and experience. It was a pleasure to read your article and participate in the discussion.
I’m looking forward to the next article from you.
Cheers.
Regarding minimising the pain / risk of vendor lock in, Pulumi looks interesting (haven't used it in anger so YMMV): pulumi.com