Now dev – Serverless on localhost
zeit.co
zeit.co
"When you work with servers, the developer workflow is quite tedious. You have to run a process, find the port, then make your changes, then kill the process (usually with Control+C)..."
I don't know what web servers they are using but in development that's not the case at all in Python, Ruby and Elixir.
With most modern web servers you can run them in some type of development / debug mode where on code change, your code gets reloaded without having to do that manually, and you'll get sub 100ms updates. This has been available for many many many years now. Even with PHP development from 10+ years ago you had a way to see code changes without having to restart Apache.
May be your framework is just restarting automatically very fast. That's not a hot reload, though.
If you can't tell the difference, then what's the difference?
There are plenty of ways to reload classes in the JVM as well - OSGi is the most well known and popular. If an agent is the only way you've seen reloading done, then you mustn't have much experience with the full range of libraries and frameworks available on the JVM.
Seems like slow startup time would be just as bad, if not worse, for a workflow that involves killing the server and bringing it back up again from scratch to test changes. So I think that either way it's a good idea to architect your application, at least in "development mode", to have a fast startup time.
These are good things for serverless, which is what the article is about -- runtime state in a serverless application is bad, and fast startup is good.
Serverless instances are intended to be interchangeable and ephemeral. You should be able to start new instances and they should be able to do the same work as the existing instances -- that only works well if they are stateless. Any necessary state should be stored in a database or blob store or some other external state management system.
Granted, there are advantages to things like JRebel that can also preserve state, but I feel like that is really orthogonal to the whole discussion.
tomcat using exploded wars hot reloads out of the box. run it inside intellij and it is even easier.
The Play framework uses classloaders to keep library classes (which are stateless) loaded, while reloading app code.
The JVM has build in hot swapping for cases where signatures don't change.
And then JRebel uses proprietary rocket science to do really good hot reloading.
java has had hot reloading of recompiled classes for years.
and if you use dcevm, the number of things that can be hot-reloaded is even higher: http://dcevm.github.io/
Save a file, see the result instantly.
In a browser, terminal, etc. Using live reload, auto test, Rails class reloading, and so on.
You may as well make a bacon pizza and say "vegetarian" and when someone questions it, just say "well you didnt personally kill the pig, so it's not really from an animal"
hah! I'm so happy to see someone say this. I've been thinking the same for awhile and did not know how to articulate it.
Serverless very literally involves a server
Is a rented vm in a warehouse on a remote industrial estate a hyper-scale data centre with dedicated fibre etc.? No.
Is a web host which lets you manually add more hosts into a load balancer and bill you for each additional host a self-scaling, micro billed (aka serverless) solution? No.
But you know that already.
Is a rented vm in a warehouse on a remote industrial estate a managed data centre with dedicated fibre etc.? No.
Is a web host which lets you manually add more hosts into a load balancer and bill you for each additional host a self-scaling, micro billed (aka serverless) solution? No.
But you know that already.
When I last did PHP, i ran it all in docker, but the same thing applies.
I'll take a look at this the next time I'm required to use serverless, but I really don't know what the people pushing this as the future of web apps are smoking. It's never been anything but pain for me. How anyone can try to use this for real and say, "This is sooooo much better than all that old shit!" has never actually used that old shit. That old shit works really, really well. It has for a very long time.
I really wanted to use now because the developer experience is so great but the TTFB made itunusable for us to host customer facing services and lack of support response made it hard to stay.
[1] https://spectrum.chat/zeit/now/slow-response-times-for-node-... [2] https://spectrum.chat/zeit/now/latency-discrepancy-between-n...
Had strictly the same issue with zeit.
Performance is horrible.
I also remember seing a somewhat similar issue about latency opened on GitHub[0].
They randomly closed it without giving any explanations or further details.
That's great support for sure !
They've made React development feel as simple as PHP. Or at least close. Just make a file and upload it.
I like to use next.js for small brochure-like websites. I think it's simpler for simpler things. But for a more full-featured content site I would chose gatsby.
Gatsby probably isn't the right choice if you have a lot of pages (e.g. ecommerce site) as it has to render each page down to HTML during the build - so everytime you make a change, you have to rebuild all those files which could take a substantial amount of time. But if you were just building a few landing pages or a blog that required good SEO then Gatsby would be fine.
Next.js renders serverside on the fly and has good SEO.
This might be useful for you to read: https://coffeencoding.com/cra-vs-next-js-vs-gatsby/
I'm not sure if your intent is to express your own opinion, or reflect Zeit's official position; but their official position last I checked at the end of the 1400 post monster Spectrum thread, was that Now v1 is dead and won't be supported after some point.
And I think that is an utterly insane decision to be making, and is the reason we are leaving. If I can't trust my host to not get "shiny tech syndrome", then I need a different hosting service.
With regards to 1.0 "just working": Aside from making 2.0 more intuitive, we're heavily investing into tools that allow you to automatically transition existing applications to 2.0, so that would definitely help a lot.
"The latest version of the CLI is now x.x.xx" - and all that stuff you think you knew how to do has changed. And we've added a useful feature that's only documentation is Github issue #432.
Also this email is to inform you that you've been charged incorrectly because you're on Now v1. Upgrade to Now v2 for cheaper rates. It's simple, just follow these 8 steps, change your entire mental-model of how everything works, and flip this obscure option in your settings.
It's as if their development process is a bunch of hackathons thrown out to the public.
You're doing good work Zeit, but please, some order.
I agree strongly. There's been a lot of chance over the last couple of months, as Now 2.0 appeared and the entire platform started adapting to it.
However, I'd also like to let you know that the entire concept of "platform versions" is just a temporary way of slowly allowing everyone to migrate to Now 2.0 at their own pace. Once this process is complete, the whole concept of platform versions will disappear and I hardly doubt there will be any major changes from that point on.
The problem is that Zeit wants to deprecate Now v1 in favor of Now v2, which is super different and is incompatible (Now v1 code should be appropriately configured to use the `@now/node-server-builder` to run on the v2 platform).
I believe that Zeit should keep these two products as different names, something like ‘now classic’ and ‘now serverless’.
Now v1 was essentially serverless Docker: you define a Dockerfile that runs a web server on a port (along with anything else you can cram into that container), push that Dockerfile up to Now v1 and they would build the container and run it in a scale-to-zero configuration: with no traffic, the container wouldn't run at all. When a request came in it would start up and start serving - then it would shut down again a few minutes after the last incoming request.
It was very similar to Google's new Cloud Run product - but better, because you didn't even have to build the Dockerfile yourself - they would build and run it for you.
The biggest catch with v1 was the cold-start time: depending on the size of your image it could take quite a while to serve that first hit. Their efforts to optimize this apparently didn't work out well enough for them.
Now v2 is an entirely different product. It doesn't use Docker at all - instead it compiles your code to run on AWS Lambda. This means it's MUCH less flexible: with Now v1 you could run anything that could be defined in a Dockerfile - Now v2 instead requires you to stick to the list of languages supported by their "builders" - https://zeit.co/docs/v2/deployments/builders/overview - initially available for Node.js, Python PHP and Go but more have emerged over time.
Now v2 also has the ability to run a single app built in multiple languages - it compiles each language to a separate Lambda. This is a neat technical trick but it's not something most people are actually keen on using in my opinion.
My biggest problem with v2 is that you have to write software that specifically targets it. With v1 I could take any web application that can run in a Dockerfile and deploy it instantly with no changes. v2 requires me to write code that directly targets the Now v2 system (hence why the initial lack of "now dev" was so painful).
My second biggest problem with v2 is that the AWS Lambda build of Python 3 doesn't currently ship with the sqlite3 module, which is key to many of my projects.
From my perspective, Now v1 was genuinely my dream hosting environment. Now v2 is an interesting project, and it's great if your project is one that fits the AWS Lambda model well, but it's no-where near as appropriate for my projects as v1 was.
Although I think this approach would benefit more from Cloud Run’s request multiplexing per function.
Congratulation to Zeit team for the effort on DX. Thanks you very much for the inspiration.
https://github.com/vishaldpatel/rust_lambda_sam_local
.. hopefully it'll save you some time =).
>- Newer installation of Rust, probably.
does not instill confidence
My overarching goal is to be able to create and deploy a new web app, from scratch, and just have the platform take care of all the boring stuff that should just work.
So far I've been pretty pleased with nextjs and now 2.0, especially once I grokked the lambda concept and found out how to slice my old express server into vertical pieces. Also, I had to realize that the monorepo model was the right fit.
I'm not quite up and running yet on now 2.0 but I'll be any day now. Curious as to how it will affect my bill.
https://github.com/zeit/now-builders/tree/master/packages
(These are just the default ones, you can add your own language using https://zeit.co/docs/v2/deployments/builders/developer-guide...)
Given what I read in this thread and their docs, it looks like they are still searching for a coherent solution to solve the "deploy my app" problem (from Docker with v1 to AWS lambda in v2), and they appear to be very vendor-specific with solving it.
The main goal seems to be to condense any action a developer might want to do into a single command.
It pretty much seems geared towards the JavaScript ecosystem.
Just yesterday i put the 'dnspython' module behind a google cloud function and all it took was 5 minutes and i had a REST interface to query MX records. It's great for small little use cases like that.
Another use case might be a simple webhook, where you're receiving pings from an external service and all the serverless function does is save it to a DB and maybe trigger another task for it.
In cases like this you can skip a lot of the devops boilerplate and reduce it a single file containing your function and perhaps a requirements.txt(or whatever manages your dependencies)
I don't have anything against FaaS as a concept, but it almost always leads to crappy operation. The simplest examples of it working are crowded out by the attempts that ended up redesigned as normal applications.
I will gladly pay (Amazon|Google|Microsoft|Cloudflare|Zeit) to manage software deployment infrastructure for me, allowing my teams to concentrate on writing business logic. As with any other concept, it has a learning curve, but once you're comfortable with the concepts, your development will speed up, no question about it.
You really have to have extremely unpredictable and spikey needs as well as need the processing immediately. Because if the traffic is predictable, you can schedule spot instances for much cheaper and same for if the data doesn't have to be processed immediately.
To me, the best use cases are very infrequent, spikey, brief needs. I haven't seen a lot of examples that meet that.
The 1% in functions was for processing large PDF files where users were sitting their looking at a progress bar waiting for the file to be processed in real time.
Another use case might be for something that is very low load, and say you have a lot of these services you may not want a VM for each one. However Docker provides a nicer solution for that: Get a VM (reserve if required) and run some kind of Docker host/orchestration on it, and run all your little services from there.