111–120 of 137 posts
It doesn't solve all problems (tt isn't a CRUD framework) - but it does make the developer experience much better as compared to Amplify.
Earlier quoted context omitted.
I’d much rather write 20 lines of boilerplate code and a Dockerfile than deal with 100s lines of CDK code, distributed tracing, and the associated observability challenges.
Some frameworks used to support serverless applications are completely over-engineered cesspools, no doubt, but it doesn't have to be that way.
Earlier quoted context omitted.
Some frameworks used to support serverless applications are completely over-engineered cesspools, no doubt, but it doesn't have to be that way.
It has nothing to do with the framework if it's a web app you have to manage deploy of multiple lambdas and API gateway.
Serverless doesn't have to be over engineered-garbage, even if some bored technologists looking for a promotion and/or to pad their resume try their best to make it so.
they constantly try to escape from the complexity outside and within by dreaming of abstractions so perfect that no one will need to be good but the latency that is will shadow the "simple" that pretends to be
grug wonder why big brain take hardest problem, factoring system correctly, and introduce network call too seem very confusing to grug
Earlier quoted context omitted.
In python there is lithops, which provides nice Executor primitives that can run on a wide range of cloud services (AWS lambda, GCF etc.) https://github.com/lithops-cloud/lithops
Omg the Python code examples are center aligned. But it looks sweet
from lithops import FunctionExecutor
def hello(name):
return f'Hello {name}!'
with FunctionExecutor() as fexec:
f = fexec.call_async(hello, 'World')
print(f.result())
Without tooling to run a serverless service locally, this is always going to be a sticking point. This is fine for hobby projects where you can push to prod in order to test (which is what I've ended up doing) but if you want stronger safeguards, it's a real problem.
Earlier quoted context omitted.
I'm from even before that, and it makes no sense to me. I understand both what you say and what "serverless" commonly means, I'm just saying it's essentially arbitrary. A symbol with no etymology that holds water.
All words are arbitrary, but how does it not make sense? "Server" is a well understood term in software. "Less a X" is well understood in English to mean something akin to "without X", or "not having X". Serverless is short for "less a server", which succinctly indicates exactly what it is: The application is without a server. Which is a shift in how these types of applications are written, as since the mid-2000s it…
This might be why people are having trouble with it. "Cloud" and "serverless" both refer to hardware, not software.
"Cloud" was moving the hardware from something you managed, either in office or a datacenter, to using machines someone else managed, but it was still server-oriented (such as software in VMs or bare-metal that you managed).
"Serverless" drops even that, using ephemeral code that doesn't care what server it's running on, so the people managing the hardware can move your software as-needed.
Serverless doesn’t mean no-server. It means someone else’s server. Their system. Their rules. Their way or the highway. No thank you.
I hate the term "serverless". It's a misnomer to the extent that it feels like it was designed to deliberately mislead. Even vague consultant-speak like "externally provisioned infrastructure" would feel more accurate.
Back when the hype was virtualization (so probably mid-2000s, before my time at the company), a big project was run to try moving to virtual machines. After the research phase had been deemed a success, they were gearing up to go into production and put in a hardware order. This was supposedly rejected by an executive who complained that they should not need physical servers if they do everything on virtual machines now.
Earlier quoted context omitted.
All words are arbitrary, but how does it not make sense? "Server" is a well understood term in software. "Less a X" is well understood in English to mean something akin to "without X", or "not having X". Serverless is short for "less a server", which succinctly indicates exactly what it is: The application is without a server. Which is a shift in how these types of applications are written, as since the mid-2000s it…
> "Server" is a well understood term in software. This might be why people are having trouble with it. "Cloud" and "serverless" both refer to hardware, not software. "Cloud" was moving the hardware from something you managed, either in office or a datacenter, to using machines someone else managed, but it was still server-oriented (such as software in VMs or bare-metal that you managed). "Serverless" drops even that,…
Not really. "Cloud" refers to a software abstraction that tries to hide the existence of actual hardware namely to remove dependence on the availability of any specific hardware component (like, as in, being able to transparently move to another physical machine without the user ever knowing). It is clearly a software term. I can't go down to my local Walmart and buy a "Cloud". Amazon won't ship a "Cloud" to my place. There is nothing "hard" implied by the word as used in this context. I'll grant you that it more or less maintains some kind of "virtual" hardware concept. Perhaps that is what you mean?
There is no hardware association with "serverless". It refers to a pattern for developing a certain breed of applications that resemble servers, but without the server. "Server" is definitively a software term as used here. A server is an application that listens for requests from a client, typically on a network port if we are to dive into implementation territory, but could be something else like a unix domain socket. Much like CGI of yore, these "serverless" applications shed the server, relying on the runtime environment to fill in the missing pieces.