5 ms·
IMO, deciding to go “serverless” or not usually ends up with about the same amount of work as far as writing code and configuration goes. Things like “serverle
by alexkavon 7y ago
IMO, deciding to go “serverless” or not usually ends up with about the same amount of work as far as writing code and configuration goes.
Things like “serverless” or firebase data stores or even html hybrid app frameworks, for example, are designed more so for simple proof of concept apps. As soon as you begin any sort of serious pipeline development, deep configuration for special case, scaling, etc. you’ll find these easy to use services and ideas limit your control overall. Vendor lock-in is just a benefit of “configuration-free” systems which is a side effect of people not willing to rtfm.
- ryanmarsh 7y agoServerless guy here. You’re on the right track. I’d just add that it’s more about ops burden than anything else. iRobot is a $3bn market cap company with 23 million robots in the wild. Their entire IT estate for managing 23 million robots including the communication and systems is $15k a month. They can see their costs down to the function, they can see where every cent is spent and they do this with 10 engineers, 8 of which are in development, 2 in Ops. shrug
- alexkavon 7y agoUntil a rearchitecture is needed. Then you’ll either need all your developers in ops or vice versa. (Assuming your response implies iRobot uses serverless)
- nilkn 7y agoI view these serverless cloud offerings as more of a business/staffing decision than an engineering one. It may not be less work overall, but it tends to outsource traditional ops work and replace it with work that ordinary developers can do. Instead of having an extensive in-house ops staff to support your development team, you can have a much smaller ops staff and grow your development team more quickly.