7 ms·

Cloud commoditized datacenters. People then tightly coupled their applications to cloud providers like AWS. After some time, containers came along and commoditi

Cloud commoditized datacenters. People then tightly coupled their applications to cloud providers like AWS. After some time, containers came along and commoditized the cloud providers. Those applications no longer needed to be tightly coupled to a specific cloud provider. This reduced both costs and the risk of being invested in a single cloud provider. Serverless (AWS Lambda) is just the cloud's way of trying to "de-commoditize" the containers that commoditized them. They want you to tightly couple your applications to their specific cloud provider again. And charge you more. How much is that function in the zip from S3 going to cost you to run in a container managed and run by AWS? And how long did you spend configuring the API Gateway (and where else can you apply what you've learned doing the configuration)? Next time you see an article fawning over serverless and saying things like "Containers just don’t matter in the serverless world" take a look at what the author does for a living. You'll start to see the same pattern I've been seeing. Meanwhile, you could be spending less money and time treating AWS like a dumb processor with a network connection while only really configuring the open source software you already know. But it's your time and money.

dev1n 9y ago
API Gateway is the literal manifestation of the worst product I have ever had the misfortune of configuring. This is mostly due to AWS's incompetence at delivering any semblance of working documentation around the product. Looking forward to their new "open source" documentation.
- Shoothe 9y ago
  I can second this. I wanted to write a simple provisioning tool a while ago that sets up HTTP endpoint on API Gateway and forwards the call to Lambda and the process was extremely complicated.
  - dev1n 9y ago
    People (as in I) would pay good money for this tool.
    - mullen 9y ago
      Just use Zappa.
- nzoschke 9y ago
  Check out the Serverless Application Model (SAM): https://github.com/awslabs/serverless-application-model https://github.com/awslabs/serverless-application-model All of the manual configuration of API gateway vanishes because it builds up an implicit API gateway from your functions and event mapping config. You can see a boilerplate SAM config here: https://github.com/nzoschke/gofaas/blob/master/template.yml https://github.com/nzoschke/gofaas/blob/master/template.yml I'm hacking on CORS today and with SAM it's 2 lines of config to add the allowed origins and methods.
  - dev1n 9y ago
    I have just finished up using SAM and it is miles better than trying to wire API Gateway and Lambda together. Setting up an authorizer with cognito took some time to find the right examples and get the swagger right but yes I am a fan of SAM. While we're on the subject, Cloudformation could definitely use some work too. AWS, please tell me what line the template failed at. We had to use the swagger extensions to integrate cognito and those were failing because of indentation errors, but it just kept complaining about invalid swagger 2.0 definitions. That is just so gross.
staticassertion 9y ago
I just don't get the "lambda locks you in" thing. You write a server the same way you always would, but like an extra 50LOC exists to make it work on lambda. So if I wanted to deploy elsewhere what would the big deal be? Lambda also provides a lot more than containerized services, as the article mentions - I no longer have to patch my system, which is a huge operational/ security burden that many companies struggle with. The time to configure API Gateway/ Lambda feels trivial compared to the work involved in maintaining a patched FAAS solution.
- paulgb 9y ago
  I agree, but in my experience, the lock-in with using Lambda is that you become integrated with other Amazon services (like S3 and DynamoDB) that are harder to replace if you abandon AWS entirely.
  - staticassertion 9y ago
    That really doesn't feel like it's inherent to Lambda at all. You could say the same thing about EC2. On top of that, many of AWS's services use standard API's. It's not hard to move away from RDS or Elasticache, you're just using SQL/Redis anyways... If we're talking about something like SQS, ok, well you can just as easily say you're "locked in" when you use RabbitMQ because there is work involved to not be using RabbitMQ.
    - zapita 9y ago
      > That really doesn't feel like it's inherent to Lambda at all. You could say the same thing about EC2. The major difference is that Lambda hooks into your developer tooling, and source code, in a way that EC2 doesn't. Sure, you can use Lambda without calling AWS APIs from your app... But you'll be using SDKs, tools and documentation that push you to do so, every day. It will require conscious thought and effort in your development to avoid lock-in, and over time the required effort will increase, because more and more third-party tools and libraries will switch to proprietary dependencies, dragging you along with them.
    - 9y ago
djhworld 9y ago
AWS Lambda itself isn't vendor lock in. If you write your Lambda function to put the interaction between the AWS Lambda service at the surface level of your application (i.e. the entry/exit point), and then write your business logic inbetween, you can create a function that is quite easily tranferrable between cloud providers. The vendor lock in creeps in more around the surrounding services that the cloud provider offers. You can protect yourself from this though by writing good quality hooks that have pluggable backends, e.g. writing/reading to an object store should be abstracted
- electricEmu 9y ago
  Why would I split, write, and deploy an vendor cloud function for every cloud provider when Docker moves between them? My team ditched serverless functions. We're better off without them.
  - thinkloop 9y ago
    Do you manually manage the infrastructure (keeping instances hot/cold, updates, scaling, etc.)? If so that's a lot to consider.
    - electricEmu 9y ago
      Containers are generally managed similar to serverless. AWS drains connections and workloads on container deployments. I set the same rules to scale either. Containers offer flexibility that serverless doesn't for implementing hot/cold, blue/green, n running with n+1, etc. So, additional flexibility with the same considerstions.
      - phamilton 9y ago
        Lambda support blue/green and all sorts of flexible stuff: aws lambda update-alias --function-name myfunction --name myalias --routing-config '{"AdditionalVersionWeights" : {"2" : 0.05} }'
  - mateuszf 9y ago
bthornbury 9y ago
Might as well throw away the automobiles and go back to horses, they're cheaper on gas. Forget that they take more time to care for, and to learn how to ride, and how to feed properly.
- reactivesearch 9y ago
  I think this is a bad analogy. Containers don't reduce convenience by a significant factor. On the other hand, what you are suggesting ...
  - bthornbury 9y ago
    It's straightforward logic. Serverless platforms increase convenience. Throwing them away decreases convenience and increases developer time to learn and launch. Many great inventions, like writing, automobiles, all increased convenience. Throwing away inventions that increase convenience, decreases convenience.
    - braderhart 9y ago
      Serverless in this context is merely a product by AWS. What great inventions do you think that Amazon created here, because serverless is just a word? Do you think that creating a buzzword like Amazon is the same as the science involved in creating an automobile?
    - Vindicis 9y ago
      So is this: Humans reproduce. Trees reproduce. Humans should reproduce with trees. Just because something is logical doesn't mean it makes sense.
      - deleted 9y ago
        [deleted]
ryanmarsh 9y ago
I don’t understand why people complain about Serverless vendor lock in. Let’s split lock-in into two categories: 1. Essential complexity DyanmoDB and Firebase are different products with different features and complexities. There is no “ANSI SQL” here. They are as different as they are similar. Moving from one to the other is a non-zero cost because they have different features your app would have to make up for or adopt. 2. Inessential complexity Serverless functions don’t necessarily need different signatures and it is conceivable that a standard for HTTP evented functions could emerge. Many are working on this. I expect this to be largely resolved over the next few years. Lastly, I’m grateful for ANSI SQL but over the last 20 years I think I’ve seen one or two clients migrate a mature Java app from one database vendor to another (excluding some very recent moves to AWS RDS). Keep in mind that JDBC is about as good an abstraction as we’ve ever had for database agnosticism. When you choose to build a lot of complexity upon an abstraction you have to be honest with yourself: have you ever dealt with a service (storage, queues, naming, auth, etc...) that didn’t have leaky abstractions? Of those with few/zero leaky abstractions how often did you need to migrate to a different vendor? Why do we expect a rapidly evolving set of systems and services to behave like mature commodity software? Fear of vendor lock-in is a premature optimization.
mankash666 9y ago
AWS and other managed FaaS offerings allow you to go from zero to endpoint in minutes. You can choose to deploy your own open source Faas framework (like openwhisk or open-faas) on one of these clouds, but YOU will have to: 1. Manage scaling of underling EC2s 2. Manage security patching of both the docker and underlying OS 3. Setup whole lot of configs 4 manage optimizations With a managed FaaS you're trading ops for more dev time, but someone has to be paid for the ops - it isn't free
ec109685 9y ago
Another issue with Lambda is that everything goes off the rails if you need to do something that Amazon hasn’t prioritized yet. Let’s say you want a GRPC endpoint, web sockets, http/2, mutual tls authentication, etc. Lambda won’t help you and you’ll be left building up your own patterns for those. Once you have those patterns, then Lambda’s use cases can be satisfied as well. Also, Lambda doesn’t provide any sla’s on container reuse. They could restart your container multiple times per second or every few minutes. You are at their mercy to keep your containers warm. Finally, with the meltdown example, would containers actually need to be patched if the parent OS gets patched since the kernels are shared between host and client containers? With Fargate, amazon would patch the base OS and your containers would be safe as they get rescheduled onto patched nodes.
manigandham 9y ago
Serverless is nothing more than PaaS - just at a more granular deployment/operation/billing/analytics scale. PaaS has always had a certain amount of lock-in because it's an abstraction, as any abstraction naturally does. There are also some abstractions like Kubernetes that are neutral yet also managed with extras by all the providers which is a nice middle ground. None of this is new or groundbreaking other than the silly hype words like "serverless".
- gardnr 9y ago
  I agree with you about the term "serverless" being silly, especially in a time when all the various forms of decentralized architecture are beginning to come of age. It makes it difficult to find information on "serverless webrtc signalling." While other auto-scaling PaaS exist, the granularity of the lambda pricing model is fairly new and groundbreaking. A service can be launched that may see very little use and just costs pennies to test out during its initial phases. That same service will scale exponentially rather easily in comparison to a similar deployment on a traditional server.
cdnsteve 9y ago
I suggest you take a look at https://www.openfaas.com/ https://www.openfaas.com/
WhitneyLand 9y ago
Then what is the point of the open source serverless frameworks our there? Or are you making that argument only within the context of aws lambda?
justicezyx 9y ago
It’s a cycle Depending on where you start your argument, one can be the commodity or meta commodity Your point is sort of moot Cloud for next 10 to 20 years, is still about killing old it vendors and make people not worried to put everything they own on cloud. Container or serve less is but major milestones.

dev1n 9y ago

API Gateway is the literal manifestation of the worst product I have ever had the misfortune of configuring. This is mostly due to AWS's incompetence at delivering any semblance of working documentation around the product. Looking forward to their new "open source" documentation.

Shoothe 9y ago
I can second this. I wanted to write a simple provisioning tool a while ago that sets up HTTP endpoint on API Gateway and forwards the call to Lambda and the process was extremely complicated.
- dev1n 9y ago
  People (as in I) would pay good money for this tool.
  - mullen 9y ago
    Just use Zappa.
nzoschke 9y ago
Check out the Serverless Application Model (SAM): https://github.com/awslabs/serverless-application-model https://github.com/awslabs/serverless-application-model All of the manual configuration of API gateway vanishes because it builds up an implicit API gateway from your functions and event mapping config. You can see a boilerplate SAM config here: https://github.com/nzoschke/gofaas/blob/master/template.yml https://github.com/nzoschke/gofaas/blob/master/template.yml I'm hacking on CORS today and with SAM it's 2 lines of config to add the allowed origins and methods.
- dev1n 9y ago
  I have just finished up using SAM and it is miles better than trying to wire API Gateway and Lambda together. Setting up an authorizer with cognito took some time to find the right examples and get the swagger right but yes I am a fan of SAM. While we're on the subject, Cloudformation could definitely use some work too. AWS, please tell me what line the template failed at. We had to use the swagger extensions to integrate cognito and those were failing because of indentation errors, but it just kept complaining about invalid swagger 2.0 definitions. That is just so gross.

staticassertion 9y ago

I just don't get the "lambda locks you in" thing. You write a server the same way you always would, but like an extra 50LOC exists to make it work on lambda. So if I wanted to deploy elsewhere what would the big deal be? Lambda also provides a lot more than containerized services, as the article mentions - I no longer have to patch my system, which is a huge operational/ security burden that many companies struggle with. The time to configure API Gateway/ Lambda feels trivial compared to the work involved in maintaining a patched FAAS solution.

paulgb 9y ago
I agree, but in my experience, the lock-in with using Lambda is that you become integrated with other Amazon services (like S3 and DynamoDB) that are harder to replace if you abandon AWS entirely.
- staticassertion 9y ago
  That really doesn't feel like it's inherent to Lambda at all. You could say the same thing about EC2. On top of that, many of AWS's services use standard API's. It's not hard to move away from RDS or Elasticache, you're just using SQL/Redis anyways... If we're talking about something like SQS, ok, well you can just as easily say you're "locked in" when you use RabbitMQ because there is work involved to not be using RabbitMQ.
  - zapita 9y ago
    > That really doesn't feel like it's inherent to Lambda at all. You could say the same thing about EC2. The major difference is that Lambda hooks into your developer tooling, and source code, in a way that EC2 doesn't. Sure, you can use Lambda without calling AWS APIs from your app... But you'll be using SDKs, tools and documentation that push you to do so, every day. It will require conscious thought and effort in your development to avoid lock-in, and over time the required effort will increase, because more and more third-party tools and libraries will switch to proprietary dependencies, dragging you along with them.
  - 9y ago

djhworld 9y ago

AWS Lambda itself isn't vendor lock in. If you write your Lambda function to put the interaction between the AWS Lambda service at the surface level of your application (i.e. the entry/exit point), and then write your business logic inbetween, you can create a function that is quite easily tranferrable between cloud providers. The vendor lock in creeps in more around the surrounding services that the cloud provider offers. You can protect yourself from this though by writing good quality hooks that have pluggable backends, e.g. writing/reading to an object store should be abstracted

electricEmu 9y ago
Why would I split, write, and deploy an vendor cloud function for every cloud provider when Docker moves between them? My team ditched serverless functions. We're better off without them.
- thinkloop 9y ago
  Do you manually manage the infrastructure (keeping instances hot/cold, updates, scaling, etc.)? If so that's a lot to consider.
  - electricEmu 9y ago
    Containers are generally managed similar to serverless. AWS drains connections and workloads on container deployments. I set the same rules to scale either. Containers offer flexibility that serverless doesn't for implementing hot/cold, blue/green, n running with n+1, etc. So, additional flexibility with the same considerstions.
    - phamilton 9y ago
      Lambda support blue/green and all sorts of flexible stuff: aws lambda update-alias --function-name myfunction --name myalias --routing-config '{"AdditionalVersionWeights" : {"2" : 0.05} }'
- mateuszf 9y ago

bthornbury 9y ago

Might as well throw away the automobiles and go back to horses, they're cheaper on gas. Forget that they take more time to care for, and to learn how to ride, and how to feed properly.

reactivesearch 9y ago
I think this is a bad analogy. Containers don't reduce convenience by a significant factor. On the other hand, what you are suggesting ...
- bthornbury 9y ago
  It's straightforward logic. Serverless platforms increase convenience. Throwing them away decreases convenience and increases developer time to learn and launch. Many great inventions, like writing, automobiles, all increased convenience. Throwing away inventions that increase convenience, decreases convenience.
  - braderhart 9y ago
    Serverless in this context is merely a product by AWS. What great inventions do you think that Amazon created here, because serverless is just a word? Do you think that creating a buzzword like Amazon is the same as the science involved in creating an automobile?
  - Vindicis 9y ago
    So is this: Humans reproduce. Trees reproduce. Humans should reproduce with trees. Just because something is logical doesn't mean it makes sense.
    - deleted 9y ago
      [deleted]

ryanmarsh 9y ago

I don’t understand why people complain about Serverless vendor lock in. Let’s split lock-in into two categories: 1. Essential complexity DyanmoDB and Firebase are different products with different features and complexities. There is no “ANSI SQL” here. They are as different as they are similar. Moving from one to the other is a non-zero cost because they have different features your app would have to make up for or adopt. 2. Inessential complexity Serverless functions don’t necessarily need different signatures and it is conceivable that a standard for HTTP evented functions could emerge. Many are working on this. I expect this to be largely resolved over the next few years. Lastly, I’m grateful for ANSI SQL but over the last 20 years I think I’ve seen one or two clients migrate a mature Java app from one database vendor to another (excluding some very recent moves to AWS RDS). Keep in mind that JDBC is about as good an abstraction as we’ve ever had for database agnosticism. When you choose to build a lot of complexity upon an abstraction you have to be honest with yourself: have you ever dealt with a service (storage, queues, naming, auth, etc...) that didn’t have leaky abstractions? Of those with few/zero leaky abstractions how often did you need to migrate to a different vendor? Why do we expect a rapidly evolving set of systems and services to behave like mature commodity software? Fear of vendor lock-in is a premature optimization.

mankash666 9y ago

AWS and other managed FaaS offerings allow you to go from zero to endpoint in minutes. You can choose to deploy your own open source Faas framework (like openwhisk or open-faas) on one of these clouds, but YOU will have to: 1. Manage scaling of underling EC2s 2. Manage security patching of both the docker and underlying OS 3. Setup whole lot of configs 4 manage optimizations With a managed FaaS you're trading ops for more dev time, but someone has to be paid for the ops - it isn't free

ec109685 9y ago

Another issue with Lambda is that everything goes off the rails if you need to do something that Amazon hasn’t prioritized yet. Let’s say you want a GRPC endpoint, web sockets, http/2, mutual tls authentication, etc. Lambda won’t help you and you’ll be left building up your own patterns for those. Once you have those patterns, then Lambda’s use cases can be satisfied as well. Also, Lambda doesn’t provide any sla’s on container reuse. They could restart your container multiple times per second or every few minutes. You are at their mercy to keep your containers warm. Finally, with the meltdown example, would containers actually need to be patched if the parent OS gets patched since the kernels are shared between host and client containers? With Fargate, amazon would patch the base OS and your containers would be safe as they get rescheduled onto patched nodes.

manigandham 9y ago

Serverless is nothing more than PaaS - just at a more granular deployment/operation/billing/analytics scale. PaaS has always had a certain amount of lock-in because it's an abstraction, as any abstraction naturally does. There are also some abstractions like Kubernetes that are neutral yet also managed with extras by all the providers which is a nice middle ground. None of this is new or groundbreaking other than the silly hype words like "serverless".

gardnr 9y ago
I agree with you about the term "serverless" being silly, especially in a time when all the various forms of decentralized architecture are beginning to come of age. It makes it difficult to find information on "serverless webrtc signalling." While other auto-scaling PaaS exist, the granularity of the lambda pricing model is fairly new and groundbreaking. A service can be launched that may see very little use and just costs pennies to test out during its initial phases. That same service will scale exponentially rather easily in comparison to a similar deployment on a traditional server.

cdnsteve 9y ago

I suggest you take a look at https://www.openfaas.com/ https://www.openfaas.com/

WhitneyLand 9y ago

Then what is the point of the open source serverless frameworks our there? Or are you making that argument only within the context of aws lambda?

justicezyx 9y ago

It’s a cycle Depending on where you start your argument, one can be the commodity or meta commodity Your point is sort of moot Cloud for next 10 to 20 years, is still about killing old it vendors and make people not worried to put everything they own on cloud. Container or serve less is but major milestones.