5 ms·

I do wonder what the equivalent review of AWS Lambda would look like from an equivalent writer but one versed in GCP and K8S, encountering Lambda and IAM for th

I do wonder what the equivalent review of AWS Lambda would look like from an equivalent writer but one versed in GCP and K8S, encountering Lambda and IAM for the first time. I think one can easily make concerning arguments about all the things Lambda abstracts away and how concerning that is. HAVING SAID THAT, the substantial fundamental difference between something like Lambda and something like K8S is the value proposition. Lambda works backwards from your business logic. How to go from 0 to "working production code" with the minimal amount of steps, yet will still scale essentially infinitely (so long as you are willing to tolerate the latency costs) K8S seems to me like it instead works backwards from your infrastructure. How to go from one set of working infrastructure to another set of working infrastructure, but one optimized for solving problems that your organization doesn't have yet until you're at the point where you're looking to migrate your whole cloud strategy to another provider because Azure gave you a 2% higher discount than AWS did. Meanwhile, by the time you've built your first working K8S-based architecture, your competitor with Lambda is already in production serving customers. I know, I know, it's not Apples and oranges. But K8S and Lambda are of the same "generation", both launching in 2014. Lambda was AWS's big bet of "Here is the amazing value you can get if you go all-in on AWS-native development", K8S was GCP's equivalent "Here's how you can design your cloud infra to be portable if you explicitly DON'T want to go all-in one cloud provider." So while they offer almost diametrically opposite solutions (philosophically), they are pursuing the same developers to convince them of the mind share. Me, I'll take the one that actually cares about getting me to production with working business logic code.

joshuamorton 6y ago
This comment (and the original article) confuse me: GCP offers cloud functions as a lambda equivalent. K8s and lambda don't fill the same niche. The niche k8s fills doesn't have an AWS alternative, as far as I know. Now whether that niche is useful is a question that I don't have an answer for.
- cortesoft 6y ago
  I would imagine AWS Elastic Kubernetes Service is the aws alternative? https://aws.amazon.com/eks/ https://aws.amazon.com/eks/
  - jvolkman 6y ago
    That's not really a Kubernetes alternative since it is Kubernetes.
    - jen20 6y ago
      ECS would be the alternative in that case, no?
      - jpgvm 6y ago
        Exactly and ECS failed hard enough that they had to introduce EKS as consolation.
- fragmede 6y ago
  You're right, the niche that Lambda and K8s fill are quite different. However, what is the higher level problem that is being solved for? The smallest unit of execution for code is a (virtual) server, with a kernel, and filesystem, and just think of all the Nagios disk space emails to ignore. For application developers, the problem is that they don't want to manage an entire server, they just want their code to run when it's asked to, and not have to care about running out of inodes or some nonsense. From that single problem came a vast number of solutions, some competing, others not. As an application developer, I write my code, tack on manifest file appropriate to the platform (K8s pod, Lambda, Dockerfile, whatever.) and I've got a service. Without all the minutia of dealing with a server. There are tons of differences between Lambda and K8s; don't start. Look instead at how similar the architecture of the interface they provide to the application developer is. (No, not the literal DSL that is the interface, either.) (For K8s, keep in mind that there's a separate operations team managing the cluster and the hypothetical application developer is not on that team. That's one place where the niche each fills is clearly different.) Despite the rise of cloud providers, the hardware and space that on-prem exists in and on didn't magically disappear, and K8s moves the state of the art forwards for people that are on their own hardware, possibly with cloud augmentation. For those in that situation but looking for more modern ways to manage it, K8s fills a very useful niche. (It also fills other niches, but it's very useful there.)
  - joshuamorton 6y ago
    Right, this makes sense. To summarize, the kuburnetes niche is for people who can't use a public cloud provider, but whose employees want to have familiar interfaces (and to not have to deal with the ops). Or briefly, it's a tool for organizations to build their own internal lambda for things that can't be hosted externally. (and then, things like GKE and EKS are the cloud providers providing not just a familiar interface, but an effectively identical interface to the internal clouds, which makes moving workloads easier).
    - dividedbyzero 6y ago
      We use it to expose not just a common, but mostly a simpler interface to data/engineering people via EKS/GKE to do things they commonly need to with less of a learning curve, but we wouldn't run Kubernetes on bare metal, and we don't commonly move workloads between clouds (though we do run Kubernetes on both AWS and GCP). Turns out you need a lot of AWS/GCP knowledge even to run relatively simple apps, and even more for processing pipelines, and especially on AWS, every product has its own often steep learning curve, they don't necessarily share much. We find our k8s platforms offer a nice middle ground between siloing AWS/GCP knowledge and access away from engineers/data people and requiring everyone to fully understand the respective clouds, so they can have wide-ranging access and take care of things themselves. For example, it can be a huge pain to find out how to debug issues in native AWS/GCP products (Cloud Run, looking at you especially); with Kubernetes, common usage patterns share a lot more, e.g. debugging pretty much always involves pod logs, maybe exec'ing into a pod, reading and editing YAML in a familiar structure, be it a scheduled processing pipeline, app deployment, or whatever else, so we can train people how to do this once, and we find they're able to transfer that knowledge pretty well with a little pointing them to the right namespace/pod, and they can have all the access they need (depending on the cluster). Our own little tailored micro-clouds, if you will, but with a huge lot less effort than doing this from scratch, since a lot of the hard work involved is done by managed Kubernetes, and without much of the overhead of a cloud that has to work with 7823783 products involved. Similar things can be achieved by providing CDK templates, Terraform modules, well thought-out IAM policies, etc. etc., but this works well for us and appears to be a lot less hassle and complexity than those alternatives. It also helps security-wise that learning Kubernetes security once goes a very long way, and the concepts seem quite a bit more limited than for, say, running arbitrary things directly on AWS. Locking things up in separate clusters and namespaces can also add an additional layer to limit blast radii. Though we also use k8s because, especially on GCP, where we do the most data-intense work, strict GDPR compliance seems to be incredibly hard to achieve with much of their serverless offerings, it's incredibly easy to accidentally transfer data to the US without realizing, and there seems to be no mechanism to prevent that globally, though that better fits the category of things that cannot run on (serverless) Cloud. We still run many of these kind of workloads in the Cloud, but in GKE. Those that cannot run in cloud at all due to legal requirements don't run on Kubernetes, but directly on their own dedicated hardware on-prem. Inter-cloud portability is neat as well, but we wouldn't have picked k8s just for that.
skybrian 6y ago
It's odd to see this because Google App Engine is (was) not that hard and launched in 2008. I'm no longer doing that kind of work, but it seemed pretty good for people who want to keep it simple? I wonder Tim Bray would be better off kicking the tires on Firebase.
- deleted 6y ago
  [deleted]
- justicezyx 6y ago
  > Google App Engine is (was) not that hard It's incredible hard to use GAE in the same fashion as the LAMP or whatever web framework stack at its time. GAE is a primary example of overly confident technologists anticipating the next trend: They anticipate things happening too far in the future. Of course, GAE represent the eventual next step for application development. At the time, for anyone inside Google, that's obvious. And what happened was that neither Google itself, nor the industry embraced that model in the time frame that allows GAE to be relevant.
justicezyx 6y ago
The necessary first step for any in-depth technical discussion is to set the context. Per the topic in this article, the context probably could be set to 2 extreme opposite ends: hardware at the bottom, application at the top. Then we are clear that the focus is on how to reuse the pieces in the middle in order to optimize for a suite of objectives: * Application's software engineering quality * Application performance * Operational excellence * Hardware utilization When hardware is pinned to CPU based general computing, and application to a typical server side web/mobile one, the environment is set in a public cloud; then this background more or less matches all sorts of different hot trending tech technologies, for example, container, microservices, service mesh, server less, etc. In the end, generally speaking, one who produces the code for application developers, depending on how narrow they want to target, moves more distant from hardware. At the same time, the complexity spectrum between hardware and application is largely constant. That means if application moves into certain directions, hardware eventually coaches up. And shed aways a lot of its legacy. The computation towards AI & ML calls for GPU, precisely because CPU cannot maintain sufficient abstraction and performance due to its extended complexity gap with AI & ML computing. Back to CPU based application development. Then what you observed is precisely what's hapoening. I.e. serverless optimizes for application abstraction for developers directly. While container optimizes hardware neutrality, while it's audience is devops, I.e. the operators. The intention or results are not what you imagined though. Google does not particularly think the tech evolution should be from lower substrate. Rather, it's the only place they can differentiate from AWS. For AWS, the goal is to offer convenience to customers. Be it serverless, or any other tools or tech, it's largely determined by their assessment on how to capture the next high ground of tech competition. Obviously, it's always safer to start from more abstraction in application development. As it directly interact with the customer and provide the most direct feedbacks.
- aliswe 6y ago
  Why in the world is this downvoted? HN is so frustrating oftentimes.
  - justicezyx 6y ago
    I suggest HN to have a quick drop down list for down voting reasons, such that some form of thinking is applied while clicking the icon.
Bombthecat 6y ago
What about knative?
tlarkworthy 6y ago
Cloud Run is a more flexible lambda, but with a slightly worse cold starts, but much better concurrency story. See https://futurice.com/blog/openresty-a-swiss-army-proxy-for-serverless https://futurice.com/blog/openresty-a-swiss-army-proxy-for-s... where I shoved a scale to zero nginx proxy in a lambda-like container.
hitekker 6y ago
An insightful comment. k8s and Lambda aim to solve the problem of service management & deployment. k8s focuses on abstracting the server underneath and automating its operations, aka orchestration, "in-the-weeds & full control". Lambda instead focuses on outsourcing the server and its operations to AWS, aka serverless, "don't even think about it". Infrastructure engineers value the wide & deep featureset of k8s, and will accordingly invest significant manpower into its maintenance. Business developers value the simplicity of lambda and appreciate its low overhead and low price. The tension between these two solution & their audiences is resolved by the value-chains emanating from the top of their organizations. In a startup phase, leaders will likely value Lambda over k8s because managing services is not a core competency, i.e., they don't care enough. "Just get the application on prod and make sure it doesn't go down! How hard can that be?" As the organization develops over time, situations will arise that cannot be solved easily by Lambda or are too expensive to work on Lambda, which will necessitate expensive solutions like k8s. The leaders don't want to care about uptime, for example, so they'll hire people who do, people who have a different sense of value and cost. I think it's telling that the presenter of Lambda at AWS is not the CTO, but the CPO himself: https://aws.amazon.com/solutions/case-studies/netflix-and-aws-lambda/ https://aws.amazon.com/solutions/case-studies/netflix-and-aw... Four years later, an engineer gave a presentation about how Netflix built their own in-house FaaS, seemingly outgrowing Lambda: https://www.slideshare.net/yunongx/going-faaster-functions-as-a-service-at-netflix https://www.slideshare.net/yunongx/going-faaster-functions-a...

joshuamorton 6y ago

This comment (and the original article) confuse me: GCP offers cloud functions as a lambda equivalent. K8s and lambda don't fill the same niche. The niche k8s fills doesn't have an AWS alternative, as far as I know. Now whether that niche is useful is a question that I don't have an answer for.

cortesoft 6y ago
I would imagine AWS Elastic Kubernetes Service is the aws alternative? https://aws.amazon.com/eks/ https://aws.amazon.com/eks/
- jvolkman 6y ago
  That's not really a Kubernetes alternative since it is Kubernetes.
  - jen20 6y ago
    ECS would be the alternative in that case, no?
    - jpgvm 6y ago
      Exactly and ECS failed hard enough that they had to introduce EKS as consolation.
fragmede 6y ago
You're right, the niche that Lambda and K8s fill are quite different. However, what is the higher level problem that is being solved for? The smallest unit of execution for code is a (virtual) server, with a kernel, and filesystem, and just think of all the Nagios disk space emails to ignore. For application developers, the problem is that they don't want to manage an entire server, they just want their code to run when it's asked to, and not have to care about running out of inodes or some nonsense. From that single problem came a vast number of solutions, some competing, others not. As an application developer, I write my code, tack on manifest file appropriate to the platform (K8s pod, Lambda, Dockerfile, whatever.) and I've got a service. Without all the minutia of dealing with a server. There are tons of differences between Lambda and K8s; don't start. Look instead at how similar the architecture of the interface they provide to the application developer is. (No, not the literal DSL that is the interface, either.) (For K8s, keep in mind that there's a separate operations team managing the cluster and the hypothetical application developer is not on that team. That's one place where the niche each fills is clearly different.) Despite the rise of cloud providers, the hardware and space that on-prem exists in and on didn't magically disappear, and K8s moves the state of the art forwards for people that are on their own hardware, possibly with cloud augmentation. For those in that situation but looking for more modern ways to manage it, K8s fills a very useful niche. (It also fills other niches, but it's very useful there.)
- joshuamorton 6y ago
  Right, this makes sense. To summarize, the kuburnetes niche is for people who can't use a public cloud provider, but whose employees want to have familiar interfaces (and to not have to deal with the ops). Or briefly, it's a tool for organizations to build their own internal lambda for things that can't be hosted externally. (and then, things like GKE and EKS are the cloud providers providing not just a familiar interface, but an effectively identical interface to the internal clouds, which makes moving workloads easier).
  - dividedbyzero 6y ago
    We use it to expose not just a common, but mostly a simpler interface to data/engineering people via EKS/GKE to do things they commonly need to with less of a learning curve, but we wouldn't run Kubernetes on bare metal, and we don't commonly move workloads between clouds (though we do run Kubernetes on both AWS and GCP). Turns out you need a lot of AWS/GCP knowledge even to run relatively simple apps, and even more for processing pipelines, and especially on AWS, every product has its own often steep learning curve, they don't necessarily share much. We find our k8s platforms offer a nice middle ground between siloing AWS/GCP knowledge and access away from engineers/data people and requiring everyone to fully understand the respective clouds, so they can have wide-ranging access and take care of things themselves. For example, it can be a huge pain to find out how to debug issues in native AWS/GCP products (Cloud Run, looking at you especially); with Kubernetes, common usage patterns share a lot more, e.g. debugging pretty much always involves pod logs, maybe exec'ing into a pod, reading and editing YAML in a familiar structure, be it a scheduled processing pipeline, app deployment, or whatever else, so we can train people how to do this once, and we find they're able to transfer that knowledge pretty well with a little pointing them to the right namespace/pod, and they can have all the access they need (depending on the cluster). Our own little tailored micro-clouds, if you will, but with a huge lot less effort than doing this from scratch, since a lot of the hard work involved is done by managed Kubernetes, and without much of the overhead of a cloud that has to work with 7823783 products involved. Similar things can be achieved by providing CDK templates, Terraform modules, well thought-out IAM policies, etc. etc., but this works well for us and appears to be a lot less hassle and complexity than those alternatives. It also helps security-wise that learning Kubernetes security once goes a very long way, and the concepts seem quite a bit more limited than for, say, running arbitrary things directly on AWS. Locking things up in separate clusters and namespaces can also add an additional layer to limit blast radii. Though we also use k8s because, especially on GCP, where we do the most data-intense work, strict GDPR compliance seems to be incredibly hard to achieve with much of their serverless offerings, it's incredibly easy to accidentally transfer data to the US without realizing, and there seems to be no mechanism to prevent that globally, though that better fits the category of things that cannot run on (serverless) Cloud. We still run many of these kind of workloads in the Cloud, but in GKE. Those that cannot run in cloud at all due to legal requirements don't run on Kubernetes, but directly on their own dedicated hardware on-prem. Inter-cloud portability is neat as well, but we wouldn't have picked k8s just for that.

skybrian 6y ago

It's odd to see this because Google App Engine is (was) not that hard and launched in 2008. I'm no longer doing that kind of work, but it seemed pretty good for people who want to keep it simple? I wonder Tim Bray would be better off kicking the tires on Firebase.

deleted 6y ago
[deleted]
justicezyx 6y ago
> Google App Engine is (was) not that hard It's incredible hard to use GAE in the same fashion as the LAMP or whatever web framework stack at its time. GAE is a primary example of overly confident technologists anticipating the next trend: They anticipate things happening too far in the future. Of course, GAE represent the eventual next step for application development. At the time, for anyone inside Google, that's obvious. And what happened was that neither Google itself, nor the industry embraced that model in the time frame that allows GAE to be relevant.

justicezyx 6y ago

The necessary first step for any in-depth technical discussion is to set the context. Per the topic in this article, the context probably could be set to 2 extreme opposite ends: hardware at the bottom, application at the top. Then we are clear that the focus is on how to reuse the pieces in the middle in order to optimize for a suite of objectives: * Application's software engineering quality * Application performance * Operational excellence * Hardware utilization When hardware is pinned to CPU based general computing, and application to a typical server side web/mobile one, the environment is set in a public cloud; then this background more or less matches all sorts of different hot trending tech technologies, for example, container, microservices, service mesh, server less, etc. In the end, generally speaking, one who produces the code for application developers, depending on how narrow they want to target, moves more distant from hardware. At the same time, the complexity spectrum between hardware and application is largely constant. That means if application moves into certain directions, hardware eventually coaches up. And shed aways a lot of its legacy. The computation towards AI & ML calls for GPU, precisely because CPU cannot maintain sufficient abstraction and performance due to its extended complexity gap with AI & ML computing. Back to CPU based application development. Then what you observed is precisely what's hapoening. I.e. serverless optimizes for application abstraction for developers directly. While container optimizes hardware neutrality, while it's audience is devops, I.e. the operators. The intention or results are not what you imagined though. Google does not particularly think the tech evolution should be from lower substrate. Rather, it's the only place they can differentiate from AWS. For AWS, the goal is to offer convenience to customers. Be it serverless, or any other tools or tech, it's largely determined by their assessment on how to capture the next high ground of tech competition. Obviously, it's always safer to start from more abstraction in application development. As it directly interact with the customer and provide the most direct feedbacks.

aliswe 6y ago
Why in the world is this downvoted? HN is so frustrating oftentimes.
- justicezyx 6y ago
  I suggest HN to have a quick drop down list for down voting reasons, such that some form of thinking is applied while clicking the icon.

Bombthecat 6y ago

What about knative?

tlarkworthy 6y ago

Cloud Run is a more flexible lambda, but with a slightly worse cold starts, but much better concurrency story. See https://futurice.com/blog/openresty-a-swiss-army-proxy-for-serverless https://futurice.com/blog/openresty-a-swiss-army-proxy-for-s... where I shoved a scale to zero nginx proxy in a lambda-like container.

hitekker 6y ago

An insightful comment. k8s and Lambda aim to solve the problem of service management & deployment. k8s focuses on abstracting the server underneath and automating its operations, aka orchestration, "in-the-weeds & full control". Lambda instead focuses on outsourcing the server and its operations to AWS, aka serverless, "don't even think about it". Infrastructure engineers value the wide & deep featureset of k8s, and will accordingly invest significant manpower into its maintenance. Business developers value the simplicity of lambda and appreciate its low overhead and low price. The tension between these two solution & their audiences is resolved by the value-chains emanating from the top of their organizations. In a startup phase, leaders will likely value Lambda over k8s because managing services is not a core competency, i.e., they don't care enough. "Just get the application on prod and make sure it doesn't go down! How hard can that be?" As the organization develops over time, situations will arise that cannot be solved easily by Lambda or are too expensive to work on Lambda, which will necessitate expensive solutions like k8s. The leaders don't want to care about uptime, for example, so they'll hire people who do, people who have a different sense of value and cost. I think it's telling that the presenter of Lambda at AWS is not the CTO, but the CPO himself: https://aws.amazon.com/solutions/case-studies/netflix-and-aws-lambda/ https://aws.amazon.com/solutions/case-studies/netflix-and-aw... Four years later, an engineer gave a presentation about how Netflix built their own in-house FaaS, seemingly outgrowing Lambda: https://www.slideshare.net/yunongx/going-faaster-functions-as-a-service-at-netflix https://www.slideshare.net/yunongx/going-faaster-functions-a...