"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.
It's hardly surprising the phrasing is a big WTF - the term "serverless" is the most ridiculous thing since rented virtual servers suddenly become "the cloud".
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"
I'm also not a big fan of the term "serverless" within this context either, however I don't think it's entirely fair to blame the Zeit team for following along with the rest of the industry. All the big tech companies use the term, which forces smaller players that wish to compete in the same space to use it as well.
Both terms have a deeper meaning which is seemingly lost on pedants like yourself.
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.
Both terms have a deeper meaning which is seemingly lost on pedants like yourself.
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.
I guess I just don't see how much easier it can get than to kill a process, start it, and test. These are all solutions to non-problems. My control-C + up arrow motion is hammered down after years of practice.
Yeah, same as Ctrl-Shift-R in the browser for me. Even when I'm running a hot reloading server on my project I'll start off pretty much every manual test with a hard refresh because it's so trivial that it's easier than dealing with the 1/500 chance of something going weirdly wrong with the hot reloading and being difficult to debug.
Same for me - I even do it for things that don't really need a server restart to take effect, just because it's an ultra-quick reflex. It's a non-issue really.
The reality of developing serverless apps is seriously painful for anything that's not 'hello world'. Non-trivial functions very quickly go over the size limit for directly uploading your dependencies, then you have to start doing stuff like extracting your python packages into a zip file and pushing it to an s3 bucket, and then every small code change requires a new upload. Testing and debugging tools for serverless are distributed logs that are mixed in with all your other logs in your VPC.
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 implemented hot reloading once for a game scripting engine. The gain was totally worth the work I put in (and had the side effect of discouraging use of globals).
Yeah in PHP, unless you have some opcode caching that ignores file modification time, you simply need to just change the file and it immediately starts running the new code. There isn't a compiled runtime generally that persists across requests. This is one of the great things about php, and is one of the things that made PHP so pervasive and get the marketshare that it did.
When I last did PHP, i ran it all in docker, but the same thing applies.
What? I beg to differ... I've used many a JVM web framework with hot reloading. Like most every language, they are not perfect, and come with gotchas but they're surely there.
The only "easy" way to support hot reload in JVM is using java agent. But it can only reload method body, so it's extremely limited tool. That's how IDE usually work. You can sell your house and buy JRebel license, but if you don't have house to sell, you're out of luck. You can try some experimental alternative JVM implementations (DCEVM) which might or might not work.
May be your framework is just restarting automatically very fast. That's not a hot reload, though.
Five years ago I was coding Java EE (JSF, EJB, JPA) on NetBeans, which comes bundled with GlassFish. The hot reload development experience back then was extremely fast (sub-second for what I was doing) and a lot more reliable than JRebel. It didn't need any special configuration. The whole thing worked right out of the box. I got the feeling back then that JRebel's days were numbered if developers caught on. Sadly, the trend was more towards a build-your-own stack approach, typically using Spring, and so JRebel continued to have a market. It's a pity, because Java EE 6 onwards seemed to be quite well thought out with numerous open source implementations and a good reference implementation.
> 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.
The difference is that your runtime state is reset and you must architect your application to keep fast startup time which is not always a good thing. OSGI does not reload classes, it loads new classes, you can't reload class for an existing object. It's the same restart, you just leak memory.
> The difference is that your runtime state is reset and you must architect your application to keep fast startup time which is not always a good thing.
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.
> The difference is that your runtime state is reset and you must architect your application to keep fast startup time which is not always a good thing.
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.
About 6months ago we had to leave now v1 because of bad TTFB times compared to Heroku (me in Europe and server in USA east - now gave 800-900ms TTFB with massive variance > 2s vs Heroku constant 250ms TTFB). We left because of those bad TTFB times and an unresponsive support from my point of view, once they left slack in favour of spectrum [1, 2] it was impossible to get a response. I had left some detailed tests. (Spectrum is hosted on now I think which has currently a 2s TTFB for me in Spain).
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.
From my experience, every single time a company/product moves to Spectrum, the quality of support drops significantly, both from staff and the community. I really don't understand why people like it, and why they were bought by GitHub.
This is the company behind Next.js, which I've had a wonderful experience using for React development. They've managed to do what I thought wasn't possible: abstracting away most of the build system. "Now" seems to do similarly well at abstracting away a lot of the hosting complexity.
They've made React development feel as simple as PHP. Or at least close. Just make a file and upload it.
I use Next by default for all React projects now. Just haven't found any reason not to, it's a joy to use. Same can be said for the Vue equivalent, Nuxt.
I’ve had a very similar experience building with nextjs. Drastically simplifies the boiler plate needed for a React app and gives you a concise api for SSR.
The positives are both are pretty similar but the usecase is different.
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.
Next.js is server-rendered which means it includes a light weight node.js server that pre-renders your pages, you can export everything as an static website, but it's not really the main selling point.
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.
Would be interested in this as well. I currently use Gatsby for a personal site, and the development server is great and for prod I just sync production assets to an s3 bucket and serve from there. It's hard to see how it could get any easier.
I can’t believe that `now dev` was released after about 6 months? from now v2 launch.
For my experience in developing now v2, it was super insane to develop for the platform.
Any kind of code change involves minutes to just test, see the `console.log` result, which makes developing super painful. Everytime I think about Zeit’s now v2 is that it was rushed to launch for the new buzzword ‘serverless’.
I actually was impressed by the new architecture; but development was (and is... I didn’t check about a week or two, but last time I checked: `now dev` doesn’t respect `now.json`’s routing properly) painful.
Ultimately I just went to Netlify Functions :-(
(BTW... While I didn’t say anything about Now v1, it’s a mistake if you consider v1 as outdated; those two should be different products... and should not be deprecated but marketed as a different service...)
> it’s a mistake if you consider v1 as outdated; those two should be different products... and should not be deprecated but marketed as a different service
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.
Am I the only one who wishes they would continue their v1 system work? It Just Works(tm) and was wonderful to use and easy to understand, especially from a pricing perspective. I feel like the gas pump style pricing for their serverless offering is shoehorning a pricing model that works well for vendors but less so for users. With that said, I really enjoy these guys/gals’ work and would love to work more with their platform.
Thanks for your feedback. We've actually received quite a lot of other feedback regarding the new pricing model and will – as a result – soon be working on a way to set custom alerts and limits, so that it behaves just like 1.0 pricing, if you want it to.
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.
I really like the stuff by Zeit but if you've been a user for more than a year it's insane how quickly the platform is shifting under your feet.
"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.
I really like the recent trend of dead-simple deployment tools. Now, zeroserver[0], and 1mb[1] are all awesome attempts at simplifying the confusing web world!
I've heard a lot of devs have very negative comments about Now 2, but have never delved into specifics. Apparently it's way worse than 1. Anyone here has any idea what, exactly, is wrong with it, and whether it's really bad?
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.
This is a great point. For small to medium, read-only, slowly changing datasets, this is the ultimate serverless database model, especially for lots of queries.
Although I think this approach would benefit more from Cloud Run’s request multiplexing per function.
I imagine you could load something from an endpoint like s3 or an API in one format, load it into sqlite, then begin processing it using SQL. Results could be posted back to another API or S3 in any format.
It’s not bad; it’s a different product.
Now v1 was about dead simple deployments with no configuration, as now automatically configured that for you.
Now v2 is about serverless (with minimal lockin, I’d say), and is a pretty good (actually pretty awesome) product if you see it alone.
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 1 was very opinionated but got out of the way quickly, with mini al changes to your code (in my case golang) you were up and running, did it with a Dockerfile using scratch as a base, integration with github, autoscaling, multiple data centers. I ran a production app used by hundreds of mobile users every day and it ran for a year practically unsupervised. you were up and running. now 2 requires rearchitecting your applications, in golang it means one file per server path and for our application it meant it was easier to migrate to GCP using nixops.
If you're interested in other JS based serverless frameworks, https://arc.codes can also run on localhost - even though serverless deploys are fast because they're per-lamda, localhost is still super useful for ever faster iteration.
Imagine AWS has the same Developer Experience as Zeit team, AWS could benefit even more from their services. The AWS console and its definitions is too low level to me, hard to grasp quickly to produce something useful.
Congratulation to Zeit team for the effort on DX. Thanks you very much for the inspiration.
Thanks for the compliments! That's exactly what our product is trying to achieve: Abstracting away all of that low level stuff, so you can just run `now` and that's it.
I'm currently experimenting with migrating a side project to now 2.0. It has been a learning experience, for sure. But so far I think that it has been time well spent.
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.
I'm glad to hear! Over time, more and more guides and proper documentation will be created for Now 2.0, so I'm sure you won't have any troubles with migrating any kind of application to Now 2.0. Aside from that, your bill is most likely going to decrease heavily, as Now 2.0 is much cheaper than Now 1.0.
The command used for this can be invoked on any OS that Now CLI supports (Linux, Alpine, macOS and Windows). In terms of the languages that are supported, there's no end, really:
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.
Finally - I've been using Now v2 for side projects at work and it's been a PITA to work without simple local dev. Having to shoehorn dev-only code in there was annoying. Hopefully this works well.
Ouch, so many negative comments in this thread. I thought this sounded very interesting and was thinking about trying it, but it sounds like they need to improve a lot of things.
This release of `now dev` is indeed a preview release. We're working very hard to improve the quality of the CLI, so should you notice any bugs, please let us know and we'll get right to it: https://zeit.co/feedback/dev
If "serverless" is referring to AWS Lambda, Azure Functions, etc. then cost and scalability make it a great idea for some applications. If load varies by time, and there are surges and troughs, then running servers can cost more and potentially be less responsive to changing demand. Its a nice way to take load off a web server.
I feel like the use case is much smaller than the number of people preaching it warrants though.
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.
I agree. Where I saw it used, I'd say 99% of the application logic was in the web server, 1% in functions.
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.
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.
Depends on your use case. Certain parts of the app fit the bill really well.
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)
It would also be really simple to sftp a single application to a /cgi-bin/ directory on a shared web host. You don't need to know anything except STDIN and STDOUT, and none of that CI/CD or VCS boilerplate to worry about. Instant web applications. It'd probably be much simpler than using Lambda.
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.
Genuinely interested to hear/read these use cases.
I'm using a serverless stack at the moment (AWS Api GW + Lambda), and after the initial headaches of wrestling with Cloudformation it's been relatively simple and performant
Yes. I believe "serverless" still has it's use cases. It's really good for small services and abstracting away some logic. It's really good for basic query and render (html/json) type apps. If you're doing more, then I suggest you just build more services that are specific to it's task and then let them talk to each other through RPC or similar.
Care to share? I haven't seen a single such blog post and would like to learn. (never did much serverless myself but could see us use it in the future)
"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.