7 ms·

Post-Serverless Era Trends

50 points by bibryam 3y ago

deleted 3y ago
[deleted]
andrewstuart 3y ago
Serverless - there's the strongest cloud lock in right there.
- willsmith72 3y ago
  Eh you can still use a lot of the regular frameworks and libraries on top of serverless, and then easily switch between cloud and on prem. I wouldn't go all in in a stack which only worked for example on lambda, but I don't think that's the way most people are going anyway
  - emestifs 3y ago
    > I don't think that's the way most people are going anyway Unfortunately some are. And not only that, but also full steam ahead on a 100% locked-in, read _all_ the AWS (serverless)services, AWS-only stack. I speak from unfortunate experience.
    - mikhmha 3y ago
      Yup me too. Just got out of working at a B2B SaaS that was 100% AWS serverless - Lambda, S3, dynamoDB and all that. I worked there for 3 years! When I started 3 years ago - the owners touted the benefits of all of it. And I agree its not all totally bad. There are some valid use cases for small enterprise projects. BUT after 3 years it was really starting to wear me down. The codebase just kept growing, there were so many lambdas to keep track of. It was so hard to test and observe the system in production. Sure you can address some of these pitfalls by creating your own tools that wrap AWS API calls but it never ends. It doesn't make your life easier, you still have to write a bunch of extra glue code because a lot of the tooling for these serverless platforms is terrible and left up to frameworks to solve.
- jmaker 3y ago
  I know what you mean but it’s been quite fine for me. With AWS, you have a JMS compliant message router in SQS, and SNS is okay, just might need an adapter to the message schema. I don’t like some of their limitations that are foreign to me when integrating over Artemis, Pulsar or Rabbit, and Kafka. Lambdas are just runtime system containers, you can use Spring Cloud Functions or any of the myriad of compatible approaches. RDS is but a scaled HA Postgres or MySQL service. Redis, DynamoDB, MKS, Keyspaces, and so on, can all be hosted on-premises. Not really a lock-in.
xnx 3y ago
The future has to be something more like code-on-cloud. Infrastructure should be so abstracted and effortless that development is mainly creating and editing core logic into a web-based development environment. Only the heaviest/purest technology companies and hosting companies (Google, Meta, Microsoft, TikTok) should get down to the level of worrying about the next level down.
- packetlost 3y ago
  This is such an insanely short-sighted and downright ignorant statement to make. Not everyone is working with highly abstracted "web applications". If your entire infrastructure doesn't think of anything lower than HTTP, sure. But the industry is so much larger and there are so many reasons to care about the actual hardware your code runs on.
- splitstud 3y ago
  [dead]
- rollcat 3y ago
  Code runs on computers, and cloud is just a single word for "someone else's computer". Great, you've outsourced hardware provisioning, maybe even OS patches - that's smart, this is not your core business, just like toilet plumbing isn't. But you still need to hire someone to carry a pager, and when the plumbing fails, that person needs to understand what exactly went wrong - sometimes at 3AM on a Sunday. Engineering and operations is not just layering abstractions, we've had Lisp 60 years ago and yet it didn't solve everything.
- mikhmha 3y ago
  I think the future is some BEAM-like VM abstraction for cloud environments. I worked at a 100% AWS serverless place and the current tooling is terrible. Now I'm working in Elixir and it offers so many of the tools I wish I had when working there.
- spacebanana7 3y ago
  Some infrastructure decisions need to be made by app developers. For example, anybody with hard security environments (finance, healthcare, defence) needs to make sure that some services aren’t available on the public internet but are capable of communicating with internal services. This kind of networking requirement is essentially tied to the application layer - only application development organisations can know whether e.g the service to check why a user is banned should be on the public internet. Such a decision could be expressed by app developers using infrastructure as code, UI toggles or physical buttons in a DC - but it has to be their decision. Similar logic applies to DNS, data isolation, backup policies, caching strategies and much more.
mrtksn 3y ago
IMHO the future should be one where there is no difference between computers and the service providers simply provide always on, always connected devices. Is there any reason why there's a "server" or "serverless servers"? Why everything isn't just apps talking to each other? I think no, there's no real hard reason but just its how evolved as the early on the connectivity and device power was drastically different for devices that users had and devices that were needed to process data and stay on forever. At this day, a JavaScript code can be the engine on a desktop machine, on a mobile app, on HTML client page and on a backend server. Actually, with WASM and some other tools any language can do the same. Its even possible for everything to run in a browser that is available on every platform and all that running in decent speeds because our computers are all supercomputers and the significantly different high performance computing is happening on GPUs.
- reactordev 3y ago
  "Is there any reason why there's a "server" or "serverless servers"?" Yes, you can not run compute processes without compute. A server is where that compute happens. Serverless is a concept that your function will run on "some" compute, that you don't have to manage. It does, however, require compute. So running that function on your mobile device, a server, a fridge, all within the realms of possible. You still, in the end, need compute to execute the code. Decentralized compute (running on your devices or someone else's) is what serverless is (only, it's wrapped behind a service offering so it's not completely decentralized).
  - mrtksn 3y ago
    Compute? Never heard of it. Whatever it is, just drop it and use computers that can execute some high level languages like JavaScript to perform directly useful actions like storing information in embedded DB like SQLite, reading information, transforming information, transmitting information and displaying information - stuff that can be done with huge performance even on 5 years old mobile phones. So all that "serverless" stuff is basically that but its using traditional server software behind the scenes to provide maintenance free interfaces to do all the things I mentioned. Another aspect is that the client devices may connect to server resources and directly manipulate data without an intermediary code on the "server" and you still don't need specialised hardware to handle it, its handled cryptographically using algorithms that any computer can run. The problem with it is that its proprietary non portable software that locks you in. Instead of that, you can run the exact same software on every computer(in the datacenter, at the company building, in the hands of people etc). Bottlenecks occur in certain situations, so you don't store all your clients information on every machine and the problem is solved. You run the same platform everywhere but each machine operates with an algorithm suitable for its role. Modern consumer computers are beasts, they are capable of processing huge amount of data. Its common for handheld devices to load megabytes of of JavaScript, compile it, render graphics with it, handle inputs and send data tens of times per second to multiple servers as the user is interacting with it. I don't believe that a device capable of doing that will have hard time storing and fetching from an SQL database with a few thousand rows.
teknopurge 3y ago
I've seen the exact opposite - many projects are going back towards monolithic structures and then decoupling a minority of components that need to horizontally scale.
- spacephysics 3y ago
  This I feel is the ideal way in many many cases. Only separate out components if the additional cost of service communication (when moving the component away from a monolith) is less than the benefits of scaling/separate repo/etc. Cost also includes the orchestration and such
  - sn0wf1re 3y ago
    I'm personally a fan of the mono-microlith (or whatever people call it), where you compartmentalize the monolith so that it's a just a flag of what "micro-services" are enabled on each instance. Easy to scale down on a dev machine (one process) and easy to scale out, the local procedure calls just become remote procedure calls (over HTTPS or whatever).
- camgunz 3y ago
  Yeah I think there are fundamental challenges with microservices that are very hard to address unless you're someone like Google and you can invent BigTable and Zanzibar. It used to be you needed to move processing into app code and out of the database because they were hard and expensive to scale, but that's not true anymore.
  - jzelinskie 3y ago
    The nice part is that we're no longer at the beginning of this journey. BigTable and Zanzibar already have open source equivalents: HBase/Cassandra-likes (hard to pin BigTable to just one thing) and SpiceDB. As these projects mature, they only become easier for folks to adopt into their architectures and get all the same benefits.
    - 3y ago
gatvol 3y ago
Not on board with this, other than the advantages that solutions like Pulumi have over 2nd gen IaC tooling like TF. Pulumi is far more extensible and composable than anything else I've seen out there.
- willio58 3y ago
  Pulumi is fantastic, just wish it was more popular honestly. That and how you have to handle async stuff with it feels kinda weird in the era of async await in JS. But it's wild, our tech stack at the company I'm working at is Typescript all the way down. Frontend, Backend, Infrastructure is all typescript. Our team loves it. We also use serverless. Given the perspective in this thread I'm expecting downvotes but we love that too. I think serverless is just like everything else. If you implement it poorly it can be slow, expensive, and pointless. If you implement it well it can be cheap, fast, and keep your team lean.
  - mind-blight 3y ago
    What Typescript infrastructure code are you using? I'm looking for alternatives to TF, so if love to know what's working for people
  - freedomben 3y ago
    This is very much a meta comment, but: > Given the perspective in this thread I'm expecting downvotes but we love that too. It's a sad commentary that this is the case on HN. People using down votes as lazy disagreements against an opinion they don't like is fundamentally anti hacker IMHO.
fvdessen 3y ago
Has anybody actually tried to program as these serverless / microservices articles propose ? Having a collection of lambdas orchestrated by infrastructure as code ? I have and the result has always been a complete nightmare… I’m starting to think I’m not actually an idiot doing it wrong, but that I’m being sold snake oil by cloud companies and ex-programmers who now make money writing books and powerpoints for conferences :(
- netghost 3y ago
  I think it solves a very specific set of problems that most people probably don't have. For example, if scaling various parts of your application independently is a hard requirement, you're going to want to follow some set of these practices. Otherwise you're probably not going to see any practical benefits relative to the additional complexity.
- gofreddygo 3y ago
  All of my past projects where we implemented these cloud paradigms, didn't need them. There were better options to extract performance and improve scale than going all-in for cloud based migrations. sure, that OS patch was auto updated, but that vuln in our deps that showed up over the weekend did suck in our time. We lost productivity, the cloud credits ran out and so did our good folks.
- jamesfinlayson 3y ago
  I inherited a project that was a collection of Lambdas set up with the Serverless framework - there are Lambdas that proxy HTTP requests to other Lambdas plus Lambdas sending messages via SNS to other Lambdas. Tracing/debugging is difficult, and in many cases something seemingly straight-forward is more complex than it needs to be.
- myaccountonhn 3y ago
  Currently used at my current company. It is a nightmare in terms of development. OTOH it is a nice feeling not needing to worry about servers suddenly going down or some sql query tanking prod, which Id say is the only upside
- 3y ago
teaearlgraycold 3y ago
I’m instantly skeptical about any web tech that promotes performance, scalability, or cloud cost optimization. Those are absolutely not the pain points for 99% of developers.
- ardaoweo 3y ago
  I agree. My team has been building systems integrations for years, and it's figuring out what the customers want, and dealing with bad, inconsistent data accumulated over decades that makes life hard. Moving these boring microservices that handle this data from on-prem to the cloud wouldn't solve any of our problems. Most of our customer-facing services also run with on-prem VM instances just fine.
skywhopper 3y ago
This article puts together a lot of real things that exist and confuses what is actually happening. The new technologies aren't replacing the old ones. They are supplementing them. Not only that, but the author is apparently confused about a lot of the pieces. I'll take just the Infrastructure as Code section since I know the most about it. First it says Infrastructure as Code was a bunch of DSLs like Ansible, Chef, and Puppet. No, those were the second wave of "Configuration Management". Some folks might include them in "Infrastructure as Code", but I wouldn't. They are tools to manage configuration of traditional servers. They have some IaC capabilities, but they are very limited and not really the core of what these tools provide. Terraform and CloudFormation are the real exemplars of "Infrastructure as Code". They take a declarative, relatively static approach to defining infrastructure. That's honestly fine for most cases. But I'd lump the AWS CDK and Pulumi in here too. They aren't something new, they just bring the ability to use more traditional languages to the game. But they don't fundamentally provide more flexibility than traditional TF or CF, because they are still bound to the static plan/apply cycle. I'd not heard of "Composition as Code" until reading this article. But to the extent its meaning is clear from this context, the author isn't making any sense. The author says CaC allows developers to use "finer grained" infrastructure specification than IaC, but if anything, that's the opposite of what they do. By abstracting things into broader chunks of multiple pieces of infrastructure, they are by definition working with "coarser grained" infrastructure. Anyway, as folks here point out, the movement towards highly specific components rather than actual code for building cloud-hosted services just trades one set of problems (scaling; dealing with VMs; having sysadmins) for another (business logic spread out over dozens of individual "components"; impossibility of rapid testing and troubleshooting; requires massive supporting observability infrastructure to make sense of).
lgkk 3y ago
Serverless is fine. I always find that people try to shoehorn everything into something trendy for no reason. Like I use serverless for a handful of async tasks that can run in background. Common things like image resizing, processing data to make metadata tags or something, or some things that I would have originally used Kafka for. With serverless especially if I’m already on aws for example I have access to the whole ecosystem. Once something completes it can just write data to some store. Done. I don’t need to lose my sanity fixing Kafka event failures and other bs. Core logic goes into monoliths or services. Anything that can be offloaded that’s an atomic operation goes to serverless from either mono or service.

50 points by bibryam 3y ago

deleted 3y ago

[deleted]

andrewstuart 3y ago

Serverless - there's the strongest cloud lock in right there.

willsmith72 3y ago
Eh you can still use a lot of the regular frameworks and libraries on top of serverless, and then easily switch between cloud and on prem. I wouldn't go all in in a stack which only worked for example on lambda, but I don't think that's the way most people are going anyway
- emestifs 3y ago
  > I don't think that's the way most people are going anyway Unfortunately some are. And not only that, but also full steam ahead on a 100% locked-in, read _all_ the AWS (serverless)services, AWS-only stack. I speak from unfortunate experience.
  - mikhmha 3y ago
    Yup me too. Just got out of working at a B2B SaaS that was 100% AWS serverless - Lambda, S3, dynamoDB and all that. I worked there for 3 years! When I started 3 years ago - the owners touted the benefits of all of it. And I agree its not all totally bad. There are some valid use cases for small enterprise projects. BUT after 3 years it was really starting to wear me down. The codebase just kept growing, there were so many lambdas to keep track of. It was so hard to test and observe the system in production. Sure you can address some of these pitfalls by creating your own tools that wrap AWS API calls but it never ends. It doesn't make your life easier, you still have to write a bunch of extra glue code because a lot of the tooling for these serverless platforms is terrible and left up to frameworks to solve.
jmaker 3y ago
I know what you mean but it’s been quite fine for me. With AWS, you have a JMS compliant message router in SQS, and SNS is okay, just might need an adapter to the message schema. I don’t like some of their limitations that are foreign to me when integrating over Artemis, Pulsar or Rabbit, and Kafka. Lambdas are just runtime system containers, you can use Spring Cloud Functions or any of the myriad of compatible approaches. RDS is but a scaled HA Postgres or MySQL service. Redis, DynamoDB, MKS, Keyspaces, and so on, can all be hosted on-premises. Not really a lock-in.

xnx 3y ago

The future has to be something more like code-on-cloud. Infrastructure should be so abstracted and effortless that development is mainly creating and editing core logic into a web-based development environment. Only the heaviest/purest technology companies and hosting companies (Google, Meta, Microsoft, TikTok) should get down to the level of worrying about the next level down.

packetlost 3y ago
This is such an insanely short-sighted and downright ignorant statement to make. Not everyone is working with highly abstracted "web applications". If your entire infrastructure doesn't think of anything lower than HTTP, sure. But the industry is so much larger and there are so many reasons to care about the actual hardware your code runs on.
splitstud 3y ago
[dead]
rollcat 3y ago
Code runs on computers, and cloud is just a single word for "someone else's computer". Great, you've outsourced hardware provisioning, maybe even OS patches - that's smart, this is not your core business, just like toilet plumbing isn't. But you still need to hire someone to carry a pager, and when the plumbing fails, that person needs to understand what exactly went wrong - sometimes at 3AM on a Sunday. Engineering and operations is not just layering abstractions, we've had Lisp 60 years ago and yet it didn't solve everything.
mikhmha 3y ago
I think the future is some BEAM-like VM abstraction for cloud environments. I worked at a 100% AWS serverless place and the current tooling is terrible. Now I'm working in Elixir and it offers so many of the tools I wish I had when working there.
spacebanana7 3y ago
Some infrastructure decisions need to be made by app developers. For example, anybody with hard security environments (finance, healthcare, defence) needs to make sure that some services aren’t available on the public internet but are capable of communicating with internal services. This kind of networking requirement is essentially tied to the application layer - only application development organisations can know whether e.g the service to check why a user is banned should be on the public internet. Such a decision could be expressed by app developers using infrastructure as code, UI toggles or physical buttons in a DC - but it has to be their decision. Similar logic applies to DNS, data isolation, backup policies, caching strategies and much more.

mrtksn 3y ago

IMHO the future should be one where there is no difference between computers and the service providers simply provide always on, always connected devices. Is there any reason why there's a "server" or "serverless servers"? Why everything isn't just apps talking to each other? I think no, there's no real hard reason but just its how evolved as the early on the connectivity and device power was drastically different for devices that users had and devices that were needed to process data and stay on forever. At this day, a JavaScript code can be the engine on a desktop machine, on a mobile app, on HTML client page and on a backend server. Actually, with WASM and some other tools any language can do the same. Its even possible for everything to run in a browser that is available on every platform and all that running in decent speeds because our computers are all supercomputers and the significantly different high performance computing is happening on GPUs.

reactordev 3y ago
"Is there any reason why there's a "server" or "serverless servers"?" Yes, you can not run compute processes without compute. A server is where that compute happens. Serverless is a concept that your function will run on "some" compute, that you don't have to manage. It does, however, require compute. So running that function on your mobile device, a server, a fridge, all within the realms of possible. You still, in the end, need compute to execute the code. Decentralized compute (running on your devices or someone else's) is what serverless is (only, it's wrapped behind a service offering so it's not completely decentralized).
- mrtksn 3y ago
  Compute? Never heard of it. Whatever it is, just drop it and use computers that can execute some high level languages like JavaScript to perform directly useful actions like storing information in embedded DB like SQLite, reading information, transforming information, transmitting information and displaying information - stuff that can be done with huge performance even on 5 years old mobile phones. So all that "serverless" stuff is basically that but its using traditional server software behind the scenes to provide maintenance free interfaces to do all the things I mentioned. Another aspect is that the client devices may connect to server resources and directly manipulate data without an intermediary code on the "server" and you still don't need specialised hardware to handle it, its handled cryptographically using algorithms that any computer can run. The problem with it is that its proprietary non portable software that locks you in. Instead of that, you can run the exact same software on every computer(in the datacenter, at the company building, in the hands of people etc). Bottlenecks occur in certain situations, so you don't store all your clients information on every machine and the problem is solved. You run the same platform everywhere but each machine operates with an algorithm suitable for its role. Modern consumer computers are beasts, they are capable of processing huge amount of data. Its common for handheld devices to load megabytes of of JavaScript, compile it, render graphics with it, handle inputs and send data tens of times per second to multiple servers as the user is interacting with it. I don't believe that a device capable of doing that will have hard time storing and fetching from an SQL database with a few thousand rows.

teknopurge 3y ago

I've seen the exact opposite - many projects are going back towards monolithic structures and then decoupling a minority of components that need to horizontally scale.

spacephysics 3y ago
This I feel is the ideal way in many many cases. Only separate out components if the additional cost of service communication (when moving the component away from a monolith) is less than the benefits of scaling/separate repo/etc. Cost also includes the orchestration and such
- sn0wf1re 3y ago
  I'm personally a fan of the mono-microlith (or whatever people call it), where you compartmentalize the monolith so that it's a just a flag of what "micro-services" are enabled on each instance. Easy to scale down on a dev machine (one process) and easy to scale out, the local procedure calls just become remote procedure calls (over HTTPS or whatever).
camgunz 3y ago
Yeah I think there are fundamental challenges with microservices that are very hard to address unless you're someone like Google and you can invent BigTable and Zanzibar. It used to be you needed to move processing into app code and out of the database because they were hard and expensive to scale, but that's not true anymore.
- jzelinskie 3y ago
  The nice part is that we're no longer at the beginning of this journey. BigTable and Zanzibar already have open source equivalents: HBase/Cassandra-likes (hard to pin BigTable to just one thing) and SpiceDB. As these projects mature, they only become easier for folks to adopt into their architectures and get all the same benefits.
  - 3y ago

gatvol 3y ago

Not on board with this, other than the advantages that solutions like Pulumi have over 2nd gen IaC tooling like TF. Pulumi is far more extensible and composable than anything else I've seen out there.

willio58 3y ago
Pulumi is fantastic, just wish it was more popular honestly. That and how you have to handle async stuff with it feels kinda weird in the era of async await in JS. But it's wild, our tech stack at the company I'm working at is Typescript all the way down. Frontend, Backend, Infrastructure is all typescript. Our team loves it. We also use serverless. Given the perspective in this thread I'm expecting downvotes but we love that too. I think serverless is just like everything else. If you implement it poorly it can be slow, expensive, and pointless. If you implement it well it can be cheap, fast, and keep your team lean.
- mind-blight 3y ago
  What Typescript infrastructure code are you using? I'm looking for alternatives to TF, so if love to know what's working for people
- freedomben 3y ago
  This is very much a meta comment, but: > Given the perspective in this thread I'm expecting downvotes but we love that too. It's a sad commentary that this is the case on HN. People using down votes as lazy disagreements against an opinion they don't like is fundamentally anti hacker IMHO.

fvdessen 3y ago

Has anybody actually tried to program as these serverless / microservices articles propose ? Having a collection of lambdas orchestrated by infrastructure as code ? I have and the result has always been a complete nightmare… I’m starting to think I’m not actually an idiot doing it wrong, but that I’m being sold snake oil by cloud companies and ex-programmers who now make money writing books and powerpoints for conferences :(

netghost 3y ago
I think it solves a very specific set of problems that most people probably don't have. For example, if scaling various parts of your application independently is a hard requirement, you're going to want to follow some set of these practices. Otherwise you're probably not going to see any practical benefits relative to the additional complexity.
gofreddygo 3y ago
All of my past projects where we implemented these cloud paradigms, didn't need them. There were better options to extract performance and improve scale than going all-in for cloud based migrations. sure, that OS patch was auto updated, but that vuln in our deps that showed up over the weekend did suck in our time. We lost productivity, the cloud credits ran out and so did our good folks.
jamesfinlayson 3y ago
I inherited a project that was a collection of Lambdas set up with the Serverless framework - there are Lambdas that proxy HTTP requests to other Lambdas plus Lambdas sending messages via SNS to other Lambdas. Tracing/debugging is difficult, and in many cases something seemingly straight-forward is more complex than it needs to be.
myaccountonhn 3y ago
Currently used at my current company. It is a nightmare in terms of development. OTOH it is a nice feeling not needing to worry about servers suddenly going down or some sql query tanking prod, which Id say is the only upside
3y ago

teaearlgraycold 3y ago

I’m instantly skeptical about any web tech that promotes performance, scalability, or cloud cost optimization. Those are absolutely not the pain points for 99% of developers.

ardaoweo 3y ago
I agree. My team has been building systems integrations for years, and it's figuring out what the customers want, and dealing with bad, inconsistent data accumulated over decades that makes life hard. Moving these boring microservices that handle this data from on-prem to the cloud wouldn't solve any of our problems. Most of our customer-facing services also run with on-prem VM instances just fine.

skywhopper 3y ago

This article puts together a lot of real things that exist and confuses what is actually happening. The new technologies aren't replacing the old ones. They are supplementing them. Not only that, but the author is apparently confused about a lot of the pieces. I'll take just the Infrastructure as Code section since I know the most about it. First it says Infrastructure as Code was a bunch of DSLs like Ansible, Chef, and Puppet. No, those were the second wave of "Configuration Management". Some folks might include them in "Infrastructure as Code", but I wouldn't. They are tools to manage configuration of traditional servers. They have some IaC capabilities, but they are very limited and not really the core of what these tools provide. Terraform and CloudFormation are the real exemplars of "Infrastructure as Code". They take a declarative, relatively static approach to defining infrastructure. That's honestly fine for most cases. But I'd lump the AWS CDK and Pulumi in here too. They aren't something new, they just bring the ability to use more traditional languages to the game. But they don't fundamentally provide more flexibility than traditional TF or CF, because they are still bound to the static plan/apply cycle. I'd not heard of "Composition as Code" until reading this article. But to the extent its meaning is clear from this context, the author isn't making any sense. The author says CaC allows developers to use "finer grained" infrastructure specification than IaC, but if anything, that's the opposite of what they do. By abstracting things into broader chunks of multiple pieces of infrastructure, they are by definition working with "coarser grained" infrastructure. Anyway, as folks here point out, the movement towards highly specific components rather than actual code for building cloud-hosted services just trades one set of problems (scaling; dealing with VMs; having sysadmins) for another (business logic spread out over dozens of individual "components"; impossibility of rapid testing and troubleshooting; requires massive supporting observability infrastructure to make sense of).

lgkk 3y ago

Serverless is fine. I always find that people try to shoehorn everything into something trendy for no reason. Like I use serverless for a handful of async tasks that can run in background. Common things like image resizing, processing data to make metadata tags or something, or some things that I would have originally used Kafka for. With serverless especially if I’m already on aws for example I have access to the whole ecosystem. Once something completes it can just write data to some store. Done. I don’t need to lose my sanity fixing Kafka event failures and other bs. Core logic goes into monoliths or services. Anything that can be offloaded that’s an atomic operation goes to serverless from either mono or service.