Serverless by AWS standards doesn’t mean “stateless”"
Willing to be proved wrong, but what I've seen so far does equate serverless with stateless, at least at the compute tier. Aurora has no "Lambda" or "serverless" branding, right? Any stateful stuff is sort of called out as an integration.
Not sure I get the difference. This is sort of the core issue. At some point, some service is stateful. Why all the hoopla and nuance around naming? What, exactly, is new from the 1960's on? Stateful and stateless is as old as computing.
It’s not the data it’s the compute. In the 60s, you couldn’t just bring in an IBM mainframe when you needed it and not pay for it when you didn’t based on the server load.
With regular Aurora, whether you are using it or not, you’re always paying for both the server and the storage and you have to provision the server for peak workload. With Aurora Serverless, if you don’t connect to the database, you only pay for storage.
With lambda and to a lesser extent Fargate, you don’t pay for the underlying server at all until you actually need to run something and then with lambda you can scale up to as many instances as your account allows (a soft limit you can ask for more anytime) and pay nothing when you don’t.
With EC2 you have a server sitting there listening for events whether or not anything is sending you an event.
Interesting example. Mainframes were one of the first to deploy lots of capacity to your data center floor you hadn't yet paid for. Upgrades were often just a phone call and a remote (often, zero down time) re-config.
Willing to be proved wrong, but what I've seen so far does equate serverless with stateless, at least at the compute tier. Aurora has no "Lambda" or "serverless" branding, right? Any stateful stuff is sort of called out as an integration.