451–460 of 670 posts
I get to deploy stuff "the regular way", that is with a constantly running application, I don't have to re-train my developers, I have extra power in the cluster should I need it, I don't depend on a cloud provider in particular, and my costs are bounded.
Cherry on top: I don't maintain the infrastructure either, there isn't even a SSH daemon running.
This advantage: “Serverless models don’t require users to maintain their own operating systems, or even to build applications that are compatible with particular OSs. Instead, developers can produce generic code, and then upload it to the serverless framework, and watch it run.” ... is utterly compelling and is why serverless will not just win, but leave renting a server a tiny niche market that few developers will h…
> Maintaining your own server is completely nuts. If that isn’t obvious now, it will be in another decade. It’s massively inefficient. Like running your own power plant to serve your factory, except you also have to worry about security and constant maintenance, along with all the moving parts that surround a server. Except that it is not. The security and constant maintenance is needed but it is worth in many cases.…
For the past 20 years you have been able to target x86 gnu/linux and have it running without modification on a readily available server, either your own hardware or rented/public cloud. How does switching from one binary format to another (x86 to WASM) change anything (except maybe slowing down your code)? As I understand it, the main draw of WASM is running non-JS code in a web browser.
This advantage: “Serverless models don’t require users to maintain their own operating systems, or even to build applications that are compatible with particular OSs. Instead, developers can produce generic code, and then upload it to the serverless framework, and watch it run.” ... is utterly compelling and is why serverless will not just win, but leave renting a server a tiny niche market that few developers will h…
It's not nuts to run servers. If an application is operating at any scale such that there is a nonstop stream of requests, then it will be cheaper, faster, and more energy-efficient to run a hot server. This follows from thermodynamics. No matter how good the cloud vendor's serverless is, it's always going to be less efficient than a server, unless it doesn't do any setup and teardown (i.e. no longer server less ). I…
You seem to implying only applications with huge numbers of users can be profitable. This statement ignores a tremendous amount of (typically B2B) applications that provide enormous value for their users but don't see a lot of traffic.
I have worked on applications that are at the core of profitable businesses yet they can go days, in some cases weeks without any usage. Serverless architecture will be a real benefit there once it matures.
Earlier quoted context omitted.
Yeah, I took a look at using a serverless framework for a hobby project, and it was just a real pain to get started at all, let alone develop a whole application in. I tried AWS, and then IBM's offering which is based on an open source (Apache OpenWhisk) project, thinking that it might be easier to work with, but that was also a pain. I just lost interest as I was only checking it out. For something constantly market…
> Yeah, I took a look at using a serverless framework for a hobby project, and it was just a real pain to get started at all, let alone develop a whole application in. Look into Firebase functions. Drop some JS in a folder, export them from an index.js file and you have yourself some endpoints. > exports.helloWorld = functions.https.onRequest((request, response) => { response.send("Hello from Firebase!"); }); The amo…
If this was a standard service the standard service would have became overloaded very quickly, allowing the database to remain up but at a degraded performance and the only service that would have been down would have been the one that was getting too many queries. Instead, everything was effected.
I've came to the realisation that if your lambda requires something else to operate, lambda is probably not a good solution.
Kind of surprised the article didn't mention lack of reasonable development environment. At least on AWS, the "SAM" experience has been probably the worst development experience I've ever had in ~20 years of web development. It's so slow (iteration speed) and you need to jump through a billion hoops of complexity all over the place. Even dealing with something as simple as loading environment variables for both local…
> It's so slow (iteration speed) and you need to jump through a billion hoops of complexity all over the place. Even dealing with something as simple as loading environment variables for both local and "real" function invokes required way too much effort. Honestly, it reminds me of PHP development years ago: running it locally sucked, so you need to upload it to the server and test your work. It. Sucked.
This advantage: “Serverless models don’t require users to maintain their own operating systems, or even to build applications that are compatible with particular OSs. Instead, developers can produce generic code, and then upload it to the serverless framework, and watch it run.” ... is utterly compelling and is why serverless will not just win, but leave renting a server a tiny niche market that few developers will h…
I've in this area professionally for some time now, and I've never "maintained" servers in any reasonable sense. There are kernel people who maintain the kernel and there are Debian devs who maintain the operating system. The server may be mine (but more often that not, it isn't) but only in very specific circumstances do I ever concern myself with maintaining any part of this stack.
A vanilla Linux VM is a platform to build on. Just like AWS or anything else. It is the environment in which my software runs.
Thus far, something like Debian has been more stable and much less of a moving target than any proprietary platform has been, cloud or non-cloud. Should a client wish to minimize maintenance costs of the software over the coming decade, it is most cost effective to not depend on specialized, proprietary, platform components.
That may change in the future, but right now there is no indication that is the case.
Earlier quoted context omitted.
> developers can produce generic code There is nothing generic about the code that runs on serverless services. It’s the ultimate lock in.
At the moment. Is there anything stopping an organisation from defining some standard types of serverless environments? Is there anything stopping someone from turning that standard into implementations to help cloud providers offer it, or even be a fallback option that could be deployed on any generic cloud infrastructure? I think those are the way forward from here.
This advantage: “Serverless models don’t require users to maintain their own operating systems, or even to build applications that are compatible with particular OSs. Instead, developers can produce generic code, and then upload it to the serverless framework, and watch it run.” ... is utterly compelling and is why serverless will not just win, but leave renting a server a tiny niche market that few developers will h…
As an experienced back-end developer and linux user I would pull my hair out if I was completely helpless in fixing an issue or implementing some side thing that requires shell access. I don't want to wait for some guy in Philippines who will be online 12 hours later to come try to fix it.
pbBouncer[0] in transaction mode tries to solve the problem of limited connections by giving a connection from the pool to a transaction. This has a limitation of not being able to reuse statements; e.g. they have to be deleted before the transaction is released, adding an extra roundtrip for the queries. It also means you must wrap every request into a transaction, if planning to use statements. Otherwise the solution is to sanitize all your values and concatenate a single SQL query. It has the big risks of SQL injections and is against all best practices, but this is what Active Record is doing to solve the issue, and I guess it works for them quite well.
pgBouncer has also the statement mode. Here you can't use transactions and with that, no prepared statements either. So you must then just use the text protocol of the database and concatenate the parameters to your query.
Amazon has the RDS, and I haven't looked into it that much yet. What I kind of think I know about it, is it pins the connections when using statements. Meaning, when pinned, the connection is for one client and cannot be reused until disconnected.
MySQL has the serverless-mysql package[1], which is a client side library killing of stale connections and disconnecting as fast as possible when done. So, basically during the request, it reads the system tables and tries to drop the connections from other sessions. I haven't tried this either, but more I think about it, it really doesn't feel like a good strategy at all. For one, you need a root access to the database for every client, and then you need to modify the state of other connections from the clients. There could be a bug in the client library, that is quite nasty to find and can cause really hard-to-fix issues.
Then the last thing is of course the locking of traditional relational databases. They don't scale to massive concurrency that well; the MVCC chokes when running with many parallel queries[2]. So you need a distributed system, something that can have locking mechanisms that can scale to tens of thousands of sudden connections when the serverless system gets a request peak. Hopefully something with a stateless connection. If somebody knows a system that can do this, I'd like to hear about it.
[0]: https://www.pgbouncer.org/
[1]: https://www.npmjs.com/package/serverless-mysql
[2]: https://15721.courses.cs.cmu.edu/spring2019/papers/02-transa...