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.
I have to admit that I'm not a big fan of the serverless architecture. Maybe someone here will be able to convince me to it :)
The reason why I'm so careful with serverless is that it is tightly coupled with a particular provider. I'm experienced with Azure which provides Azure Functions. At the moment if you decided to use it, you have to use Azure (with small exceptions like using Docker images). I agree that serverless is now cheap but who knows if next year pricing won't kill us. In that case, I can't easily migrate my solution to a competition cloud (like AWS), because my code is connected with Azure solutions.
As I mentioned, I can create a Docker image and migrate it to AWS, but in that case, in my opinion, the idea of serverless is being lost. Azure Function hosted on a Docker container can't use all triggers offered by Azure hosting That is the price of moving solution from the cloud provider :(
You compared IaaS (Infrastructure as a Service) with FaaS (Functions as a Service) in your article. I'm curious how will the compare look like between PaaS (Platform as a Service) and FaaS solution. In the PaaS solution, there is less work to do like no need for Configure route tables, Configure AMIs for your VM instances with specific OS version and any required application software or Set up a secure VPN/SSH bastion instance (and keep it patched). Have you ever compare PaaS vs. FaaS?
I don't want to offend you, so please don't take my comment personally. I'm just looking for someone who convinces me to Serverless and explains my the phenomenon of it.
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.
Nice post.
I have to admit that I'm not a big fan of the serverless architecture. Maybe someone here will be able to convince me to it :)
The reason why I'm so careful with serverless is that it is tightly coupled with a particular provider. I'm experienced with Azure which provides Azure Functions. At the moment if you decided to use it, you have to use Azure (with small exceptions like using Docker images). I agree that serverless is now cheap but who knows if next year pricing won't kill us. In that case, I can't easily migrate my solution to a competition cloud (like AWS), because my code is connected with Azure solutions.
As I mentioned, I can create a Docker image and migrate it to AWS, but in that case, in my opinion, the idea of serverless is being lost. Azure Function hosted on a Docker container can't use all triggers offered by Azure hosting That is the price of moving solution from the cloud provider :(
You compared IaaS (Infrastructure as a Service) with FaaS (Functions as a Service) in your article. I'm curious how will the compare look like between PaaS (Platform as a Service) and FaaS solution. In the PaaS solution, there is less work to do like no need for
Configure route tables,Configure AMIs for your VM instances with specific OS version and any required application softwareorSet up a secure VPN/SSH bastion instance (and keep it patched). Have you ever compare PaaS vs. FaaS?I don't want to offend you, so please don't take my comment personally. I'm just looking for someone who convinces me to Serverless and explains my the phenomenon of it.
Cheers.
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