I wrote a piece (a semi-rant about serverless) where I mention you folks 🙏 https://caludio.medium.com/a-couple-of-things-about-serverless-development-not-a-rant-f9d63895b850 (at the end)

I really resonate with the “developing with a fast feedback loop” part… it seems staying away from the docker approach is the right choice 😆

I am used to React and nodejs server development (and in TS), which both have almost instanteneous feedback… when I started investigating with SAM I was like… “wait, what?” 😄

yeah.. I really liked the create-react-app experience

yeah, game changer – unfortunately now it has become a standard de-facto that makes almost impossible doing anything else differently. Recently we “ejected” a project and… oh boy, what a mistake it was.

It’s an interesting opinion. In terms of the things to think about when designing an application, I think they’re just a different set of things compared with the more traditional architectures. Remember, moving to a 3-tier architecture felt odd at one time and the tooling for it needed to adapt. As for adopting micro-services, I think there’s a tipping point in trading infrastructure complexity for application complexity, striking the right balance for your own team or organisation will differ depending on skill sets and team structure. In terms of that developer experience, things are improving all the time. I haven’t (yet) moved to SST but using the serverless framework with serverless-offline has been a positive experience. Running some services in Docker like dynamodb-local hasn’t been a problem at all (on a Mac - interested in what Docker issues you have - our Windows devs have many more problems). I agree, getting the instant feedback while running real services in AWS is very attractive though. We moved away from YAML files as soon as I found out the same serverless framework template could be written with TypeScript however, writing ‘real’ TypeScript constructs to build the infrastructure is where I’d like to be soon. Having that witchcraft feedback proxy is the feature that will make us schedule this, whereas CDK was more of a nice-to-have.

CDK makes the “devops should be part of the dev team” idea, a reality. I love it.

I should also add, Seed had been critical in our adoption of serverless too

As for adopting micro-services, I think there’s a tipping point in trading infrastructure complexity for application complexity,

yeah, as the “architect” of the company I struggle with this every single day. It takes a long time to get used to it.

Indeed. I feel like there's a trend toward overmicroservitisation (I just made that word up, can you tell? 😁) because so many blogs are written about the likes of Netflix's architecture. The truth is, there ain't many companies in the world that are solving problems anywhere near that scale or with the resources to do so.

“microservice” is definitely an overrated concept, and a dangerous one if a new microservice means a new “micro-system” to manage and orchestrate (as in, a new Java Spring boot application). But here is the kicker: I think serveless helps making sense of what a “microservice” really is: a group of functions working in the same domain (file, banking, user auth…). They are lightweight and don’t need to manage their public interface (yay for API GW!)

Interesting, for us it’s a bit different. For example we have a single repo for all the modules for one of our products. They’re lambdas communicated with predominantly through various API Gateway routes. There’s still a storage ‘layer’ using DynamoDB. which is common to many of those modules. However, they can still be worked on separately, despite being in the same repo. We find it’s more straightforward to share common things like logging and auth across the modules when done that way

@claudioc Appreciate the mention! I think with SST some of the best practices in terms of organization are still being figured out. So it'll great if people share what they are learning as they are using it with their teams.