First of all, I'd like to thank you for creating
micro and all other amazing services/ products and for hosting this AMA. My questions are:
nowdeployments are stateless, what service do you recommend for database hosting?
The "Pro" pricing plan of
nowlooks great, but can be a bit expensive for some. Do you have plans (pun intended) to create a cheaper, 'lite' plan that offers private projects and custom domains while cutting down on other features?
1) One of the reasons Now is stateless is that you get to pick the right solution for each problem!
This allows you to find the balance between latency, querying features, replication characteristics, throughput and even UX (how do you see the data you store later on? what questions can you ask on the data?).
Hosted OSS databases
- Compose.IO: MySQL, Redis, Postgres, RethinkDB, ElasticSearch
- Google Cloud SQL / Amazon RDS: MySQL
- Redis Labs
Realtime databases / message queues
- Elastic Cloud (haven't tried this yet)
- Backblaze (haven't tried this yet)
- Slack (you can for example log events to channels and get search, teams access, notifications for free!)
- Spreadsheets with APIs:
- Google Spreadsheets
The beautiful thing about the world we live in today is that we have so many APIs for everything. I've built little websites that I update by editing my spreadsheets and the changes reflect in realtime. I've stored multiple terabytes of data on S3. Huge range of possibilities and scale.
2) With regards to pricing, this is a very interesting question! Another question down here asks how we can provide so much for the value.
So here we are, in an AMA with two conflicting opinions in price. And in that paradox lies the answer. It all has to do with usage patterns!
Now is such a versatile tool that it can be useful for hosting a little static site, but also launching dozens of microservices that auto-scale to power a large operation.
If you look at our pricing page, you'll see that we impose some interesting bandwidth limits. The idea is to make the basic use cases for individuals and teams as cheap as possible. Meanwhile, as you start growing (and so does your bandwidth and concurrency), we'll start charging proportionally to the amount of resources you use.
Our goal is to provide a realtime pay-as-you-go model, with a strong bias towards making it as cheap as possible, if not free, for those hosting Open Source projects, educational materials and much more.
And to answer your concrete question, I don't write off introducing further price reductions for individuals, as we continue to evolve our models and the underlying technology that makes our dynamic resource sharing possible.
Just to note: I don't think
now is too expensive at all. John Lindquist is completely right when he says that
now offers too much for its value. I suppose I was asking for a plan based on the open source plan where the only difference is to be able to use custom domains.
Why did you decide to make ZEIT/now? Is it because you were frustrated with the existing Node.js deployment solutions?
Many reasons. On one hand, I believe that the fundamental action of "launching" an application has to be as frictionless on the Cloud as it is on Mobile or Desktop. That's the mission of the company.
When developing products or APIs, I was really frustrated with how long everything took. Managing packages, containers, registries, images, certificates, DNS records, scaling groups, load balancers. There had to be a more adequate abstraction.
We realized that if we set up the boundaries of the HTTP protocol as our constraint, we could dramatically simplify a huge part of the paradigm. If you could imagine the Cloud as one big computer, Now is the CPU. The hard drive can be S3 and the memory Firebase, for example, for many applications.
We want to move that build step to the cloud so that you get reproducible deployments very quickly.
Are you guys considering adding benefits for students via the GitHub Student Developer Pack?
Absolutely. This is a request we get quite a bit and I also touched on briefly when answering Stephan de Vries's question.
One of our missions is to make student, research, OSS, non-profit accounts completely accessible. We think the Cloud can do a lot to further those use cases.
You can definitely expect to hear news about this in 2017.
What do you think is the next big thing after React? Web standards and web components?
In my article "Pure UI" I mentioned that a really interesting thing about React is that for the most part it shifted the discussion away from frameworks and features and towards programming models and how we reason about and scale our projects.
This set up the trajectory of the community in a very healthy path. With React came the discussion about Flux and state stores. With all the research around Flux came Redux. Simultaneously we have members from the React community rethinking how we design our APIs and backends with GraphQL.
And this brings me to the answer to your question. React was a revolutionary way of thinking. The Web Platform, and standards in general, are evolutionary.
As such, I expect the "next big thing" to almost never come from a platform burdened with browser compatibility issues, RFCs, GitHub issue drama, artificially encumbered mobile browser competition, etc. I expect it to come from a private company faced with lots of interesting and novel problems and very strong user demands and economical pressures.
But that also provides balance! The moments I've been the most productive in my life is when I master a tool or conceptual framework and I create new things with that tool over and over and over again.
This is why with ZEIT we created Next.js (https://github.com/zeit/next.js). We think the React programming model combined with some of the strengths of what the "PHP way" had given us will give us a very strong productivity (and therefore economical) advantage for years to come.
First off, everything you've put out so far is amazing so thank you for that!
- Micro is great, but it feels like it could benefit from some kind of system for managing a collection of services. For instance, if I made changes to multiple services used by my front-end, deploying to now would give me new URLs for each and I would then have to go update my front-end references to these services. Is there a recommended tool/workflow for handling this or is there something in the works?
- The only thing "missing" from the Zeit ecosystem for deployment is a data solution. Are there any plans for some kind of hosted data persistence solution
1) We already put out https://github.com/zeit/micro-cluster as an interim solution. Thanks to
Dockerfile, you can also deploy and scale services like Nginx to front your microservices. We definitely want to and will make this process easier
2) We don't think there's such a thing as a "general data solution", only offerings with different tradeoffs in latency, power, replication capabilities, etc. Our intention is to make the process of setting them up and understanding their capabilities and tradeoffs extremely smooth.
How did you calculate your pricing model? You appear to provide way too much value for what you charge, so I worry that you're not making enough to stay in business...
I answered this on the top question by Stephan de Vries. The bottom line is that we need to remain very aware of usage patterns, and adapt our technology accordingly. This is why the plans we offer already include some bandwidth limits that we think typically correlate with higher usage.
In the brief period that we've been online we've learned a tremendous amount already about the different types of users we have. We look forward in the coming months to providing plans that fit each use case very well "out of the box", in combination with a realtime pay-as-you-go model whenever you go over the limits or stipulations that you had.
This gives us the ability to account for "one-off events" for individuals (like John Lindquist's website is featured on Reddit and Hacker News for 1 day), and at the same time accommodate for the large traffic demands of bigger organizations.
Will you provide an integrated solution for persistent storage for databases, to e.g make deploying simple MongoDB instances without the need for external services?
We think the problem of dynamically scaling and distributing stateless HTTP/2 services is extremely interesting and has originated a number of very novel solutions on our end.
There's a lot to do in this space yet and that's why we've been focusing strongly on that.
- How do you decide what to do next?
- Some words about your UX/DX process?
- What help you to keep focus?
- Can you give some details about 'now' backend (arch, design, etc..) ?
1) We have a roadmap in our minds that covers a big spectrum of use-cases and possibilities for the future. At the same time, we're constantly listening to our customers and addressing their most pressing needs.
One "trick" that I use is that I tend to give priority to limitations that constitute "dead-ends" to our customers.
For example, imagine that Now didn't support Dockerfile deployments. The one day that you need to build Node.js from source with a forked version of V8 to address some pressing business need, you and your team would be completely blocked.
Therefore, since there was no "escape hatch", that takes priority over everything else.
2) A lot of it I covered in my essay Pure UI. I try to think as much as possible as a designer and then work my way backwards to the technology.
3) I'm completely in love with what we do and our mission, and every single day we hear words of gratitude and support from our customers. That keeps us going strong.
4) This would be best reserved to an AMA of its own. We use a very wide range of programming languages, open source and proprietary technologies.
What should I avoid hosting on "now"? Docker opens up so many possibilities, but I know persistent storage is not provided.
You can host everything! As I said to Stephan de Vries, you get the freedom to pick the best persistent storage solution for each problem.
In the future we look forward to simplifying the process of incorporating those solutions. To this end we launched our "secrets" support, and you can expect some interesting features there for making their provisioning much easier :)
I would like to thank you for all the projects you have initiated, i insanely love now, next, hyper and serve too! I was wondering, you contribute to OSS a lot, and that's excellent! but, how do you get money incomes? only through now plans? do you plan to launch any other software for profit? thanks and regards!
We are first and foremost a cloud hosting company, and that's our source of revenue.
All our OSS work is about sharing our favorite internal tools, and we do it because we think Googling our own documentation is better than GitHub search :P Among many other reasons, of course!
Why the logo is upwards triangle?
Simultaneously aiming at the cloud and the skies, and the mathematical symbol of "delta", which points to some of our interesting features:
- Immutability. Each deployment is simply the delta of your previous one. You can go back and see the evolution of your cloud over time
- Realtime. We show you the logs right away, we do everything possible to start up your process(es) right away, we even give you a working URL within 900ms on average!
I'd like to understand how your company works financially. You do a lot of great things and I wonder how you actually pay your bills. Can you share some details on how you structure your time and the time of your employees?
The default behavior of Now is that your code is open-source unless you upgrade. This provides a very big incentive for teams and companies to move onto the next tiers.
In addition, many of our largest customers have very specific feature requests, such as machine isolation (single-tenancy), certifications, logs replication, 24/7 support, realtime insight into metrics and auto-scaling events, and much more.
Have you thought about releasing a GraphQL version of your API?
I'm excited about the latest blog post about using
now.json to customize the deployment. Can you talk more about future plans for
now.json and how many knobs you guys plan to expose to us? For example, I'm particularly interested in controlling how
now scales my deployment. Thanks.
As a team, how do you balance OSS developments like hyper or next.js and your main product needs?
This is a great question. I want to make our OSS development sustainable, responsible and predictable. I wrote our "policy" on the subject as a result: https://zeit.co/blog/oss
Some of the most important principles are:
- It has to have demonstrated its value within the company. The project should almost be in a "desperate need" to be open source. This happened to us with Next.js, for example. We were building quite a bit of internal documentation. I wanted to set that free. I find myself learning from the community now! We've had a lot of great help, insight and ideas via GitHub issues and the likes
- The software we open source has to have a small and limited yet extensible surface. A trick for accomplishing this is focusing on components (like Next.js) or plugins (like Hyper). This takes away a lot of the burden from maintainers, and also at the same time puts the community "in charge". It's a great balance. Moving forward, I'm skeptical of projects that don't meet this criteria and likely won't open source any, unless they're small components and such.
Zeit and the Zeit team is amazing! It seems some of you have children/ families? How do you all balance your family life and work life? Thank you.
You seem to have people working from all around the globe. Do you have physical office(s) or do all work from home? How has it worked out?
We all work from home which is awesome you don't have to have a crowded commuter train in Japan, where I live :D What the most wonderful thing I think is you can work with great people all around the world without geographical restrictions.
Can you provide more information about how you scale? If I have a micro service that need a lot of CPU but don't get a lot of traffic, will you scale according to CPU or traffic ?
I would also love to know what you are doing for service discovery?
And thanks for your work!
From the get-go, I wanted Next.js to resemble "vanilla CSS" as much as possible. It took me a while to come up with the exact implementation (styled-jsx), and in the meantime I personally liked Glamor best.
So what we settled on is to embrace all CSS-in-JS systems. I think if I were to pick one from scratch today I'd use Glamor or Styled Components. Styletron has features of both and I like it as well.
At the same time, I think inline styles are also super powerful (in their simplicity!) and work amazing well for most use cases.
As a final note: CSS is actually a very nice syntax. I find that I'm really productive writing CSS! It's nice when the selectors don't leak and you can use it within component boundaries.
do you have any plans to offer in-house
now for companies, which cant host their code on someone's else servers?
What are your thoughts on Functions as a Service? Lambda seems to be falling a bit behind in terms of their modern-ness - they're still using early 4.x. Do you see Lambda-like services springing up, or will Lambda be where the majority of FaaS for Node.js lives?
I believe strongly on building on top of open standards. I appreciate the Lambda solution, but the power of Now is in its ability to host everything with almost no new APIs.
Dockerfile and HTTP/2 or WebSocket as an API cover a huge array of usecases for Cloud and IOT.
Any chance you might have an in-between plan in the works for those who don't mind OSS restrictions (public folder, etc) but would want custom domains or more deploys?
Considering you have such an international team of GREAT people, what do you think of Trump increasingly closing borders of America? How do you feel Trump's politics affect digital business?
In a way, the very thing that brings down the ▲ZEIT team together is the Cloud.
We're all from different countries, cultures, religions and only one of our members has English as their first language.
The reason for this is that the Cloud, which is what connects us, outpaces Land. Land has a very high translation cost for us: everything from airport security (and subsonic aircraft :P) or traffic jams, to not having the desire to walk away from our growing children or aging relatives every single day.
The company itself is incorporated in Delaware and the main office based in San Francisco. I'm extremely grateful for this country which has welcomed me as an immigrant and connected me with all the wonderful people that have made ▲ZEIT possible.
I'm convinced that the whims of a particular leader or epoch won't prevent us all from connecting and fulfilling our dreams, both on Cloud and Land. I want our leaders to re-consider their views on immigration, but I also urge you to not let any given politician halt your dreams. If the land is blocked, take your dreams higher, in the meantime.
Thanks for all amazing OSS projects, you are releasing.
question is: do you have any plan to improve database aspect of
Could you explain a little (or preferably, in detail) how Now works under the hood? Are you using Amazon ECS? Lambda? Custom solution? Where is the user code ultimately running and how do you scale it?
You've made an impressive product, with a breakthrough concept.
While you're building this awesome thing there's a lot of people, though enthusiastic, that are flooding you with new requests, from doable to totally out of zeit's world.
How do you guys cope with that? Do you stay true to your initial idea or are considering disrupting part of the roadmap?
This is definitely one of the most important battles to fight. Saying "no" is difficult yet absolutely critical. It can even result in anxiety in the short term because you think you might be missing out.
My coping mechanism is to remind myself of the very fundamental underlying challenges and opportunities that very few companies, if any, have been able to optimally solve, even with the existing subset of functionality.
There's a whole universe to be explored within these constraints.
What are your thoughts on Elm and PureScript?
The neat thing about learning those systems is that they have a lot of transferrable wisdom and ideas. Sure, sometimes those ideas don't transfer directly as boundaries within the code, but they can exist within your head as you architect your software.
So, while we haven't really used Elm and PureScript directly (yet!), I'm very grateful for having been exposed to them and their associated ideas.
Micro looks amazing !! DId you guys have plan to provide real world examples / tutorials /documentations for it ?
We plan to invest quite a bit on improving the README for micro (Tim Neutkens is leading that project) to feature examples (like Micro + GraphQL), screencasts and more.
Also check out:
What is the "internal joke" about tag?
Is there any plan to support account switching for now-desktop? i personally like to separate projects for clients and personal projects with different accounts/subscriptions, but the switch process is kind of cumbersome now
How do you all make such awesome products? 😀
But on a more serious note, what's next for
now? You've already got support for static sites, Node.js, and Docker, so where is the service expanding to next?
Performance, reliability and scalability. We measure every single detail of the system pretty obsessively, and we have a lot of really big improvements coming. I'm excited about all the features that are coming without breaking the contract at all. Faster and better, with one command all the same.
Do you have any plans to bring Now, as a platform, (NaaP?) to a larger business audience - i.e. large companies and Enterprises?
Do you deliberately practice your skills? If yes which ones and how?
What are your plans for Zeit moving into the future? 🕵️
What do you think it's the future of now-desktop? Do you plan having a some UI to allow handle multiple deploys, with their aliases?
will you do something to increase the file size limit of the static assets(fonts, images) in Now.sh?
You are creating amazing products !
- If the now containers is spread around the world and I want to work with AWS RDS or another DBaaS, what is the correct region I should choose to have the lowest latency? why?
Have you thought about a free tier (non-OSS) that lets developers of small projects use the system for awhile while developing? Perhaps you could disable the CDN features, only have one data center, ... disable some other things that aren't required in development/testing but are required for production?
As others have said I'm impressed by what you've done and want to do more, but I can't convince myself that I need to spend another $15/month until it's in production. And then when it's in production $15/month seems too cheap!