This is more of a question to @rauchg and others who have used now one. When I use now within the AWS realm, are the AWS services when used in conjunction with Zeit Now containers subjected to ingress/egress costs? As it does sound like I am using a different cloud as far as AWS is concerned
Serverless Docker Beta
191–200 of 236 posts
Re: Serverless Docker Beta
#192Re: Serverless Docker Beta
#193Earlier quoted context omitted.
Frankly I blame the SQL DBs for the rise of NoSQL. They didn't move fast enough for this kind of environment, and stuff like Cassandra fit that need pretty well.
That's an divisive statement. I'd blame people who were unwilling to invest the time in properly modelling their data on the rise of NoSQL. Transactional consistency and data normalisation - pffft. SQL is still doing very well running things behind the scenes.
Talking about running things behind the scenes, mainframes with pre-SQL NoSQL DBs (ADABAS, IBM IMS) and even with no DBMS in a modern sense at all (running on TPF, working directly with Direct Access Storage Device records) are still doing very well.
Re: Serverless Docker Beta
#194Earlier quoted context omitted.
but how do you feed data in? Usually, it's some other service on one of the big 3 cloud providers. I'm using google for my projects these days so it's a mix of Google PubSub and Dataflow. I think this is the issue/risk with serverless. You either get locked into one of the big 3, or you end up doing all of the ops work to run your own stateful systems. As some of the people above you said, managing and scaling the st…
How does one get locked in when it’s a simple function in X language? Seriously, serverless is just an endpoint they provide. You write the code and they handle everything else.
Because the function is the stateless easy part. To make any non trivial system, in a serverless way, you have to use their proprietary stateful systems. IN my case, google pubsub, google data flow, google datastore, Spanner, etc. that’s where the lock in happens.
Re: Serverless Docker Beta
#195Re: Serverless Docker Beta
#196Re: Serverless Docker Beta
#197And so ZEIT, my favorite serverless provider, keeps getting better. Highlights: - "sub-second cold boot (full round trip) for most workloads" - HTTP/2.0 and websocket support - Tune CPU and memory usage, which means even smoother scaling And all that for any service you can fit in a Docker container - which is also how you get near-perfect dev/prod parity, an often overlooked issue with other serverless deployment te…
Where the fang devs mock come from? They are on the forefront of serverless.
Specifically AWS Lambda is. In terms of performance and flexibility AWS and GCP are far far behind.
Re: Serverless Docker Beta
#198Earlier quoted context omitted.
How does one get locked in when it’s a simple function in X language? Seriously, serverless is just an endpoint they provide. You write the code and they handle everything else.
Because the function is the stateless easy part. To make any non trivial system, in a serverless way, you have to use their proprietary stateful systems. IN my case, google pubsub, google data flow, google datastore, Spanner, etc. that’s where the lock in happens.
Right, because serverless is actually just a cover for "de-commoditizing" the cloud services that companies like AWS built to commoditize datacenters. You hit the nail on the head. It's not completely useless to help less technical people solve the problems that folks like you and I consider "the easy part" and so people will find a use for it.
But the primary utility of serverless is an attempt at solving Amazon's problem of being commoditized by containers.
Re: Serverless Docker Beta
#199Looks great for basic websites but it's missing the biggest and most difficult piece of cloud infrastructure. The DATABASE! Today you'd have to open up your cloud DB provider to the world since Zeit can't provide a list of IPs to whitelist. This is a showstopper for me unfortunately.
From what I've seen, when people talk about serverless there's 2 camps. Functions makes life easier camp. Serverless development and deployments have nicer properties which make them easier to reason about and eliminate entire classes of errors. Functions make edge computing possible camp. Serverless functions can be deployed in datacenters around the globe close to your users, offloading compute from your core and i…
Firestore has strong consistency transactions.
Re: Serverless Docker Beta
#200Earlier quoted context omitted.
From what I've seen, when people talk about serverless there's 2 camps. Functions makes life easier camp. Serverless development and deployments have nicer properties which make them easier to reason about and eliminate entire classes of errors. Functions make edge computing possible camp. Serverless functions can be deployed in datacenters around the globe close to your users, offloading compute from your core and i…
You can't decouple validation from the datastore if you want to be certain that all the validation happens and none is ever bypassed or outdated. It bugs me how many systems have opt-in correctness.
If you start with the intention of asynchronous, non-transactional eventual consistency as your assumptive design model, you'll realise:
1. Most applications don't need 100% correctness. Few people are writing nuclear reactor control systems, or bank account management software
2. This model frees you to up to compute at the edge more.
Is there a chance that you consider something valid that eventually wasn't? Yes. But in a single actor-per interaction system (e.g. an single actor mutating something, multiple people seeing effects, etc.), typical to the web, this is OK.
People know about CAP theorem but hang onto the C with dear life. Let it go. It makes everything easier. Honest.