11 ms·

Kind of surprised the article didn't mention lack of reasonable development environment. At least on AWS, the "SAM" experience has been probably the worst deve

by nickjj 6y ago

Kind of surprised the article didn't mention lack of reasonable development environment. At least on AWS, the "SAM" experience has been probably the worst development experience I've ever had in ~20 years of web development. It's so slow (iteration speed) and you need to jump through a billion hoops of complexity all over the place. Even dealing with something as simple as loading environment variables for both local and "real" function invokes required way too much effort. Note: I'm not working with this tech by choice. It's for a bit of client work. I think their use case for Serverless makes sense (calling something very infrequently that glues together a few AWS resources). Is the experience better on other platforms?

Latty 6y ago
Yeah, I took a look at using a serverless framework for a hobby project, and it was just a real pain to get started at all, let alone develop a whole application in. I tried AWS, and then IBM's offering which is based on an open source (Apache OpenWhisk) project, thinking that it might be easier to work with, but that was also a pain. I just lost interest as I was only checking it out. For something constantly marketed on the ease of not having to manage servers, it fell a long way short of "easy".
- com2kid 6y ago
  > Yeah, I took a look at using a serverless framework for a hobby project, and it was just a real pain to get started at all, let alone develop a whole application in. Look into Firebase functions. Drop some JS in a folder, export them from an index.js file and you have yourself some endpoints. > exports.helloWorld = functions.https.onRequest((request, response) => { response.send("Hello from Firebase!"); }); The amount of work AWS has put in front of Lambdas confuses me. Firebase does it right. You can go from "never having written a REST endpoint" to "real code" in less than 20 minutes. New endpoints can be created as fast as you can export functions from an index.js file.
  - iudqnolq 6y ago
    And if you need a dependency that has a sub dependency with a subdependency that uses a native module prepare for poorly defined -fun- hell getting it to work. A surprising amount of standard is libs do.
    - iudqnolq 6y ago
      *standard js libs (as in commonly used)
      - com2kid 6y ago
        Eh, you win some you lose some. Being able to throw up a new REST endpoint in under 10 minutes with 0 config is really cool though. And Firebase Functions are priced to work as daily drivers, they can front an entire application and not cost an insane amount of $, per single ms pricing. Lambda's are a lot more complicated.
hermanradtke 6y ago
GCP has https://cloud.google.com/functions/docs/functions-framework https://cloud.google.com/functions/docs/functions-framework but I will not use it. I have found the best solution is to abstract away the serverless interface and create a test harness that can test the business logic. This adds some extra complexity in the code, but iterations are fast and do not rely on the overly complex and bug prone "platforms" like SAM and Functions Framework.
- uglygoblin 6y ago
  This is precisely what I do when I write code destined to be an AWS Lambda Function. It really feels like the only sane way to do it. It also makes it easy to mock the incoming request/event for integration tests.
- jdsalaro 6y ago
  Can you elaborate on your approach to "abstract away the serverless interface and create a test harness that can test the business logic"?
spcebar 6y ago
I found firebase functions pretty easy and painless. Worth a look.
- john-tells-all 6y ago
  Keep in mind Firebase has a big caveat. Firebase is great... for what it does. However, there's no way to easily migrate the Firebase resources to the larger GCP ecosystem. Firebase does what it does, and if you need anything else, you're out of luck. Firebase is magic... but I never recommend it for anyone, until there's some sort of migration path.
  - disqard 6y ago
    I'll second this. I'm currently migrating away from Firebase to MySQL, and I'm glad I didn't wait any longer.
  - ugh123 6y ago
    Are you referring to performance capabilities or some other connectedness to GCP resources?
  - habosa 6y ago
    [Firebaser here] that’s not quite accurate. For cloud functions they’re literally the same. Your Firebase function is actually a GCP function that you can manage behind the scenes. With Cloud Firestore (our serverless DB) that’s the case as well. And Firebase Auth can be seamlessly upgraded to Google Cloud Identity Platform with a click. However you’re right that for many Firebase products (Real-time Database, Hosting) there’s no relation to Cloud Resources.
- pier25 6y ago
  Deploying is super slow. Usually it takes a minute or two, which is already quite long, but sometimes something goes wrong and then you can't redeploy immediately. You have to wait a couple of minutes before being able to redeploy. To be fair, Firebase recently released a local development tool which alleviates the need to deploy on every change, but I haven't used it yet. https://firebase.google.com/docs/emulator-suite https://firebase.google.com/docs/emulator-suite
ryancoleman 6y ago
Developer experience for serverless is such a pain point, spot on. AWS SAM has tackled some of the IaC modeling problem (on top of CloudFormation which is a mature choice) and they've had a crack at the local iteration (invoke Lambda function or API Gateway locally with connectivity to cloud services). It's a little incomplete, missing some of the AWS IAM automation that makes local development smooth, environment management for testing and promoting changes, and some sort of visualization to make architecture easier to design as a team. I work for a platform company called Stackery which aims to provide an end-to-end workflow and DX for serverless & CloudFormation. Thanks for comments like these that help identify pain points that need attention.
- tupputuppu 6y ago
  Stackery is great. Doing serverless without an extensive toolset is impossible, which is sad.
  - rolldeez 6y ago
    Thanks! We like you too. <3 Stackery.
whalesalad 6y ago
I felt your pain immediately and decided to write my own mini-framework to accomplish this. What I have now is a loosely coupled, serverless, frontend+backend monorepo that wraps AWS SAM and CloudFormation. At the end of the day it is just a handful of scripts and some foundational conventions. I just (this morning!) started to put together notes and docs for myself on how I can generalize and open source this to make it available for others. stack is vue/python/s3/lambda/dynamodb/stripe but the tooling I developed is generic enough to directly support any lambda runtime for any sub-namespace of your project so it would also support a react/rails application just as well.
- dahfizz 6y ago
  As a systems developer, comments like yours make me amazed at the state of web development. From the outside looking in, it seems like 10% code and 90% monkeying around with tooling and frameworks and stacks.
  - deleted 6y ago
    [deleted]
  - whalesalad 6y ago
    It’s still a very young ecosystem. Serverless hasn’t had its Rails moment (yet). I don’t think it’s as bad as people make it out to be.
    - x86_64Ubuntu 6y ago
      What's the Rails moment? It's already hit the part where people speak about it as if it will save the world.
      - Toutouxc 6y ago
        I believe it's the moment when there's a solution that just makes sense and works well for most people. A gold standard that other solutions will try to develop more and spice up, instead of reinventing it.
2ion 6y ago
Wait until you get to work with the CDK, it's worse.
- technics256 6y ago
  Can you elaborate why?
- inoop 6y ago
  This is surprising to me, I work with the CDK daily and I really enjoy it. Can you explain what issues you're hitting?
- EdwardDiego 6y ago
  I've been using it for a recent project, and quite enjoy it.
pier25 6y ago
> Kind of surprised the article didn't mention lack of reasonable development environment. I've been pretty happy with Cloudflare Workers. You can easily define environments with variables via a toml file. The DX is great and iteration speed is very fast. When using `wrangler dev` your new version is ready in a second or two after saving.
rangoon626 6y ago
SAM feels wrong to me, it’s way too much friction. I was planning on trying out FastAPI + Zappa, but have not gotten round to it yet.
jpdb 6y ago
I used to be complain about the same thing and even asked someone who was head of BD for Serverless at AWS what they recommended, and didn't get an answer to my satisfaction. After working with more and more serverless applications (despite the development pains, the business value was still justified) I realized that local development was difficult because I was coupling my code to the delivery. This is similar to the way you shouldn't couple your code to your database implementation. Instead, you can write a function that takes parameters from elsewhere and call your business logic there. It definitely adds a bit more work, but it alleviates quite a bit of pain that comes with Lambda local development. Disclaimer: I work at AWS, however not for any service or marketing team. Opinions are my own.
- jacques_chester 6y ago
  > I realized that local development was difficult because I was coupling my code to the delivery. Of interest, I've spent some free time crunching on CNCF survey data over the past few months. Some of the strongest correlations are between particular serverless offerings and particular delivery offerings. If you use Azure Functions then I know you are more likely to use Azure Devops than anything else. Same for Lambda + CodePipeline and Google Cloud Functions + Cloud Build.
  - oblio 6y ago
    I think his point was that you should be able to run and test the Lambda code independently of Lambda. After all the entry point is just a method with some parameters, you can replicate that locally.
    - jacques_chester 6y ago
      ... ah.
    - losteric 6y ago
      Yes, this is a great way of doing things - I have no problems TDD'ing business logic hosted in Lambda, because the business logic is fully decoupled from the execution environment. SAM should be for high-fidelity E2E integration testing.
inoop 6y ago
Take a look at the [CDK](https://aws.amazon.com/cdk/ https://aws.amazon.com/cdk/) if you haven't already. It lets you define your infrastructure using TypeScript, which then compiles to CloudFormation. You can easily mix infrastructure and Lambda code in the same project if all you're doing is writing some NodeJS glue Lambdas which sounds like what you're looking for. There's a couple of sharp edges still but in general it just 'makes sense'. If you don't like TypeScript there are also bindings for Python and Java, among others, although TypeScript is really the preferred language.
- autotune 6y ago
  This doesn't solve the general lack of observability, lack of logging, and slowness of CloudFormation itself.
  - mylons 6y ago
    AWS Lambda logs to Cloudwatch, and has monitoring out of the box.
    - deleted 6y ago
      [deleted]
    - autotune 6y ago
      Very poor logging and monitoring, in my experience.
      - mylons 6y ago
        Poor how? Do you not like the UI? The UI is not the best, but there’s no issue in reliability.
- nullsense 6y ago
  CDK made IaC accessible to me. I hated raw CloudFormation and never bothered with it because of that reason. I had a crack at Terraform, but never got passed the learning curve before my enthusiasm died. Currently using some CDK in a production app and finally I found a way of doing IaC I actually enjoy.
k__ 6y ago
SAM is okay-ish. Felt still better than K8s to me. Have you tried Amplify?
- eghri 6y ago
  I found Amplify excellent to get up and running quickly. I’d highly recommend it for anyone without a well-oiled CICD setup who wants to quickly get a website up to test out an idea. Unfortunately, I quickly hit the limits of its configurability (particularly with Cloudfront) and had to move off it within a few months.
  - chrisco255 6y ago
    You could just use Amplify for the backend and pair it with any other front end host / CDN provider. I've used it with Vercel and it works great.
  - k__ 6y ago
    Care to elaborate on the limits you hit?
revicon 6y ago
we use the serverless framework and use > serverless invoke local All the time for doing testing. You can pass in a json file that contains a simulated event to test different scenarios. Works very well for us.
- FrenchTouch42 6y ago
  Unfortunately, it has a lot of issues with how credentials are handled. I believe they decided to re-create their own credentials chain and a lot of things are not working with MFA (like support for credential_process).
cmckn 6y ago
Couldn’t agree more, the dev experience was awful. You basically have to develop against public AWS services, my dev machine became a glorified terminal. They do seem to be iterating on the tooling quickly, but I wouldn’t use it again if I had a choice. Edit: CloudFormation was also painful for me, the docs were sparse and there were very few examples that helped me out.
- rajamaka 6y ago
  > the docs were sparse Over 5000 pages of documentation https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-ug.pdf https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGui... > very few examples that helped me out AWS provide an example for most common services, plus there are thousands of other community supplied examples out there. https://github.com/awslabs/aws-cloudformation-templates https://github.com/awslabs/aws-cloudformation-templates
  - cmckn 6y ago
    SAM templates are a subset of CloudFormation templates; that PDF could be three times as long and still not have the content I needed. Yes there are examples, but there wasn’t one at the time that mapped to what I was trying to accomplish. Because, again, SAM templates are not one-for-one CloudFormation templates. I found the community around SAM to be very limited. One of the many reasons I’ve moved to the Kubernetes ecosystem.
wiremine 6y ago
> It's so slow (iteration speed) and you need to jump through a billion hoops of complexity all over the place. Even dealing with something as simple as loading environment variables for both local and "real" function invokes required way too much effort. Honestly, it reminds me of PHP development years ago: running it locally sucked, so you need to upload it to the server and test your work. It. Sucked.
- kortilla 6y ago
  It was actually pretty good if you had an IDE with sftp/scp support because you could save a file, refresh your browser, and have immediate new results.
  - nickjj 6y ago
    Yeah this wasn't too bad and it was what I used to do back in the day with Notepad++. By the time you hit save in your editor, your changes were ready to be reloaded in the browser. With SAM we're talking ~6-7 seconds with an SSD to build + LOCALLY invoke a new copy of a fairly simple function where you're changing 1 line of code, and you need to do this every time you change your code. That's even with creating a custom Makefile command to roll up the build + invoke into 1 human action. The wait time is purely waiting for SAM to do what it needs to do. With a more traditional non-Serverless set up, with or without Docker (using volumes) the turn around time is effectively instant. You can make your code change and by the time you reload your browser it's all good to go. This is speaking from a Python, Ruby, Elixir and Node POV.
    - iCarrot 6y ago
      The workaround my team uses is to make two entries to start the webapp: one for SAM, one for local. For fast iteration we just `npm start`, and when we're ready to do more elaborated testing we run with SAM. This works pretty well so far.
- nicky0 6y ago
  Out of genuine interest... is there a modern solution to this problem with PHP/MySQL? (I'm still doing the "upload to server to test" thing.... I've tried MAMP and Vagrant/VirtualBox for local dev but both of them seem horribly complex compared to what we can do with local dev with node.js/mongo and so on.)
GFischer 6y ago
I can report that Azure Function App development is at least pretty decent, as long as you have the paid Visual Studio IDE and Azure Function Tools (haven't tried the free version yet). I tried AWS Lambdas a few years back and it felt way more primitive.
- skvark 6y ago
  Azure Function App development experience is indeed pretty nice at least when using .NET Core. There are some issues, like loading secrets to the local dev environment from Key Vault has to be done manually and easy auth (App Service Authentication) does not work locally.
- GordonS 6y ago
  I use JetBrains Rider, rather than Visual Studio, and the dev experience is excellent, just the same as with VS.
raverbashing 6y ago
AWS tooling is one pain point Yes, SAM sucks. Boto3 sucks. I mean, yes, the AWS APIs are not the most obvious or ergonomics thing.
erikerikson 6y ago
See the serverless framework [0]. AWS built SAM because they wanted an in house option. [0] https://www.serverless.com/ https://www.serverless.com/
hendry 6y ago
https://github.com/apex/up https://github.com/apex/up is a godsend for deploying on AWS Lambda for me. By the same author as Express JS, TJ Holowaychuk. TJ abstracts the Lambda nonsense so you just get to use a standard HTTP res/resp interface. https://github.com/apex/up-examples/ https://github.com/apex/up-examples/ Deployment iterations for me in Singapore can be as low as 2s, but tbh I use https://github.com/codegangsta/gin https://github.com/codegangsta/gin locally for development iterations.
nuker 6y ago
> Kind of surprised the article didn't mention .. What does it mention?
habosa 6y ago
It definitely doesn’t have to be that way. I work on Firebase and I’ve spent most of the last year specifically working on our local development experience for our serverless backend products: https://firebase.google.com/docs/emulator-suite https://firebase.google.com/docs/emulator-suite Still very actively working on this but our goal is that nobody ever has to test via deploy again.
- randomsearch 6y ago
  Love firebase, thanks for your work! the local emulator suite is so important a feature and keenly following your progress. Slightly OT... perhaps cheeky... any idea why firebase doesn’t provide automated backups for firestore and storage out of the box? Seems like a no brainer and a valuable service people would pay for.
  - habosa 6y ago
    We're working on Firestore backups. Haven't heard many people ask for Storage backups though ... so I don't think that's on the roadmap at the moment.
- robertlagrant 6y ago
  I'm currently working on a little project backed by Firebase. Really interesting. Good to hear you're doing this - at my day job one of our key factors in choosing a technology is whether we can spin it up in docker-compose in CI and do real-as-possible ephemeral integration tests.
philliphaydon 6y ago
My experience is with .NET Core and the development experience is awesome... Dropped a $250/m cost down to ~$9/m moving it from ec2 to lambda's. Environment variables are loaded no differently between development and prod. Nothing is all over the place as it's almost 0 difference between building a service to run in Linux/Windows vs a Lambda.
sajithdilshan 6y ago
Just throwing this out here https://www.slappforge.com/sigma https://www.slappforge.com/sigma Last time I checked, it even provides in-built code debugging as well. DISCLAIMER: I used to be a developer of this product (it's from the previous company I've worked)
GordonS 6y ago
I've used Azure's serverless offering "Functions" quite a bit. The dev experience is pretty good, actually - it "just works" - start it and point your browser at the URL. And certainly no problems setting up env vars or anything basic like that. My only nitpick, and only specifically relating to dotnet, is that config files and env vars differ between Functions and regular ASP.NET Core web apps. I think there is some work going on to fix that, but it's taking forever.

by nickjj 6y ago

Latty 6y ago

Yeah, I took a look at using a serverless framework for a hobby project, and it was just a real pain to get started at all, let alone develop a whole application in. I tried AWS, and then IBM's offering which is based on an open source (Apache OpenWhisk) project, thinking that it might be easier to work with, but that was also a pain. I just lost interest as I was only checking it out. For something constantly marketed on the ease of not having to manage servers, it fell a long way short of "easy".

com2kid 6y ago
> Yeah, I took a look at using a serverless framework for a hobby project, and it was just a real pain to get started at all, let alone develop a whole application in. Look into Firebase functions. Drop some JS in a folder, export them from an index.js file and you have yourself some endpoints. > exports.helloWorld = functions.https.onRequest((request, response) => { response.send("Hello from Firebase!"); }); The amount of work AWS has put in front of Lambdas confuses me. Firebase does it right. You can go from "never having written a REST endpoint" to "real code" in less than 20 minutes. New endpoints can be created as fast as you can export functions from an index.js file.
- iudqnolq 6y ago
  And if you need a dependency that has a sub dependency with a subdependency that uses a native module prepare for poorly defined -fun- hell getting it to work. A surprising amount of standard is libs do.
  - iudqnolq 6y ago
    *standard js libs (as in commonly used)
    - com2kid 6y ago
      Eh, you win some you lose some. Being able to throw up a new REST endpoint in under 10 minutes with 0 config is really cool though. And Firebase Functions are priced to work as daily drivers, they can front an entire application and not cost an insane amount of $, per single ms pricing. Lambda's are a lot more complicated.

hermanradtke 6y ago

GCP has https://cloud.google.com/functions/docs/functions-framework https://cloud.google.com/functions/docs/functions-framework but I will not use it. I have found the best solution is to abstract away the serverless interface and create a test harness that can test the business logic. This adds some extra complexity in the code, but iterations are fast and do not rely on the overly complex and bug prone "platforms" like SAM and Functions Framework.

uglygoblin 6y ago
This is precisely what I do when I write code destined to be an AWS Lambda Function. It really feels like the only sane way to do it. It also makes it easy to mock the incoming request/event for integration tests.
jdsalaro 6y ago
Can you elaborate on your approach to "abstract away the serverless interface and create a test harness that can test the business logic"?

spcebar 6y ago

I found firebase functions pretty easy and painless. Worth a look.

john-tells-all 6y ago
Keep in mind Firebase has a big caveat. Firebase is great... for what it does. However, there's no way to easily migrate the Firebase resources to the larger GCP ecosystem. Firebase does what it does, and if you need anything else, you're out of luck. Firebase is magic... but I never recommend it for anyone, until there's some sort of migration path.
- disqard 6y ago
  I'll second this. I'm currently migrating away from Firebase to MySQL, and I'm glad I didn't wait any longer.
- ugh123 6y ago
  Are you referring to performance capabilities or some other connectedness to GCP resources?
- habosa 6y ago
  [Firebaser here] that’s not quite accurate. For cloud functions they’re literally the same. Your Firebase function is actually a GCP function that you can manage behind the scenes. With Cloud Firestore (our serverless DB) that’s the case as well. And Firebase Auth can be seamlessly upgraded to Google Cloud Identity Platform with a click. However you’re right that for many Firebase products (Real-time Database, Hosting) there’s no relation to Cloud Resources.
pier25 6y ago
Deploying is super slow. Usually it takes a minute or two, which is already quite long, but sometimes something goes wrong and then you can't redeploy immediately. You have to wait a couple of minutes before being able to redeploy. To be fair, Firebase recently released a local development tool which alleviates the need to deploy on every change, but I haven't used it yet. https://firebase.google.com/docs/emulator-suite https://firebase.google.com/docs/emulator-suite

ryancoleman 6y ago

Developer experience for serverless is such a pain point, spot on. AWS SAM has tackled some of the IaC modeling problem (on top of CloudFormation which is a mature choice) and they've had a crack at the local iteration (invoke Lambda function or API Gateway locally with connectivity to cloud services). It's a little incomplete, missing some of the AWS IAM automation that makes local development smooth, environment management for testing and promoting changes, and some sort of visualization to make architecture easier to design as a team. I work for a platform company called Stackery which aims to provide an end-to-end workflow and DX for serverless & CloudFormation. Thanks for comments like these that help identify pain points that need attention.

tupputuppu 6y ago
Stackery is great. Doing serverless without an extensive toolset is impossible, which is sad.
- rolldeez 6y ago
  Thanks! We like you too. <3 Stackery.

whalesalad 6y ago

I felt your pain immediately and decided to write my own mini-framework to accomplish this. What I have now is a loosely coupled, serverless, frontend+backend monorepo that wraps AWS SAM and CloudFormation. At the end of the day it is just a handful of scripts and some foundational conventions. I just (this morning!) started to put together notes and docs for myself on how I can generalize and open source this to make it available for others. stack is vue/python/s3/lambda/dynamodb/stripe but the tooling I developed is generic enough to directly support any lambda runtime for any sub-namespace of your project so it would also support a react/rails application just as well.

dahfizz 6y ago
As a systems developer, comments like yours make me amazed at the state of web development. From the outside looking in, it seems like 10% code and 90% monkeying around with tooling and frameworks and stacks.
- deleted 6y ago
  [deleted]
- whalesalad 6y ago
  It’s still a very young ecosystem. Serverless hasn’t had its Rails moment (yet). I don’t think it’s as bad as people make it out to be.
  - x86_64Ubuntu 6y ago
    What's the Rails moment? It's already hit the part where people speak about it as if it will save the world.
    - Toutouxc 6y ago
      I believe it's the moment when there's a solution that just makes sense and works well for most people. A gold standard that other solutions will try to develop more and spice up, instead of reinventing it.

2ion 6y ago

Wait until you get to work with the CDK, it's worse.

technics256 6y ago
Can you elaborate why?
inoop 6y ago
This is surprising to me, I work with the CDK daily and I really enjoy it. Can you explain what issues you're hitting?
EdwardDiego 6y ago
I've been using it for a recent project, and quite enjoy it.

pier25 6y ago

> Kind of surprised the article didn't mention lack of reasonable development environment. I've been pretty happy with Cloudflare Workers. You can easily define environments with variables via a toml file. The DX is great and iteration speed is very fast. When using `wrangler dev` your new version is ready in a second or two after saving.

rangoon626 6y ago

SAM feels wrong to me, it’s way too much friction. I was planning on trying out FastAPI + Zappa, but have not gotten round to it yet.

jpdb 6y ago

I used to be complain about the same thing and even asked someone who was head of BD for Serverless at AWS what they recommended, and didn't get an answer to my satisfaction. After working with more and more serverless applications (despite the development pains, the business value was still justified) I realized that local development was difficult because I was coupling my code to the delivery. This is similar to the way you shouldn't couple your code to your database implementation. Instead, you can write a function that takes parameters from elsewhere and call your business logic there. It definitely adds a bit more work, but it alleviates quite a bit of pain that comes with Lambda local development. Disclaimer: I work at AWS, however not for any service or marketing team. Opinions are my own.

jacques_chester 6y ago
> I realized that local development was difficult because I was coupling my code to the delivery. Of interest, I've spent some free time crunching on CNCF survey data over the past few months. Some of the strongest correlations are between particular serverless offerings and particular delivery offerings. If you use Azure Functions then I know you are more likely to use Azure Devops than anything else. Same for Lambda + CodePipeline and Google Cloud Functions + Cloud Build.
- oblio 6y ago
  I think his point was that you should be able to run and test the Lambda code independently of Lambda. After all the entry point is just a method with some parameters, you can replicate that locally.
  - jacques_chester 6y ago
    ... ah.
  - losteric 6y ago
    Yes, this is a great way of doing things - I have no problems TDD'ing business logic hosted in Lambda, because the business logic is fully decoupled from the execution environment. SAM should be for high-fidelity E2E integration testing.

inoop 6y ago

Take a look at the [CDK](https://aws.amazon.com/cdk/ https://aws.amazon.com/cdk/) if you haven't already. It lets you define your infrastructure using TypeScript, which then compiles to CloudFormation. You can easily mix infrastructure and Lambda code in the same project if all you're doing is writing some NodeJS glue Lambdas which sounds like what you're looking for. There's a couple of sharp edges still but in general it just 'makes sense'. If you don't like TypeScript there are also bindings for Python and Java, among others, although TypeScript is really the preferred language.

autotune 6y ago
This doesn't solve the general lack of observability, lack of logging, and slowness of CloudFormation itself.
- mylons 6y ago
  AWS Lambda logs to Cloudwatch, and has monitoring out of the box.
  - deleted 6y ago
    [deleted]
  - autotune 6y ago
    Very poor logging and monitoring, in my experience.
    - mylons 6y ago
      Poor how? Do you not like the UI? The UI is not the best, but there’s no issue in reliability.
nullsense 6y ago
CDK made IaC accessible to me. I hated raw CloudFormation and never bothered with it because of that reason. I had a crack at Terraform, but never got passed the learning curve before my enthusiasm died. Currently using some CDK in a production app and finally I found a way of doing IaC I actually enjoy.

k__ 6y ago

SAM is okay-ish. Felt still better than K8s to me. Have you tried Amplify?

eghri 6y ago
I found Amplify excellent to get up and running quickly. I’d highly recommend it for anyone without a well-oiled CICD setup who wants to quickly get a website up to test out an idea. Unfortunately, I quickly hit the limits of its configurability (particularly with Cloudfront) and had to move off it within a few months.
- chrisco255 6y ago
  You could just use Amplify for the backend and pair it with any other front end host / CDN provider. I've used it with Vercel and it works great.
- k__ 6y ago
  Care to elaborate on the limits you hit?

revicon 6y ago

we use the serverless framework and use > serverless invoke local All the time for doing testing. You can pass in a json file that contains a simulated event to test different scenarios. Works very well for us.

FrenchTouch42 6y ago
Unfortunately, it has a lot of issues with how credentials are handled. I believe they decided to re-create their own credentials chain and a lot of things are not working with MFA (like support for credential_process).

cmckn 6y ago

Couldn’t agree more, the dev experience was awful. You basically have to develop against public AWS services, my dev machine became a glorified terminal. They do seem to be iterating on the tooling quickly, but I wouldn’t use it again if I had a choice. Edit: CloudFormation was also painful for me, the docs were sparse and there were very few examples that helped me out.

rajamaka 6y ago
> the docs were sparse Over 5000 pages of documentation https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-ug.pdf https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGui... > very few examples that helped me out AWS provide an example for most common services, plus there are thousands of other community supplied examples out there. https://github.com/awslabs/aws-cloudformation-templates https://github.com/awslabs/aws-cloudformation-templates
- cmckn 6y ago
  SAM templates are a subset of CloudFormation templates; that PDF could be three times as long and still not have the content I needed. Yes there are examples, but there wasn’t one at the time that mapped to what I was trying to accomplish. Because, again, SAM templates are not one-for-one CloudFormation templates. I found the community around SAM to be very limited. One of the many reasons I’ve moved to the Kubernetes ecosystem.

wiremine 6y ago

> It's so slow (iteration speed) and you need to jump through a billion hoops of complexity all over the place. Even dealing with something as simple as loading environment variables for both local and "real" function invokes required way too much effort. Honestly, it reminds me of PHP development years ago: running it locally sucked, so you need to upload it to the server and test your work. It. Sucked.

kortilla 6y ago
It was actually pretty good if you had an IDE with sftp/scp support because you could save a file, refresh your browser, and have immediate new results.
- nickjj 6y ago
  Yeah this wasn't too bad and it was what I used to do back in the day with Notepad++. By the time you hit save in your editor, your changes were ready to be reloaded in the browser. With SAM we're talking ~6-7 seconds with an SSD to build + LOCALLY invoke a new copy of a fairly simple function where you're changing 1 line of code, and you need to do this every time you change your code. That's even with creating a custom Makefile command to roll up the build + invoke into 1 human action. The wait time is purely waiting for SAM to do what it needs to do. With a more traditional non-Serverless set up, with or without Docker (using volumes) the turn around time is effectively instant. You can make your code change and by the time you reload your browser it's all good to go. This is speaking from a Python, Ruby, Elixir and Node POV.
  - iCarrot 6y ago
    The workaround my team uses is to make two entries to start the webapp: one for SAM, one for local. For fast iteration we just `npm start`, and when we're ready to do more elaborated testing we run with SAM. This works pretty well so far.
nicky0 6y ago
Out of genuine interest... is there a modern solution to this problem with PHP/MySQL? (I'm still doing the "upload to server to test" thing.... I've tried MAMP and Vagrant/VirtualBox for local dev but both of them seem horribly complex compared to what we can do with local dev with node.js/mongo and so on.)

GFischer 6y ago

I can report that Azure Function App development is at least pretty decent, as long as you have the paid Visual Studio IDE and Azure Function Tools (haven't tried the free version yet). I tried AWS Lambdas a few years back and it felt way more primitive.

skvark 6y ago
Azure Function App development experience is indeed pretty nice at least when using .NET Core. There are some issues, like loading secrets to the local dev environment from Key Vault has to be done manually and easy auth (App Service Authentication) does not work locally.
GordonS 6y ago
I use JetBrains Rider, rather than Visual Studio, and the dev experience is excellent, just the same as with VS.

raverbashing 6y ago

AWS tooling is one pain point Yes, SAM sucks. Boto3 sucks. I mean, yes, the AWS APIs are not the most obvious or ergonomics thing.

erikerikson 6y ago

See the serverless framework [0]. AWS built SAM because they wanted an in house option. [0] https://www.serverless.com/ https://www.serverless.com/

hendry 6y ago

https://github.com/apex/up https://github.com/apex/up is a godsend for deploying on AWS Lambda for me. By the same author as Express JS, TJ Holowaychuk. TJ abstracts the Lambda nonsense so you just get to use a standard HTTP res/resp interface. https://github.com/apex/up-examples/ https://github.com/apex/up-examples/ Deployment iterations for me in Singapore can be as low as 2s, but tbh I use https://github.com/codegangsta/gin https://github.com/codegangsta/gin locally for development iterations.

nuker 6y ago

> Kind of surprised the article didn't mention .. What does it mention?

habosa 6y ago

It definitely doesn’t have to be that way. I work on Firebase and I’ve spent most of the last year specifically working on our local development experience for our serverless backend products: https://firebase.google.com/docs/emulator-suite https://firebase.google.com/docs/emulator-suite Still very actively working on this but our goal is that nobody ever has to test via deploy again.

randomsearch 6y ago
Love firebase, thanks for your work! the local emulator suite is so important a feature and keenly following your progress. Slightly OT... perhaps cheeky... any idea why firebase doesn’t provide automated backups for firestore and storage out of the box? Seems like a no brainer and a valuable service people would pay for.
- habosa 6y ago
  We're working on Firestore backups. Haven't heard many people ask for Storage backups though ... so I don't think that's on the roadmap at the moment.
robertlagrant 6y ago
I'm currently working on a little project backed by Firebase. Really interesting. Good to hear you're doing this - at my day job one of our key factors in choosing a technology is whether we can spin it up in docker-compose in CI and do real-as-possible ephemeral integration tests.

philliphaydon 6y ago

My experience is with .NET Core and the development experience is awesome... Dropped a $250/m cost down to ~$9/m moving it from ec2 to lambda's. Environment variables are loaded no differently between development and prod. Nothing is all over the place as it's almost 0 difference between building a service to run in Linux/Windows vs a Lambda.

sajithdilshan 6y ago

Just throwing this out here https://www.slappforge.com/sigma https://www.slappforge.com/sigma Last time I checked, it even provides in-built code debugging as well. DISCLAIMER: I used to be a developer of this product (it's from the previous company I've worked)

GordonS 6y ago

I've used Azure's serverless offering "Functions" quite a bit. The dev experience is pretty good, actually - it "just works" - start it and point your browser at the URL. And certainly no problems setting up env vars or anything basic like that. My only nitpick, and only specifically relating to dotnet, is that config files and env vars differ between Functions and regular ASP.NET Core web apps. I think there is some work going on to fix that, but it's taking forever.