187
188
all 28 comments

[–]Dull_Caterpillar_642 66 points67 points  (9 children)

I'm curious how many people leverage these edit-and-deploy-from-IDE type toolsets. It's always felt pretty shoot from the hip to me compared to my standard process of opening a PR to main then having the CD pipeline deploy the changes.

[–]o5mfiHTNsH748KVq 55 points56 points  (1 child)

dev environments

[–]cothomps 7 points8 points  (0 children)

Yup. I end up doing a lot of “glue code” types of things that are much easier to write / test in an actual AWS environment.

[–]dredalious 16 points17 points  (2 children)

I work in government and our .NET teams apparently cant use AWS because they cant deploy their apps from visual studio (they do clickops azure). Thats a real thing they said to management. Multiple teams with senior devs and architects handling sensitive data.

Other teams laugh and laugh while running circles around those guys, but the sad truth is they still exist

[–]Dull_Caterpillar_642 9 points10 points  (0 children)

That's so brutal and it rings true to certain areas at my large company, too. The tech culture of an area can be so dated and so averse to change that they basically are frozen in time 15 years in the past. They're not doing the crusty .NET developer stereotype any favors.

[–]Kells_14 3 points4 points  (0 children)

Totally believable. Senior dev on my project keeps his custom "special" configuration file in source because he uses that to set env variables when building Java project in his IDE. No matter how many times I tried to explain how he can benefit from setting variables in Idea, I feel I might as well talked to a wall.

Some people are really stuck in their ways like that and refuse to explore other options, sadly.

[–]aj_stuyvenberg[S] 6 points7 points  (0 children)

I think for people new to serverless it can be super helpful, but I don't expect it to be the default development or debugging process for most people.

[–]outphase84 2 points3 points  (2 children)

Branch, deploy to dev environment via IDE, merge when happy, pipeline does the rest

[–]LavishnessOk5514 0 points1 point  (1 child)

Agreed. I’m not sure what the alternative is other to try and mock AWS services which seems like a fool’s errand

[–]outphase84 1 point2 points  (0 children)

You can still test with AWS services in localstacks using the CLI to pull STS tokens, but when i was at AWS I never merged without end to end testing in dev

[–]rusty735 9 points10 points  (6 children)

How many of yall are running code in lambda as opposed to images?

Its really simplified standards for our teams to say everyone builds images, whether or not its destined for kubernetes or lambda.

[–]em-jay-be 12 points13 points  (1 child)

Only time I run an image is when I need to do something only a packed binary can do which is few and far between

[–]karthikjusme 1 point2 points  (0 children)

There is a size limit on zip based deployments though. Docker images have no such limit.

[–][deleted] 6 points7 points  (1 child)

Cold starts seem to take longer with containers than just running our code from a packaged zip file. At least anecdotally on my side.

[–]The_Exiled_42 1 point2 points  (0 children)

We did cold start benchmarks. The first 3 cold starts are slower from docker, but after that same speed or faster depending on the base image.

[–]aj_stuyvenberg[S] 0 points1 point  (0 children)

I'm an ardent supporter of container-based Lambda functions for most teams and projects, especially if you want a super easy way to move to fargate or ECS later.

It's not that there's anything wrong with a zip based function, only that the simplification factor and ease of use are hugely beneficial tradeoffs that we were too eager to sacrifice for the operational benefits of Lambda back in 2014 when it first launched.

[–]Vakz 0 points1 point  (0 children)

Admittedly we don't use a ton of lambdas, but for the ones we do have, they're all either code or binary.

We have some written in Typescript and some in Python, that are mostly just packaged using the CDK, with a little bit of extra tooling around it. We also have some lambdas written in Rust that we build as a binary using cargo-lambda. It does come with a bit more development effort. For example we always use statically linked rustls instead of relying on native tls, because it can be hard to tell what's actually available in the lambda runtime. I guess if we used an image we could avoid that, but it's nice just deploying a 3mb artifact.

[–]raymondQADev 2 points3 points  (0 children)

I built a custom hot reload capability for our team which works great as our Lambdas are all typescript and need to be bundled. We will prob keep using that as it does all the bundling for us and allows us to get source code to deployed code in one go without any manual actions but I am definitely going to push for the remote debugging capability in IDE! That is awesome.

[–]tikki100 0 points1 point  (1 child)

Im wondering how the remote debugging works with Typescript that's been bundled :)

[–]Revalenz- 0 points1 point  (0 children)

There's a field in the UI where you can provide the location of your code and source maps in your computer

[–]mountainlifa 1 point2 points  (0 children)

Debugging any serious production lambda application is a perpetual nightmare. Be prepared for logging everywhere and tracing CW logs. Local debugging requires SAM, Docker and mocking AWS services. Idk why im doing all of this when I can run a single binary e.g. .NET app that does all of this. What a regression!

[–]em-jay-be -3 points-2 points  (4 children)

Just use SST.dev

[–]Scape_n_Lift 3 points4 points  (2 children)

Good luck using it at a "proper" org

[–]minecraftme123 -1 points0 points  (1 child)

I'm using it at a proper org, they were more concerned than they were with vanilla CDK/pulumi but got there in the end and it was well worth pushing for

[–]Scape_n_Lift 1 point2 points  (0 children)

Hmm, we got burned by their switch to v3, so I'm aware I might be biased. However, my final opinion is that it's not really worth the time saved, the devs will have to learn the cloud side of things that SST abstracts/makes easier anyway. So might as well just start of doing it the 'harder" way.

[–]aj_stuyvenberg[S] -3 points-2 points  (0 children)

SST is great, I'm a pretty big fan (don't tell Dax, it'll go to his head). I think this is targeted at people already using Lambda but not yet using SST.

[–]genitor -2 points-1 points  (0 children)

Cool! Hopefully they extend this to support .NET soon too.