121–130 of 137 posts
Earlier quoted context omitted.
How much do your data centers cost to build roughly? How do you get global bandwidth with out peering?
How much would a VPS or a rented server cost where you can boot your own OS and be the sole tenant of the SSD and don't fight with the IOPS of the other videoconverting dude using the same machine?
Earlier quoted context omitted.
It does look like it! Personally I'm off the k8s train and don't currently have a use-case but best of luck! feedback: why make a clear distinction between "magic node" and "BYON"? Two new concepts to learn when I feel a value-prop for some users would be to not have think about these distinctions? (Just talking about wording and communication here - can you get the value prop across with less reification?)
Thanks for the feedback! I’ve been thinking about the wording too—and you might be right, perhaps highlighting the Magic Node as the mainstay vs BYON being a smaller, side feature might help sell the main value prop. I’ll try clearing that up! Thanks again!
"Managed node" and "self-hosted nodes" are examples of more familiar concepts you can utilize to communicate.
- Serverless can get very expensive - DevEx is less than stellar, can't run a debugger - Vendor lock-in - You might be forced to update when they stop supporting older runtime versions
Earlier quoted context omitted.
Thanks for the feedback! I’ve been thinking about the wording too—and you might be right, perhaps highlighting the Magic Node as the mainstay vs BYON being a smaller, side feature might help sell the main value prop. I’ll try clearing that up! Thanks again!
Cheers! What I meant was : Skip even naming/introducing the two words/concepts at all. "Managed node" and "self-hosted nodes" are examples of more familiar concepts you can utilize to communicate.
This misses the main factor, I think: Vendor lock-in. There is no unification of APIs - every provider has their own bespoke abstractions typically requiring heavy integration into further vendor-specific services - moreso if you are to leverage USPs. Testing and reproducing locally is usually a pipe-dream (or take significantly more effort than the production deploy). Migrating to a different cloud usually requires…
What started was the rebranding from distributed systems.
We have had Sun RPC (The network is the computer, a slogan now owned by Cloudflare), DCE, CORBA, DCOM, RMI, Jini, .NET Remoting, SOAP, XML-RPC, JSON-RPC,....
Client-Server, N-Tier Architecture, SOA, WebServices,...
Apparently the new trend is Microservices-based, API-first, Cloud-native, and Headless with SaaS products, aka MACH.
Earlier quoted context omitted.
> "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,…
> "Cloud" and "serverless" both refer to hardware, not software. 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 W…
You are describing a thing that is not a foo, or does not do foo, not a thing that posesses no foo.
So, I say, this is just something you're saying and not a definition I ever heard or would have implied from context from others usage. And it's not a new term by now, so there has been several years for me to have gained this impression or understanding if anyone else were using it that way.
Earlier quoted context omitted.
Serverless is more of a billing philosophy than a design philosophy in my opinion. Serverless is all about outsourcing the infrastructure for scaling a micro service. How you design the service itself, or the system its a part of, can vary widely. There are definitely dedign constraints of going serverless, but I'd argue those are largely just the constraints of going with microservices rather than a monolith.
> Serverless is all about outsourcing the infrastructure for scaling a micro service. Technically, it is all about removing the server from your application. The name literally tells you so. It is true that removing the server can offer some benefits in the scaling realm. In particular, it allows you to scale to 0 now that you no longer have to keep the process alive to serve requests. Of course, that is not tradeoff…
Technically its about removing the server from my list of responsibilities. There is still a server running my app, it just isn't managed by me and likely comes with auto-scaling features.
Earlier quoted context omitted.
> "Cloud" and "serverless" both refer to hardware, not software. 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 W…
This doesn't make sense to me because "fooless" means "lacks foo" You are describing a thing that is not a foo, or does not do foo, not a thing that posesses no foo. So, I say, this is just something you're saying and not a definition I ever heard or would have implied from context from others usage. And it's not a new term by now, so there has been several years for me to have gained this impression or understanding…
Exactly. "Serverless" lacks a server. Which, granted, wouldn't make sense with no context, but when you remember that the same types of applications were previously written to include a server and no longer include a server when written in a "serverless" fashion, that is exactly where the differentiation is found. It literally describes what it is.
> And it's not a new term by now, so there has been several years for me to have gained this impression or understanding
I have never, ever, seen "serverless" refer to anything else outside of the previous commenter who thinks it has something to do with hardware. But it clearly has nothing to do with hardware. There aren't warehouses full of "serverlesses" ready to be loaded onto trucks. It is not something physical. It is not in any way "hard", that much is obvious. It is undeniably a software term. So, what, exactly, is your impression?
I still find the DevEx of serverless terrible compared to the well-established monolith frameworks available to us. The YAML config, IAM permissions, generating requests and responses, it's all so painful to get anything done. Admittedly I speak as a software engineer primarily building CRUD apps, where frameworks have had decades of development. I can see use cases for event-driven applications where serverless may…
I find serverless to be a breeze, with zero sysadmin costs compared to setting up VPS, EC2, doing your own custom monitoring, etc. Each to their own, however. And gateway+lambda is a near perfect "dumb crud" app, though it is not without a startup cost.
If you need RDS for example you need the VPS.
It only looks good on the outside.