The serverless community appears to be embracing cloud native development practices. SST makes this super easy with the live lambda development environment. How, if at all, does this approach of development change if there are non-serverless resources in an application?

I haven't seen too much of a difference, as long everything is controlled under the same iac tool things generally "just work"

For example, I work on an application stack with both serverless and non-serverless microservices. The non-serverless services are generally Flask API's hosted in ECS, while the serverless services are APIG/Lambda. SST provides an incredible developer experience by allowing me to develop against my compute layer locally. I'm wondering how to apply this same pattern to my colleagues that are stuck in the stone age developing container-bound microservices

We have been thinking about container workloads internally as well. Something to compliment those cases where Lambda just isn’t a good fit.

Yeah, I've been trying to reason about cloud native development environments with an organization that needs to support both serverless and non serverless workloads.

yeah maybe a way to think about containers is they're intentionally not cloud native. It's about packing up an app into a blackbox your cloud willl run no questions asked. So there's less benefit to running it in the cloud during local development, might as well run it locally

Exactly. I think there is an opportunity for an overlapping approach if the container is interacting with AWS services. For example, a API that publishes to EventBridge/SQS/SNS, etc

I have same problem in my org. We have around 60 microservices built with NestJS running on k8s managed on EC2. But some new stuff is being created with SST using lambda.

Another way to look at this is that if we could mock all AWS services locally reliably one-to-one identically (running AWS on ur laptop), we should just do that. But that is not possible. What Live Lambda does is it tries to mock the least, which is the node process running inside the Lambda function. Note that SST is not mocking Lambda locally, just the node process running in there. And SST better do a good job at mocking that. But with ECS, u can actually do a reasonable job of mocking everything going on in that “blackbox” locally. So u should just do that imo.

@Frank Can you elaborate on what you mean by mocking everything going on in the blackbox locally? Are you suggesting apps meant to run within EC2 that have AWS dependencies (RDS, SQS, etc) should mock those services locally?

@Michael Clifford and I are now working at another company and trying to introduce SST/CDK and Serverless architectures, and we will be in a similar situation of what @Adrián Mouly described. We have many NestJS containers running in EC2, so we will have to figure out the same thing so the developer instances could work for the entire ecosystem.

Heh, grab a beer and have a seat at our table.

Don't feel bad. The first 2 years at my current gig, we developed using serverless-framework form the start(I was the first engineer/architect). Since then the c-level folk decided to hire a "more experienced" architect and since then, everything is moving to containers. they've had to hire half a dozen people who are still trying to work out a stable deployment pipeline for their containers. started with CodePipeline/ECS now morning to K8s. It's depressing.

Oh man, you can have VIP tickets to the support group 🙂

@Brett Fieber don’t feel bad… My company hired a CTO with serverless mindset, and he hired me to start refactoring the existing Core application from Laravel into Serverless. After 1 year, this CTO had to step out for personal reasons. The new CTO decided to stop Serverless development and re-implement everything into the existing Core Laravel (which was in deprecation process). So now we have like 5 php developers and just 2 serveless developers maintaining the “new-legacy” serverless backend, and start to kill it piece by piece.

Noo

But well, the existing part will remain in SST … for some years maybe… until I leave? hahahah.

I just gave a demo to my org today about local vs cloud development, and used SST for the demo. It was well received.

That’s awesome, it’s part of the investment as developers that we need to do, empowering other teams or colleagues.

Agreed. But boy is that a lot of work!

Totally… I always say… doing code is the easy part 😂 .

We had a group of engineers come through and try to shoehorn things like Apollo Federation into a Lambda. Sadly, instead of getting educated on what serverless is all about, the decided that serverless sucks. No matter how many times I said it was bad design/implementation. Not bad framework. Tried to get them to try AppSync or just ditch the federation, but they only knew Apollo, so tried to force it. Those engineers are all gone now. Wish they took the suits that they corrupted with them.

Winning hearts and minds is backbreaking work 😆

Yeah that’s true. Btw, if there’s material we should be putting out that can help with these conversation, please let us know!

@Brett Fieber I've seen that exact pattern play out before, it's painful. It can take years to overcome the hesitance to try again

On the good side, they had a team of 8 in LATAM who after 4 months hadn't delivered an API using their new container model. They came to me asking if I could do it. I said only if I can do it with serverless. They were desperate, so I got my way. Deployed my first SST full-stack app in 9 days.

You can't argue with results

But they are still convinced that serverless is the wrong path and are still pushing containers.. <where's the icon for ripping my hair out>

Well there is something in the middle… Lambda can run a Container too, haha.

The "new" architect, said we were going containers because as an organization, "we aren't ready for serverless" My response: "We were 100% serverless before you got here. YOU aren't ready for serverless. Get educated". So instead of getting educated, they keep hiring container-centric engineers to support their outdated vision.

Actually, in this job we had to do that… there is an AI developer who build their function into container… and we push it to lambda.

haha.. I told them that.. Lambda's ARE containers. And AWS already provides a scaling mechanism, and SF/SST/Seed provide a dead-simple deployment pipeline. The problem is they are incapable of re-thinking their code to not be a full blown server.

Which is worst… they still using EC2 .. with downtimes and everything.

ugh. my last experience with php was a nightmarish drupal project I had inherited. I replaced it with Java. But that was couple jobs ago. Hope I never have to play with that again.. hehe