
Now 2.0 - Rauchg
https://zeit.co/blog/now-2
======
simonw
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).

~~~
Rauchg
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.

~~~
simonw
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.

------
sholladay
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.

~~~
diminoten
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.

~~~
sholladay
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.

------
kristiandupont
While this is cool and surely an improvement technically, it makes it clear
that I will have to move off of Now. That makes me sad as I immediately became
a paying customer and have loved the product more and more each day.

It’s not that I couldn’t upgrade, surely I could. It’s inconvenient but not
impossible. The problem is that I need my hosting to be as reliable and
invisible as possible. Being informed that I need to change my infrastructure
out of the blue is unacceptable unless it’s because there is a security reason
or perhaps because I am using severely outdated technology. I will now have to
spend precious development time figuring out which alternative will match my
build process etc.

------
brod
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...

~~~
Rauchg
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.

~~~
ontouchstart
I took a look at this

[https://github.com/zeit/now-builders](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?

    
    
        {
          "version": 2,
          "builds": [
            { "src": "*.py", "@thirdparty/jupyter" }
          ]
        }

~~~
conceptpad
Not to speak for @rauchg and the team, but I think the answers are 1: no (or
not soon) and 2: yes

------
StanAngeloff
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?

~~~
Rauchg
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.

------
ericand
A couple significant callouts:

(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.

~~~
Rauchg
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!

~~~
playpause
Can you point to an example of using functions to build your project?

------
tima101
@Rauchg

What fraction of Now customers care about cost and scalability so much that
they will invest time into splitting monolithic server into many lambdas (a
monorepo). (I've read in Now 2.0 docs that it is recommended to have 1 lambda
per 1 API route.) EDIT: After splitting, is there overhead in managing many
lambdas vs monolith server?

Once a server is split and configured, will these customers be able to migrate
out of Now 2.0? From what I see right now, it is basically a vendor lock-in.

Is it possible that majority of Now's customers are websites, simple CRUD
apps, small SaaS apps and they don't care about cost and scalability that much
and won't add lambda-related overhead to their code?

Do you guys try to shrink your customer base and work with perhaps bigger
clients with critical apps who are more paranoid about scaling, cost and want
to invest in lambdas?

Sorry about typos.

~~~
tapsboy
I have similar questions if @rauchg is still reading. We just got a premium
account and was setting up Dockerfiles and now.json based on Now 1.0.

All, I want to do is provide a Dockerfile that included a cross-platform build
process. Including now specific build tools is not ideal for avoiding vendor-
lock in.

Now has amazing for us to build prototypes, internal sites etc that we may
eventually move to our standardized AWS infrastructure. Adding now specific
build tools makes the process unusable for us

I understand from the docs that Now 1.0 is not deprecated yet, but it bothers
me to invest more time in converting some of our internal projects to Now

------
ianstormtaylor
Potentially noob question... but how does having a lambda function per route
work with connection pooling for something like Postgres?

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.

~~~
MatthewPhillips
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.

~~~
ianstormtaylor
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?

~~~
Aeolun
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.

------
iMuzz
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.

~~~
manigandham
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.

~~~
dbbk
What's the point of that? Why not just get a normal server if you want it
available 24/7?

~~~
manigandham
But then you wouldn't be enjoying "serverless"

------
navd
Is there way to develop and test this locally? It seems like you constantly
need to deploy to now to test new changes?

~~~
Rauchg
We definitely look forward to giving you tools here. One can conceive a `now
dev` process that _faithfully_ reproduces the cloud gateway.

------
homerjam
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...?

~~~
Rauchg
In our upgrade guide we detail how you can break down a "server" that you
would otherwise deploy as a monolithic container:

[https://zeit.co/docs/v2/platform/upgrade-to-2-0#don-t-
rush-t...](https://zeit.co/docs/v2/platform/upgrade-to-2-0#don-t-rush-to-
upgrade)

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.

~~~
cphoover
So this doesn't work anymore:

[https://zeit.co/blog/now-dockerfile](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...

~~~
mattste
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".

~~~
gigatexal
Can't you use now v 1.0 setting the json file now.json to have this among
other things:

{"version":1}

~~~
mattste
_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.

[0] [https://zeit.co/docs/v2/platform/upgrade-
to-2-0](https://zeit.co/docs/v2/platform/upgrade-to-2-0)

------
sjroot
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!

------
alexashka
For someone who's not in the loop, can someone give a brief explanation of
what pain point this solves?

The space of 'easy deployment' and 'scale' seems incredibly crowded, from
reading the headlines - what makes this different/better?

~~~
keithwhor
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.

~~~
sooheon
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?

~~~
crooked-v
You put database access, S3 access, etc in your lambda functions, using env
vars configured in the Now account settings.

------
DevKoala
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?

~~~
manigandham
Cloudflare Workers does well here with their KV keyvalue store integration.

------
tmvnty
As a big Next.js fan, this is a big release to me, React is my go to front-end
choice and Next.js does amazing jobs server-side rendering and many other
great things too, Now v2 supports Next.js out of the box means I can use
lambda functions to serve SSR React for will save me a lot of boilerplates and
maintenance work, so I will definitely check out Now again probably try few
demo apps out...

But all great things aside, having Now v2 tied with AWS lambda means I will
have to switch to AWS too. I like to stick with one cloud provider and my
current favourite is GCP/Firebase, and I will have to weigh out the pro & cons
of AWS/GCP again for Now v2. Hopefully in the near future, Now could be cloud
provider agonostic

~~~
Rauchg
Very important: you absolutely don't have to switch to or configure any cloud
provider.

However, it is a very healthy thing to understand the "behind the scenes" in
case you need to interoperate with existing APIs or databases[1]

[1] [https://zeit.co/docs/v2/platform/regions-and-
providers](https://zeit.co/docs/v2/platform/regions-and-providers)

------
tofflos
Are you looking into making builders for Java and are you looking into
offering some sort of persistent storage?

I liked the 1.0 Docker-version and 2.0 feels like a completely different
product. Have you considered offering both long-term?

~~~
tapsboy
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.

------
robotkdick
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](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.

------
andrewmunsell
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!

~~~
Rauchg
We have been running an internal beta of the jobs feature, and we'll keep
everyone posted!

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.

~~~
kylehotchkiss
Yay! thanks for letting us know it's coming.

------
XCSme
Is it only for HTTP or does it also work with WebSockets?

~~~
Rauchg
We are planning to give you very simple hooks and integrations to support
WebSockets (e.g.: PubNub or Pusher).

For scalability reasons, it's likely you'll want to separate the code that
deals with the "request-response" lifecycle from the _realtime subscription_.

------
gigatexal
How do users do logging, just an agent in the app that sends data to a hosted
logs platform?

~~~
Rauchg
Logging is built-in. Just append /_logs to your deployment URL and you'll see
all stdout and stderr of your underlying functions.

~~~
gigatexal
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?

------
garysahota93
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.

Thanks!

~~~
dreamcompiler
"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.

~~~
wilg
This is why I call it "I Can't Believe It's Not Server!" instead.

~~~
jacobush
No, but it's some kind of grease you put in the pan. I love your
appropriation!

------
karakanb
Kudos to the team to launch this new version, it looks really slick and my
previous experience with Now was pure joy, it was really easy to get up and
running. My only question with this approach is what is the suggested way to
work locally? For example, the `Majestic Monorepo` sample is quite hard to run
locally without Docker or a similar containerization technology, what is Now's
approach to this? Would we be able to work offline with a project like this
for example?

------
schnarfnark
Looks cool. FYI – API Reference in the nav 404s:
[https://zeit.co/api/v2/](https://zeit.co/api/v2/)

------
PullJosh
All of this serverless stuff looks great in theory, but I'm struggling to
understand what the development environment looks like. Does every change in
testing get deployed to zeit? That seems cumbersome. Otherwise, is there a
nice way to test this stuff locally? (Also, how would one set up a database?
On a separate service?)

------
avip
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.

------
oliverx0
I was just browsing through the docs and got a rate limited error. (429)

From what I got to see, it is really cool!

------
dev1789
We loved you, Now. But we have to leave you, Now.

Serverless is still bad for modern web apps, that serve HTTP requests to real
people..

I know that from practice, running Next.js & a GraphQL backend on AWS lambda.

Many devs think, that the infamous "cold start" problem is easily solved by:

"Warm" keeping (keeping a number of functions "warm" 24x7).

Cold start times getting below a certain level, the often cited < 300ms.

Both solutions currently fail to address the problem.

Let's say you keep 5 functions "warm". Of course the first users will not
suffer from cold starts. But then, if you get a large number of almost
simultaneous requests (a burst).

A certain number of users will get immediate responses, as they are handled by
warm functions. But another set of users will experience far worse response
latencies, as lambda functions were spun up, for every additional request
coming in, while the warm functions were occupied.

While spinning up new servers is definitely slower, the total wait time in the
classical server model, under heavy load, is equally distributed among all
users of your app, so everyone sees it perform "a bit slower".

In the serverless model, on the other hand, some users will enjoy the
immediate response time, while others will have horrible response times
(especially taking additional latencies into consideration, see below). And
they will leave your website within those 3 seconds.

For most commercially successful websites, increased latency is far more
expensive, than some additional scaling cost. Everyone coming to our app is
worth a lot of $$$, as we had to spend a lot of $$$ to get her here. One
should consider that, when discussing scaling considerations. I think most
people know the famous Amazon study, of 100 ms === -1% in sales. So if you try
to argue about scaling cost, please keep your Google AdWords bill close.

Keeping functions warm also feels like the stone age. You're basically just
pinging the thing all the time. People are seriously talking about pint-time-
distribution-algorithms on Medium, i.e. how often, and at what time deltas you
need to ping the thing, to hope that e.g. AWS Lambda is keeping a certain
number of functions warm for you. Feels like a mysterious hack to me.

Now, let's debunk this naive latency argument. (I was sold on that, too before
i ran a real life app on it).

Obviously you're not using a huge monolith, splitted your app in services, at
least backend & frontend. Now, take a look at our user case.

Client →

→ Next.js Frontend (Lambda with Node.js)

→ GraphQL Server (Lambda with Node.js)

→ Prisma GraphQL Server (Lambda with the JVM)

→ Some managed database at GCP or AWS

See the problem? You don't have ONE cold start time. You might have THREE.

And don't forget, this is just additional time added to the:

Request handling time + database calls + data center latencies + client
location latency + low client bandwith. This is why you can read comments
here, that real people are waiting 5 sec for your page to load.

Also: The < 300 ms is just a best case scenario, that works for Node.js apps.
Try to put a JVM app into the chain app (like e.g. Prisma GraphQL which runs
on Scala). The results will be far worse.

That's also why the term "global deployments" is just a nice buzz word. Never
forget to keep all your stuff in the same datacenter. You can't abstract away
physics. You need to know or make educated guesses, who really owns these Zeit
datacenters. If you read "Brussels", get your database at Google. If it's SFO,
it might be better AWS..

If you're running GraphQL servers with subscriptions, or any other keep alive
connections, beware of other issues with Lambda.

We were planning to use Zeit Now for our whole app infrastracture, besides the
DB, which was supposed to be managed by Google or AWS.

We were doing serverless and running on AWS Lambda & Now before. And we were
facing severe issues with AWS Lambda: Massive problems with cold starts, with
user request bursts (e.g. someone posts an article about your app or after
running a TV commercial)

While i try to "embrace" Lambdas that, i must admit, appeal to me from a dev
experience viewpoint, i'm losing $$$ and FAR WORSE, providing a bad experience
to my users.

------
js4ever
Other similar wrapper to lambda functions but with a serverless sql database:
[https://cloudbackend.appdrag.com](https://cloudbackend.appdrag.com)

------
pier25
This makes a lot more sense for me. Next step for total serverless domination
is solving the database.

Congrats!

------
jahewson
Has anyone here used Now extensively for dynamic sites? What was your
experience?

------
kierenj
Still haven't been able to get a simple now example running, issue open since
Apr 2017 - [https://github.com/now-examples/linux-
desktop/issues/1](https://github.com/now-examples/linux-desktop/issues/1)

------
revskill
How about websocket over lambdas ?

~~~
silverstrike
Not possible. Their marketing that all 1.0 cases can be moved to 2.0 is
disingenuous

~~~
anthonyshort
They never said that all 1.0 use cases were covered now. They promised that
eventually they will have use case parity and then they’ll deprecate 1.0.

------
nine_k
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.)

