3 ms·
OK well here's the sort of ops work that serverless kinda absolves you of: - making sure you don't run out of inodes - having to manage DB backups - making s
by rtpg 9y ago
OK well here's the sort of ops work that serverless kinda absolves you of:
- making sure you don't run out of inodes
- having to manage DB backups
- making sure your cache didn't stop working
- updating your box for security updates (beyond just your application requirements)
It's a tradeoff (architecturally as well), and for a lot of stuff you'll end up wanting full-ish control of your box. But for getting the ball rolling it's nice to not have to first spend a bunch of time getting postgres to start consistently on boot.
You still have to actually manage deploys themselves, of course. And keep an eye on costs, too. But a lot of these services are getting close to "the code that you are running locally, but in the cloud". A far cry from "OK, first lets get apache up, then set up some proxy servers, then set up supervisor" etc etc.
- kogepathic 9y ago> OK well here's the sort of ops work that serverless kinda absolves you of I wasn't trying to list every bit of ops work for server/serverless. My point is that as a business you cannot expect that once you move to serverless you don't need anyone to manage it anymore, or that the time to manage it drops to zero. Yes, serverless does have its distinct advantages over rolling your own, there is no question about that. But serverless still requires experienced people to configure/manage/monitor it. I've seen way too many managers get giddy at the thought of having their developer/ops time completely free to perform other tasks, and that's not the case. You still have to budget for people and time to manage serverless architecture.