What about installation and updating/patching? Or is the intention here to still serve this package of web code, db, etc over the net (via cdn maybe), and then execute locally?
If people want updates they can download them on purpose.
What if serverless meant no backend servers?
11–20 of 138 posts
Re: What if serverless meant no backend servers?
#12Like, just … a program?
Re: What if serverless meant no backend servers?
#13Re: What if serverless meant no backend servers?
#14I wonder if there's some legal way of saying, "the web is critical communication infrastructure and all core comms devices need to support X standards"
Re: What if serverless meant no backend servers?
#15Re: What if serverless meant no backend servers?
#16Re: What if serverless meant no backend servers?
#17What we need is updates that only include security patches.... FEATURE CHANGES SHOULD BE OPTIONAL. Because all software tend to decrease in quality overtime.
Re: What if serverless meant no backend servers?
#18Re: What if serverless meant no backend servers?
#19I go to fairly great lengths to do everything in the browser to avoid having to support any backends (for the tools, etc. I make; & hobby project gamedev). It would be a great thing if (perhaps legislation) could break the app-store model, then fully-fledged apps could be distributed as web sites (with their own localstorage, etc.) I wonder if there's some legal way of saying, "the web is critical communication infra…
standards are great but how can I guarantee 200x YoY return for investors? sounds like an unnecessary capx...
Re: What if serverless meant no backend servers?
#20On one hand, if I were to have the goal to make a bunch of money, and software just happens to be the means to an end, making a gated software portal where I control everything would suit me very well. You get nothing until I get the money, and I only maintain what I want to maintain. (pretty much the model every SaaS has)
On the other hand, if I know I have a very small customer base, and everyone is making a lot of money or because of my program, and I don't really care that much about the money above a certain number, I might as well distribute it as a static/stale build. You get a binary, or a virtual machine or something like that, and it just does everything. Maybe if piracy were a concern I would add some sort of hardware dongle, but I would also be aware that it's going to get cracked anyway and the only people that are annoyed/limited by it would be my actual paying customers.
On the other more different hand (third hand?): if my program has requirements about robustness, locality or longevity, I would make sure it depends on as few things as possible, make sure that it's documented well enough for future users and administrators to run it on future environments, and perhaps not sell the software in itself as much as I'd sell support. The risk and downside is that specialised and unique software tends to be quite annoying and costly to create while there isn't a lot of telemetry or feedback to figure out what's working well and what isn't, so that would drive up the price significantly. I'd say you're looking at two orders of magnitude vs. a SaaS thing.