(1) "Behind the scenes, Now 2.0 works like an extensible build system and compiler, capable of transforming your sources into static files and serverless functions (lambdas) for production."
The demo is pretty slick. I've seen other frameworks, like Begin.com, where your lambdas are more explicit, but I'm curious to try this autogenerated approach.
(2) "The Now 2.0 platform features include:
A unified deployment type: All deployments are one type, regardless of static or dynamic parts
Massive build parallelization: Each deployment can kick off many concurrent serverless builds.
Monorepo support: Define API endpoints in Go, PHP, Node.js, Next.js, and such, in just one repository.
Zero-instruction builds: Our open-source builders take the build and cache config burden away.
Universal Cloud: Our platform leverages the best cloud infrastructure, with no lock-in or config.
With the following pricing improvements: Fully on-demand pricing, Per-100ms pricing for compute, Free seats for small teams
Including a better free-tier for our community."
It feels like all the Zeit features are coming together for a more complete offering. I love it.
Auto-generation is a great way to put it. Cloud functions are an incredible primitive, but in our view, they constitute primarily a compilation target.
Some small adjustments will be necessary when _importing_ large legacy codebases, but that's where using functions to also build your project comes in!
Can anyone offer an explanation of how this impacts docker based deploys? Since the serverless docker announcement in August I've been hoping to move off of DO to now but it sounds like that won't be possible with a 5mb cap...?
The limits are there specifically to help in that transition, to avoid the problem described in the chart. They're a crucial learning extracted from the beta we ran.
Like I understand the benefits of lambdas/serverless. But they aren't sufficient for all use cases. The ability to have an endpoint for a docker container with one command is extremely useful. There already a lot of serverless options on the market too... maybe I'm confused...
I'm in the same boat. I've spent a lot of time getting my company's deployments set-up on Now's Docker offering (which was awesome). I'm not looking for my app to be serverless. And I'm also not looking for a "Majestic Monorepo".
NOTE: v1 is fully maintained and supported. We will only announce a deprecation date once we have ensured all our customers workloads are migrated and the tooling is in place for a smooth transition.[0]
Based on that, it seems to me like I will have to migrate to Now 2.0 eventually.
One of the major pain-points I've hit with this concept of a "Monorepo" is tooling support since many things are built on the premise of separate repos for each code base. Pain points: Git+Github issues, CircleCI, etc. How do you handle those problems?
I place high value on simplicity and portability so despite not being fully optimal a monolithic docker app is a good choice for me.
The reason I'm still on DO is because I need dependencies that are both large and trivial to install in docker vs. creating a custom EC2 image. To make it clear I was hoping to deploy a docker container with ffmpeg to support long running video conversions whilst benefiting from easy deploys and on demand pricing. It seems like the potential for this alluded to in the serverless docker announcement has been removed?
I can see how this V2 makes serverless simpler but the strict limits will mean that transitioning a monolithic app requires a lot of work up front. Increasing the limits would reduce that friction greatly. Whilst not best practice deploying an existing express app and have it 'just work' is a compelling reason to go serverless.
Are there any public plans for early access or an ETA to GA for features like scheduled jobs? That's very important to me, and since daemons aren't on v2, there's currently no way to do them internally to Now (I suppose you could have an external cron system GET/POST a URL every N minutes).
Congrats on the launch, it looks like a much more cohesive product now!
I actually run a cron job (https://www.npmjs.com/package/node-cron) on Now by setting the minimal scale to 1 instance. It's for a hobby project but it's been reliable enough for my personal needs.
The only tough part is having to delete the old cron instances when I push an update. Scheduled jobs (or some cron support) would be excellent.
Apologies for sneaking into this thread. You can schedule batch jobs using Apify Actors and Scheduler. The actor can run any Docker image at times specified using a cron expression. Just have a look at:
When they say "server-less" do they mean building apps with local data and nothing goes to the company, or do they mean the server aspect is all taken care of by them? I'm not the most advanced person and would really like to know more.
"Serverless" is a marketing buzzword. It does not mean there's no server; it means that you don't have to manually provision a dedicated machine or machines to run your code. Instead, you provide some code (a "lambda") to your cloud provider that they will run when an HTTP(S) request comes in.
There is still a cloud provider which is manifestly a server; that's why this buzzword is stupid.
To me, the biggest things are the pricing improvements, including the changes to the free tier. This will make it much easier for small teams to go from concept to deployment without having to worry about exposing their source code or ending up with a huge bill. Thank you all for your hard work!
Can't help but say that "Now 2.0" is one of the coolest headlines possible. (The scope of the article is, of course, a bit narrower than a new major release of the current reality.)
Can `Now` serve as the backend for latency sensitive endpoints? My main problem with AWS Lambda a couple few years ago was the latency.
In a dumb function, imagine a single K/V lookup, is * < 10ms response time a possibility?
Guillermo and his team are focused on developer experience first and foremost; the zero -> “hello world” in any language they support is ridiculously quick and painless.
If this is hosting front-end files for me, and is "serverless", how do I hook up my db, or deal with the filesystem, etc.? Or is this only for static sites?
As far as we are aware, no one until today had solved the problem of compiling to serverless functions.
If you look at the solutions out there, they all involve you dealing with low-level APIs or config that have little to do with how you write most apps and frameworks in mainstream programming languages.
I was considering investigating Now/Zeit as a possible evolution over our current stack. Having seen this announcement I'm not so sure that is still a good idea. Now 2 is a completely different beast to Now 1. The very last thing we need is churn in our servers/infrastructure rivalling our frontend. Is Now 3 going to be [dramatically improving the reliability and scalability of -our- deployments] yet again?
Keep in mind that the the intelligence that goes into the builders (which are OSS, which you can write your own of) is specifically around not making code changes.
Surely, some code changes are necessary to go serverless (when considering legacy servers and apps), but our goal is to always minimize that.
I second that. Long-running docker containers are more beneficial in many use-cases. Now 1.0 was the closest thing I found to Azure Container Instances and AWS Fargate
Now offering 1.0 style deployments on an ongoing basis will be helpful.
This is something that is only necessary for legacy databases. Modern database providers give you gateways that deal with a huge number of connections with no issues.
You can imagine the issue being that serverless is a stateless workload, and connection pooling is, well, stateful. Your db itself would ideally be the thing to solve that problem (its already the state-management system), but if it doesn’t, you’ll need to introduce something new to handle that state.
The problem also ofc already exists when you have multiple applications (or instances) trying to talk to your db (which is why pgbouncer exists regardless of serverless), and serverless doesn’t differentiate between 1 and 1000 instances (which is why its trivially scalable).
And ofc if you werent going to need sufficient scale to require something like pgbouncer... should you even be transitioning to serverless? You could replicate the same stateless organization style on your own, on a single server.
Or, you could run it on the same server that you're running your database on.
If you're not running the database server yourself, is it so unimaginable that the service provider might have already configured PgBouncer on top of the database as an optional way to interface with it?
Regardless, "serverless" has never meant that there are no servers involved, it just means that for the serverless pieces of your application, you don't have to concern yourself with where or how they're run, only with the application logic itself.
If you want to go 100% serverless, then you're obviously going to have to choose a DBaaS that works with your connection pooling strategy, especially if that strategy is "I don't have one." Supposedly, based on comments on this thread, DynamoDB works pretty well for that scenario. Obviously Postgres doesn't scale with an increasing number of connections very well, which is why PgBouncer exists, and it works well.
Finally, PgBouncer is relatively stateless. Its main pieces of state are a static config file and the pool of open connections it holds. This could be deployed in a serverless fashion, and any time it is destroyed or recreated, it would be trivially reinitialized just from the config. It doesn't have to have any attached, mutable storage.
> If you're not running the database server yourself, is it so unimaginable that the service provider might have already configured PgBouncer on top of the database as an optional way to interface with it?
Are you familiar with any providers that offer this configuration? In my experience, at least AWS does not.
That depends on the provider and the database. For AWS Lambda with DynamoDB connection pooling is handled "behind the scenes", and you don't have to worry about it. AWS supports SQL databases as well, I would assume it also is pooled for you.
NOW currently doesn't have databases and tells you to use cloud DBs. So more than likely the connection is dropped when the lambda shuts down.
But if you'll let me go a little bit meta, the idea of serverless is that you shouldn't even be thinking about things like connection pooling. If you just use the databases that your provide supports those types of concerns are their concerns now, not yours.
In other words, if you want to pick your own tech stack then serverless is not for you (yet). If you're willing to surrender your opinions and just use what the platform provides you (if you're using AWS just use DynamoDB) then you can stop thinking about these problems and focus on your business logic.
Thank you for the detailed answer! That makes sense. Although I still find it strange... Now markets itself as preventing lock-in because it can deploy to any cloud, but to realistically use any database with it you have to lock yourself in to one of the cloud providers?
To expand upon the previous answer. Connection pools are still a problem.
Even if your lambda drops a connection after it destroys itself, a sudden influx of visitors to your site may spawn enough lambda processes to overload your DB.
What happens then is dependent on the database, but generally means that new lambdas do not get to connect.
Anyhow, you don’t really want your database to magically more around regardless, so you’d be sort-of locked in to one service regardless of what you do.
But postgres on one service is pretty much the same as on another, so if you wanted to migrate it would be fairly easy.
What the parent comment is correctly saying is that for certain databases (that are oriented around stateful connections) you might benefit from a infrastructure-level optimization.
However, this is not the case for all databases. Furthermore, modern database vendors are extremely motivated to address the serverless usecase
Yup I eventually found that. Not for static websites and things but still really cool. I wonder if your app writes to std out would that be a way to format logs yourself?
I have a question (I've tinkered with Serverless stuff but never on a production app) but my underlying assumption might be wrong.
I like that the cold boot up performance for a single function is super fast when compared to a "Legacy Server". But after the legacy server is up it "stays warm" regardless of user activity. Unlike a lambda function which goes cold after a few minutes of inactivity.
So the first user that hits an endpoint after some inactivity has to wait (a few seconds) for the lambda function to cold boot vs. being served immediately on the legacy server.
Is my assumption here true? Or are cold boots on lambda super fast now? When I was doing this stuff ~8 months ago it would take like 5+ seconds to be served after a cold boot.
You're right, they're slow. All the major providers are working on ways to speed up boot, and some users just send requests every few minutes to keep the functions warm.
The cold start times have been quietly getting better over time on AWS Lambda. I just checked some python Functions and I'm seeing cold starts take around 80ms on average for a simple function.
Hopefully they have a solution for connecting to RDS from Lambda without incurring the huge cold start time and other problems of having the Lambda inside the VPC. Ideally it would be something like PgBouncer with a security group that only allows connections from your Lambda instances.
GCP has a semi-hacky solution that provides the ability to connect to your managed dbs from your Cloud Functions; one would hope that AWS can at least match that soon.
Servers will also eventually go cold, unless you pay for them 24x7.
With the Now 2.0 design, you instead are very likely to not suffer from cold instantiation to begin with, due to the healthy constraints imposed by the system.
In other words, instead of ignoring cold boots, you just want to embrace them and make them minimal to begin with.
I'd really like to see now supports non-HTTP deployments. That would be a killer feature. There's currently no raw TCP hosted solution offered, period. now could position themselves as the first mover there. The now interface is already amazing and a total joy to use.
I have been a paid customer of Zeit for a while and have really loved their products thus far. But v2 is making me reconsider my plans. The other day, I tried to scale an existing app to an additional region and I promptly found out that Node apps are not supported in their newer regions, such as GRU. The new regions only support v2 and can't even run a Hello World without Docker, which is completely stupid. I'm not going to add any bloat to my app just to use those regions. And even if I did, I wouldn't want to go "serverless" any time soon, given the much more mature and robust ecosystem for traditional server frameworks. Lots of things around serverless are still being figured out. Yes, it is totally doable to run some things that way in production, but it's not yet what I would personally choose for most of my apps.
If I'm not mistaken, V1 just takes normal Node apps and wraps them in a Docker container. At least, that's how they handle deploying to platforms outside of Zeit such as AWS. V2 just makes that process explicit and normalized across all languages/frameworks
I believe you are correct that v1 uses Docker behind the scenes. And that's fine with me so long as it doesn't infect my project, which hasn't been a problem until now. The beauty of Zeit's v1 platform was precisely that it would take my code and run it smoothly with no fancy configuration or modifications. It Just Works. I generally prefer explicit behavior, but this is a case where the behavior is not something I want to know or care about. My app should run on any common platform without special configuration or modification. And it does, everywhere... except on Now v2. I wanted to like it, but the desire is just not there. Maybe I'll keep using them for DNS but host elsewhere. Zeit's command line experience is top notch and I'd like to keep that aspect where I can.
Docker's pretty great, I recommend at least trying to put a simple container around your app, if that'll get you onto v2. It's probably a lot easier than migrating your whole app off of their platform.
Also, look at it from their perspective. They support everything when they support Docker, no need to have specific tooling for Node.JS.
I have no use for Docker. It's literally just an extra layer that does nothing useful for me. npm starts the server and I'm good to go: npm start for production, npm run start-local to run with a local database. Keep It Simple, Stupid. I see so many people using Docker as their scripting file, even though it actually adds complexity. I have no problem with it existing for those who need it, but most apps absolutely do not benefit from it. In fact, I've occasionally had to write code to handle Docker containers in a special way... completely defeats the purpose of normalizing the environment.
I ran that exact command a few weeks ago and it tried to scale my existing app to GRU (which is what I want!) and it immediately threw an error saying that GRU requires the v2 Docker serverless crap. Not gonna happen! Maybe it's ignoring GRU now, but that just leaves me without a region that I wanted...
I have been using Now in production for about a year. I fell in love with the version 1 product because it lived up to the mission, which I think went something like: make deployments as easy as using an iphone, or something like that.
I trust the leadership at Zeit are making the right decisions technically, but as the company grows, it also seems to get further away from its original mission.
The swift deprecation of previous versions is threatening to undermine any resemblance to the mission, if ease of use is still the mission.
The React team got this so right with the release of hooks in 16.7. Dan couldn't have been any more right on the money in his delivery, which was laden with promises of no breaking changes and "don't feel like you have to rewrite anything."
When Zeit released cloud v2, about three months ago, they made v2 the default, which broke many development workflows and required me personally to spend three full days refactoring code and resolving Docker issues due to an obscure error that Zeit support had trouble identifying. The breaking change was a shock and a surprise. The explanation? You should be doing things this way anyway.
Perhaps that was true, but maybe not.
After going through all the trouble of converting to cloud v2, I reverted to cloud v1 because I could not set the min instances in cloud v2, to eliminate cold boot as an issue. Someone on this thread said cold boot is 200ms. That may be true for a particular application, but I received so many customer complaints about slow boots (5 seconds or more), I had to revert. Reverting has solved the issue.
As of today, I have a deprecation warning when I log into Now which says `Your account is using a legacy platform version. We highly recommend upgrading.` Or what? Are you going to make my unmutable application mutable?
This announcement about Now v2 is confusing, first of all because Zeit already released cloud v2. How are the versions related? Next, serverless may be the future of everything, or it may not work for some existing environments. The jury is out.
To someone at Zeit, please watch the React Hooks Intro video, and the parts of Dan Abraham and Ryan Florence in particular: https://reactjs.org/docs/hooks-intro.html
This is a great way to treat your stakeholders. Also, what helps is that React is going in a direction that focused on simplicity in design. I've experienced the opposite with using Now, but I still love the mission.
And if I want to keep my now 1.0 (or iphone 6 plus) because I prefer it, why do you want to take it away so badly? My complaint is not that you are making improvements. I trust your leadership in this space. You're obviously smart people. The problem is the behavior around deprecating earlier versions. It's herky-jerky and inconsistent.
Also, what is the mission now? That would be great to know.
This is a really cool product - but it's a very different beast from Now 1.0.
Now 1.0 really was my perfect deployment tool: you can HTTP POST it a Dockerfile and it will build that container for you, start it running and start routing HTTP traffic to it.
This means you can use it for essentially anything that can be expressed in a Dockerfile. And the Dockerfiles you use work anywhere that runs Docker, so local development is really simple.
Now 2.0 is a totally different thing. It's a way of running HTTP fronted lambda-style functions written in Go, Node, Python or PHP. It looks like you can add other platforms by writing a new builder but there aren't any community-driven examples of that just yet.
It's cool, but it's a completely different product from Now 1.0 - and for my particular use-cases (my Datasette project and serving machine learning models) it sadly doesn't appear to be suitable.
I kind of wish this was called something else - "Zeit Lambda" perhaps - and old Zeit Now with the Dockerfiles could live on as a separately named project (rather than being the legacy earlier version of Zeit Now).
Running docker daemons that handle arbitrary code in a multi-tenant scenario is a security and scaling nightmare. I don't blame them for trying to get out of the morass.
We are quite confident that 2.0 can meet all the customer needs of 1.0, but going far beyond in terms of scalability, at a much lower cost.
A great example of this is "doing work in a loop". Sure, you can spin up a process and try to schedule work yourself. At that point you're responsible for monitoring, and addressing all its failure modes.
In the 2.0 world-view, you can delegate a lot of the tough synchronization and scalability problems to the platform instead.
I think the main problem I'm having is that 1.0 was already cheap enough and scalable enough for my specific use-cases.
I totally understand how 2.0 is cheaper and more scalable, but the trade-offs are that it's much less suitable for serving occasional requests for data that depends on large server-side files (in my case machine learning models and SQLite databases, both which can be 100s of even 1000s of MBs).
I guess what I'm saying is that for my specific use-cases I don't need a Now that's cheaper and scales more easily - 1.0 already had the performance and price that I needed.
Now 2.0 (or Now Lambdas) do look amazing for cheaply handling a vastly scalable amount of incoming requests that don't need to work with a large blob of data on the server. Now v1 remains my perfect environment for hosting scale=1 persistent servers that can serve those large data blobs. I'm finding it hard to imagine a platform that can combine the best of both worlds - but I'm exciting to see if you can indeed pull it off with 2.0.
I loved Now 1.0, disappointed in 2.0. It's not accurate that all customer needs of 1.0 can be met. There are size limits deploying to AWS lambdas. Web sockets don't work in lambda. Caching is a different game if your functions can spin up and down often, not to mention no sticky sessions. DB connection limits become more relevant if you have a bunch of endpoints and put them all on their own lambdas since they can't share connections.
There's value in distributed architectures, but there are already lots of ways to add that complexity when you need it. I really liked what Now 1.0 was doing (more user-friendly than hyper.sh), so this makes me somewhat sad.
There are very cheap competitors such as Apex Up for managing AWS lambdas if people want to go that route.
I hope I'm wrong about some of the above and you have plans I'm simply not foreseeing to address these issues.
This is the only disappointing release I’ve seen from Zeit, their original mission statement was to make “cloud computing” accessible to everyone and with Now v1 they killed it, providing a truly an awesome product. Now v2 is a pivot away from everything that made them unique, soon they'll be mistaken for a trendier version of Netlify...
You'll find that nothing could bring us closer to this vision than making compute so remarkably inexpensive and scalable, out of the box, for everyone :) This is why serverless is so exciting to us.
If they were marketed as different products then there didn't be quite as much panic but since this is V2 and V1 people are afraid that the product they like will be unsupported soon since it's an older version.
Also, while V1 still exists for the time being it is fair to assume that future updates will only apply to V2. One user on here already found this to be true because although a new region was added, GRU, they could not deploy to it with V1 and was told it only supported V2.
How could I achieve it in Now.2.0? Should I wrap Jupyter server with a custom gateway index.py? Before I give it a try, I’d like to hear advice from your team.
It seems that it might be possible to write a bulder like @now/jupyter to automatically deploy Jupyter notebooks with a requirements.txt. The questions are:
1. Is your team going to write it?
2. Is it possible for a third party to write it and put in the now.json?
119 comments
[ 4.4 ms ] story [ 171 ms ] thread(1) "Behind the scenes, Now 2.0 works like an extensible build system and compiler, capable of transforming your sources into static files and serverless functions (lambdas) for production."
The demo is pretty slick. I've seen other frameworks, like Begin.com, where your lambdas are more explicit, but I'm curious to try this autogenerated approach.
(2) "The Now 2.0 platform features include: A unified deployment type: All deployments are one type, regardless of static or dynamic parts Massive build parallelization: Each deployment can kick off many concurrent serverless builds. Monorepo support: Define API endpoints in Go, PHP, Node.js, Next.js, and such, in just one repository. Zero-instruction builds: Our open-source builders take the build and cache config burden away. Universal Cloud: Our platform leverages the best cloud infrastructure, with no lock-in or config. With the following pricing improvements: Fully on-demand pricing, Per-100ms pricing for compute, Free seats for small teams Including a better free-tier for our community."
It feels like all the Zeit features are coming together for a more complete offering. I love it.
Some small adjustments will be necessary when _importing_ large legacy codebases, but that's where using functions to also build your project comes in!
https://zeit.co/docs/v2/platform/upgrade-to-2-0#don-t-rush-t...
The limits are there specifically to help in that transition, to avoid the problem described in the chart. They're a crucial learning extracted from the beta we ran.
https://zeit.co/blog/now-dockerfile ??
Like I understand the benefits of lambdas/serverless. But they aren't sufficient for all use cases. The ability to have an endpoint for a docker container with one command is extremely useful. There already a lot of serverless options on the market too... maybe I'm confused...
{"version":1}
Based on that, it seems to me like I will have to migrate to Now 2.0 eventually.
[0] https://zeit.co/docs/v2/platform/upgrade-to-2-0
The reason I'm still on DO is because I need dependencies that are both large and trivial to install in docker vs. creating a custom EC2 image. To make it clear I was hoping to deploy a docker container with ffmpeg to support long running video conversions whilst benefiting from easy deploys and on demand pricing. It seems like the potential for this alluded to in the serverless docker announcement has been removed?
I can see how this V2 makes serverless simpler but the strict limits will mean that transitioning a monolithic app requires a lot of work up front. Increasing the limits would reduce that friction greatly. Whilst not best practice deploying an existing express app and have it 'just work' is a compelling reason to go serverless.
Congrats on the launch, it looks like a much more cohesive product now!
We agree that invoking entrypoints periodically is a much better way to model most worker / daemon workloads than a "stateful event loop".
The commitment to our customers is that we won't phase out V1 until this usecase (and others!) are thoroughly addressed.
The only tough part is having to delete the old cron instances when I push an update. Scheduled jobs (or some cron support) would be excellent.
https://www.apify.com/docs/actor https://www.apify.com/docs/scheduler
Disclaimer: I'm a co-founder of Apify
Thanks!
There is still a cloud provider which is manifestly a server; that's why this buzzword is stupid.
It completely takes away the pain-points of setting up and managing the cloud infrastructure directly.
From what I got to see, it is really cool!
The space of 'easy deployment' and 'scale' seems incredibly crowded, from reading the headlines - what makes this different/better?
If you look at the solutions out there, they all involve you dealing with low-level APIs or config that have little to do with how you write most apps and frameworks in mainstream programming languages.
Surely, some code changes are necessary to go serverless (when considering legacy servers and apps), but our goal is to always minimize that.
For scalability reasons, it's likely you'll want to separate the code that deals with the "request-response" lifecycle from the realtime subscription.
I liked the 1.0 Docker-version and 2.0 feels like a completely different product. Have you considered offering both long-term?
Now offering 1.0 style deployments on an ongoing basis will be helpful.
Also, does ZEIT have any plans to offer hosted databases like Heroku and others do? That's one the biggest blockers in my mind to trying it out.
The problem also ofc already exists when you have multiple applications (or instances) trying to talk to your db (which is why pgbouncer exists regardless of serverless), and serverless doesn’t differentiate between 1 and 1000 instances (which is why its trivially scalable).
And ofc if you werent going to need sufficient scale to require something like pgbouncer... should you even be transitioning to serverless? You could replicate the same stateless organization style on your own, on a single server.
If you're not running the database server yourself, is it so unimaginable that the service provider might have already configured PgBouncer on top of the database as an optional way to interface with it?
Regardless, "serverless" has never meant that there are no servers involved, it just means that for the serverless pieces of your application, you don't have to concern yourself with where or how they're run, only with the application logic itself.
If you want to go 100% serverless, then you're obviously going to have to choose a DBaaS that works with your connection pooling strategy, especially if that strategy is "I don't have one." Supposedly, based on comments on this thread, DynamoDB works pretty well for that scenario. Obviously Postgres doesn't scale with an increasing number of connections very well, which is why PgBouncer exists, and it works well.
Finally, PgBouncer is relatively stateless. Its main pieces of state are a static config file and the pool of open connections it holds. This could be deployed in a serverless fashion, and any time it is destroyed or recreated, it would be trivially reinitialized just from the config. It doesn't have to have any attached, mutable storage.
Are you familiar with any providers that offer this configuration? In my experience, at least AWS does not.
Edit: https://devcenter.heroku.com/articles/postgres-connection-po...
NOW currently doesn't have databases and tells you to use cloud DBs. So more than likely the connection is dropped when the lambda shuts down.
But if you'll let me go a little bit meta, the idea of serverless is that you shouldn't even be thinking about things like connection pooling. If you just use the databases that your provide supports those types of concerns are their concerns now, not yours.
In other words, if you want to pick your own tech stack then serverless is not for you (yet). If you're willing to surrender your opinions and just use what the platform provides you (if you're using AWS just use DynamoDB) then you can stop thinking about these problems and focus on your business logic.
Even if your lambda drops a connection after it destroys itself, a sudden influx of visitors to your site may spawn enough lambda processes to overload your DB.
What happens then is dependent on the database, but generally means that new lambdas do not get to connect.
Anyhow, you don’t really want your database to magically more around regardless, so you’d be sort-of locked in to one service regardless of what you do.
But postgres on one service is pretty much the same as on another, so if you wanted to migrate it would be fairly easy.
However, this is not the case for all databases. Furthermore, modern database vendors are extremely motivated to address the serverless usecase
I like that the cold boot up performance for a single function is super fast when compared to a "Legacy Server". But after the legacy server is up it "stays warm" regardless of user activity. Unlike a lambda function which goes cold after a few minutes of inactivity.
So the first user that hits an endpoint after some inactivity has to wait (a few seconds) for the lambda function to cold boot vs. being served immediately on the legacy server.
Is my assumption here true? Or are cold boots on lambda super fast now? When I was doing this stuff ~8 months ago it would take like 5+ seconds to be served after a cold boot.
GCP has a semi-hacky solution that provides the ability to connect to your managed dbs from your Cloud Functions; one would hope that AWS can at least match that soon.
With the Now 2.0 design, you instead are very likely to not suffer from cold instantiation to begin with, due to the healthy constraints imposed by the system.
In other words, instead of ignoring cold boots, you just want to embrace them and make them minimal to begin with.
Also, look at it from their perspective. They support everything when they support Docker, no need to have specific tooling for Node.JS.
As a matter of fact, this is an example of executing `now --regions all` :)
https://twitter.com/rauchg/status/1060616737215795200
I trust the leadership at Zeit are making the right decisions technically, but as the company grows, it also seems to get further away from its original mission.
The swift deprecation of previous versions is threatening to undermine any resemblance to the mission, if ease of use is still the mission.
The React team got this so right with the release of hooks in 16.7. Dan couldn't have been any more right on the money in his delivery, which was laden with promises of no breaking changes and "don't feel like you have to rewrite anything."
When Zeit released cloud v2, about three months ago, they made v2 the default, which broke many development workflows and required me personally to spend three full days refactoring code and resolving Docker issues due to an obscure error that Zeit support had trouble identifying. The breaking change was a shock and a surprise. The explanation? You should be doing things this way anyway.
Perhaps that was true, but maybe not.
After going through all the trouble of converting to cloud v2, I reverted to cloud v1 because I could not set the min instances in cloud v2, to eliminate cold boot as an issue. Someone on this thread said cold boot is 200ms. That may be true for a particular application, but I received so many customer complaints about slow boots (5 seconds or more), I had to revert. Reverting has solved the issue.
As of today, I have a deprecation warning when I log into Now which says `Your account is using a legacy platform version. We highly recommend upgrading.` Or what? Are you going to make my unmutable application mutable?
This announcement about Now v2 is confusing, first of all because Zeit already released cloud v2. How are the versions related? Next, serverless may be the future of everything, or it may not work for some existing environments. The jury is out.
To someone at Zeit, please watch the React Hooks Intro video, and the parts of Dan Abraham and Ryan Florence in particular: https://reactjs.org/docs/hooks-intro.html
This is a great way to treat your stakeholders. Also, what helps is that React is going in a direction that focused on simplicity in design. I've experienced the opposite with using Now, but I still love the mission.
And if I want to keep my now 1.0 (or iphone 6 plus) because I prefer it, why do you want to take it away so badly? My complaint is not that you are making improvements. I trust your leadership in this space. You're obviously smart people. The problem is the behavior around deprecating earlier versions. It's herky-jerky and inconsistent.
Also, what is the mission now? That would be great to know.
Now 1.0 really was my perfect deployment tool: you can HTTP POST it a Dockerfile and it will build that container for you, start it running and start routing HTTP traffic to it.
This means you can use it for essentially anything that can be expressed in a Dockerfile. And the Dockerfiles you use work anywhere that runs Docker, so local development is really simple.
Now 2.0 is a totally different thing. It's a way of running HTTP fronted lambda-style functions written in Go, Node, Python or PHP. It looks like you can add other platforms by writing a new builder but there aren't any community-driven examples of that just yet.
It's cool, but it's a completely different product from Now 1.0 - and for my particular use-cases (my Datasette project and serving machine learning models) it sadly doesn't appear to be suitable.
I kind of wish this was called something else - "Zeit Lambda" perhaps - and old Zeit Now with the Dockerfiles could live on as a separately named project (rather than being the legacy earlier version of Zeit Now).
A great example of this is "doing work in a loop". Sure, you can spin up a process and try to schedule work yourself. At that point you're responsible for monitoring, and addressing all its failure modes.
In the 2.0 world-view, you can delegate a lot of the tough synchronization and scalability problems to the platform instead.
I totally understand how 2.0 is cheaper and more scalable, but the trade-offs are that it's much less suitable for serving occasional requests for data that depends on large server-side files (in my case machine learning models and SQLite databases, both which can be 100s of even 1000s of MBs).
I guess what I'm saying is that for my specific use-cases I don't need a Now that's cheaper and scales more easily - 1.0 already had the performance and price that I needed.
Now 2.0 (or Now Lambdas) do look amazing for cheaply handling a vastly scalable amount of incoming requests that don't need to work with a large blob of data on the server. Now v1 remains my perfect environment for hosting scale=1 persistent servers that can serve those large data blobs. I'm finding it hard to imagine a platform that can combine the best of both worlds - but I'm exciting to see if you can indeed pull it off with 2.0.
There's value in distributed architectures, but there are already lots of ways to add that complexity when you need it. I really liked what Now 1.0 was doing (more user-friendly than hyper.sh), so this makes me somewhat sad.
There are very cheap competitors such as Apex Up for managing AWS lambdas if people want to go that route.
I hope I'm wrong about some of the above and you have plans I'm simply not foreseeing to address these issues.
I think you did the right thing
VM/Containers allow people to develop and structure the app however they want, largely decoupled from deployment/infra.
I don't understand how many people have no issue being told to rewrite your apps so they fit inside lambdas...
Also, while V1 still exists for the time being it is fair to assume that future updates will only apply to V2. One user on here already found this to be true because although a new region was added, GRU, they could not deploy to it with V1 and was told it only supported V2.
https://now-befdojuvlz.now.sh
How could I achieve it in Now.2.0? Should I wrap Jupyter server with a custom gateway index.py? Before I give it a try, I’d like to hear advice from your team.
https://github.com/zeit/now-builders
It seems that it might be possible to write a bulder like @now/jupyter to automatically deploy Jupyter notebooks with a requirements.txt. The questions are:
1. Is your team going to write it?
2. Is it possible for a third party to write it and put in the now.json?