Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

AWS Lambda and .zip is a recipe for serverless success

medium.com

Post reply on HN
Print view View original

31–40 of 117 posts

Re: AWS Lambda and .zip is a recipe for serverless success

#31

Post by paulgb »

staticassertion wrote: post #27
fapjacks wrote: post #9

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…

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 w…

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.

Re: AWS Lambda and .zip is a recipe for serverless success

#33

Post by bthornbury »

fapjacks wrote: post #9

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…

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.

Re: AWS Lambda and .zip is a recipe for serverless success

#34

Post by bthornbury »

TAForObvReasons wrote: post #18

Does anyone have experience with alternatives to AWS Lambda (like azure functions)? How hard is it to switch between serverless providers?

www.coherenceapi.com

Makes the OP's scenario much easier. Code upload and configuration all handled for you. You run code online the same way you call a local function.

Disclaimer: I am the founder/dev/designer of CoherenceApi.

Re: AWS Lambda and .zip is a recipe for serverless success

#35

Post by ryanmarsh »

fapjacks wrote: post #9

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…

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.

Re: AWS Lambda and .zip is a recipe for serverless success

#36

Post by nzoschke »

Deploying .zip files is one of my favorite features of Lambda, particularly when writing Go apps.

Docker always felt wrong with Go to me.

Why do I need a local VM, a Linux build service, an image registry and servers with container orchestration to deploy Go software? I understand how all this helps with "legacy" Rails or Java apps, but why can't I just throw a Go binary somewhere to run it?

Lambda is exactly this. I upload a cross-compiled .zip to S3 and everything else is taken care of. This was a big breakthrough for me, seeing a much simpler solution for deploys than all the container stuff.

I've been building a boilerplate app that demonstrates just how little "stuff" is needed to run a Go service on Lambda:

https://github.com/nzoschke/gofaas

More thoughts about how .zip files make our lives easier is here: https://github.com/nzoschke/gofaas/blob/master/docs/dev-pack...

Re: AWS Lambda and .zip is a recipe for serverless success

#37

Post by jlouis »

skybrian wrote: post #21
sheetjs wrote: post #16

Earlier quoted context omitted.

The table of contents in a zip file is at the end , not the beginning, so you need random access to the full file if you want to properly jump to the right location. Some zip files use the length feature of local file headers so you can jump ahead in the file without processing the data, but many skip the length so you have to work through the DEFLATE algorithm to find the end of the first file (to find where the sec…

Yes, you can and should use random file access to load things from a zip file. For example, Go's zip package takes an io.ReaderAt interface, not an io.Reader. Using sequential I/O for this would be inefficient.

The problem here is that you mostly have a streaming interface In s3.

Re: AWS Lambda and .zip is a recipe for serverless success

#38

Post by appdrag »

keithwhor wrote: post #23

Reading through this comment thread, if anybody is interested in a much more streamlined “serverless” experience and superior API Gateway, check out StdLib [1]. We’ve built a product for getting APIs built and shipped, full stop. Bonus: .tar.gz format for submitting packages instead of .zip (though our CLI handles it automatically), and a bunch of freebies - everything from automatically generated documentation [2],…

Check also a more visual approach to Cloud Backend including an sql cloud database and an API builder : https://cloudbackend.appdrag.com

Disclosure: I'm founder

Re: AWS Lambda and .zip is a recipe for serverless success

#39

Post by nzoschke »

dev1n wrote: post #17
fapjacks wrote: post #9

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…

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.

Check out the Serverless Application Model (SAM): 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

I'm hacking on CORS today and with SAM it's 2 lines of config to add the allowed origins and methods.

Re: AWS Lambda and .zip is a recipe for serverless success

#40

Post by staticassertion »

paulgb wrote: post #31
staticassertion wrote: post #27

Earlier quoted context omitted.

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 w…

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.

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.

Post reply on HN