Really not surprised to see rauchg [name redacted] steal more ideas for his startup from colleagues.
The entire premise of Zeit is something that I explained to him five years ago in a taxi ride. I was in active communication with Guillermo about developing the idea up until two years ago when he went silent for a month or two and I then I read the announcement for Zeit on Hacker News.
I'm sure he'll sell Zeit to the first high-bidder and completely throw the development team under the bus ( like he did to TJ at his last startup ).
If you don't believe me, you can just look at the Github activity for the Zeit organization. [name redacted] has copy and pastied the same Now project into new projects several times ( which deletes the commit logs of several contributors giving him sole Git credit for the projects ).
This was clearly rushed to get ready to compete with Up, it pretty much copies my blog post exactly in terms of implementation. Expect to see the other ideas from the repo in there soon.
As I said on Twitter, it's a CLI, literally anyone can build this. Startups have their place but in this case it's such a cowardly way to run a business.
Funny thing is it doesn't even follow best practices, they clearly don't have much experience in the space, which is evident in that they built almost nothing in two years, this is basically a hobby project.
I can't compete with free though, so congrats, best of luck with your joke of a "company".
So you're implying that Zeit has been working on this for less than that time? The idea of a universal deployment tool seems like common sense once your business already deals with deployments, and behind the scenes uses multiple providers.
Why the automatic assumption this idea was "stolen"?
> Most cloud providers have created different proprietary APIs to expose lightweight services to the cloud.
True. However, in the case of Google Cloud Platform, the Protocol Buffer definitions for their services have been open-sourced here: https://github.com/googleapis/googleapis
There are two immediate benefits/possibilities: you can generate your own gRPC client libraries for GCP services and you can re-implement GCP services using their open-sourced interface definition. One example would be the Google Cloud Functions Emulator [1], which implements the service defined in the Cloud Functions service' Protocol Buffer [2]. You could deploy that Emulator somewhere for a sort-of "dev" version of the production Cloud Functions service, and the Gcloud SDK could talk to it.
This is really cool. We're a one-man shop (me) that uses Heroku though. Even though I can get on AWS or GCP really quickly with this (but probably not because we have a Rails back-end and React/Express front-end), I wouldn't then know how to best leverage/manage it. So this is a bit of a non-starter for me.
So far I'm seeing this as useful for side projects at most. The layer isn't opaque enough where I can troubleshoot serious issues and its too new to know there won't be any. More layers add more complexity in the early stages, over time though this could get quite compelling.
Yea their every cloud is pretty limited. The world isn't limited to AWS/GCP. For VM hosting, there's Vultr, DigitalOcean, Linode. And for app hosting you have Heroku, Jelastic, et. al.
It's difficult to create something that works universally since the APIs can be radically different. Terraform is a nice attempt to plug in different hosting solutions and configuration layers (puppet, anisble, chef), but your configuration still varies pretty heavily per provider and I've often struggled with it enough that I gave up and just wrote scripts to call my providers API directly.
I'm running a one-man shop too. And I deployed many websites to Digital Ocean/Vultures with the help of Docker machine, 5 minutes from starting the VPS to the website is ready
I'm a little confused, is this basically a competing service with zeit's already-abstract 'now' deployment service? Or is this completely separate from that now service that doesn't even require a zeit account/plan?
The docs are very light on technical details. It appears for aws they are using lambda and API gateway. If so, how do you connect to a sql db that requires connection pooling?
It looks promising, but it's unclear how to use it for a real app. Perhaps the idea is you maintain a separate set of servers which talk to your db?
I saw this at the reactriot hackathon. Since it works with multiple clouds I think I will try to use this from now on. If it allows me to migrate easily there are distinct advantages especially such as lock-in.
[+] [-] thangngoc89|8 years ago|reply
[1]: https://medium.com/@tjholowaychuk/blueprints-for-up-1-5f8197... [2]: https://github.com/apex/up
[+] [-] _Marak_|8 years ago|reply
The entire premise of Zeit is something that I explained to him five years ago in a taxi ride. I was in active communication with Guillermo about developing the idea up until two years ago when he went silent for a month or two and I then I read the announcement for Zeit on Hacker News.
I'm sure he'll sell Zeit to the first high-bidder and completely throw the development team under the bus ( like he did to TJ at his last startup ).
If you don't believe me, you can just look at the Github activity for the Zeit organization. [name redacted] has copy and pastied the same Now project into new projects several times ( which deletes the commit logs of several contributors giving him sole Git credit for the projects ).
[+] [-] tjholowaychuk|8 years ago|reply
As I said on Twitter, it's a CLI, literally anyone can build this. Startups have their place but in this case it's such a cowardly way to run a business.
Funny thing is it doesn't even follow best practices, they clearly don't have much experience in the space, which is evident in that they built almost nothing in two years, this is basically a hobby project.
I can't compete with free though, so congrats, best of luck with your joke of a "company".
[+] [-] PKop|8 years ago|reply
Why the automatic assumption this idea was "stolen"?
[+] [-] randall|8 years ago|reply
[+] [-] vnglst|8 years ago|reply
[+] [-] boundlessdreamz|8 years ago|reply
[+] [-] unknown|8 years ago|reply
[deleted]
[+] [-] unknown|8 years ago|reply
[deleted]
[+] [-] endergen|8 years ago|reply
[+] [-] pseudobry|8 years ago|reply
True. However, in the case of Google Cloud Platform, the Protocol Buffer definitions for their services have been open-sourced here: https://github.com/googleapis/googleapis
There are two immediate benefits/possibilities: you can generate your own gRPC client libraries for GCP services and you can re-implement GCP services using their open-sourced interface definition. One example would be the Google Cloud Functions Emulator [1], which implements the service defined in the Cloud Functions service' Protocol Buffer [2]. You could deploy that Emulator somewhere for a sort-of "dev" version of the production Cloud Functions service, and the Gcloud SDK could talk to it.
[1]: https://github.com/GoogleCloudPlatform/cloud-functions-emula... [2]: https://github.com/googleapis/googleapis/blob/master/google/...
[+] [-] thebiglebrewski|8 years ago|reply
So far I'm seeing this as useful for side projects at most. The layer isn't opaque enough where I can troubleshoot serious issues and its too new to know there won't be any. More layers add more complexity in the early stages, over time though this could get quite compelling.
But it is a really cool thing.
[+] [-] djsumdog|8 years ago|reply
It's difficult to create something that works universally since the APIs can be radically different. Terraform is a nice attempt to plug in different hosting solutions and configuration layers (puppet, anisble, chef), but your configuration still varies pretty heavily per provider and I've often struggled with it enough that I gave up and just wrote scripts to call my providers API directly.
[+] [-] thangngoc89|8 years ago|reply
[+] [-] cstpdk|8 years ago|reply
[+] [-] unknown|8 years ago|reply
[deleted]
[+] [-] dvcc|8 years ago|reply
[+] [-] arunoda|8 years ago|reply
We just wanted to make "now" the go to tool for cloud deployments.
We've a backend for "now" and that's the pricing we've mentioned on our page. Just like that, we've providers for AWS, Google Cloud, Azure and etc.
We'll sure make "ZEIT now cloud backend" better everyday. But sometimes, we just wanna deploy to existing clouds. That's what this is about.
If you decide to deploy to AWS, you don't need to pay nothing for ZEIT.
You can also think like, this is we challenging ourself :)
[+] [-] unknown|8 years ago|reply
[deleted]
[+] [-] luke3butler|8 years ago|reply
[+] [-] davidjnelson|8 years ago|reply
It looks promising, but it's unclear how to use it for a real app. Perhaps the idea is you maintain a separate set of servers which talk to your db?
Edit: Autocorrect fix
[+] [-] conceptpad|8 years ago|reply
[+] [-] zitterbewegung|8 years ago|reply
[+] [-] unknown|8 years ago|reply
[deleted]
[+] [-] nikon|8 years ago|reply
[0]: https://zeit.co/pricing
[+] [-] luke3butler|8 years ago|reply
Other cloud providers are completely separate.
[+] [-] DonbunEf7|8 years ago|reply
[+] [-] unknown|8 years ago|reply
[deleted]
[+] [-] unknown|8 years ago|reply
[deleted]
[+] [-] efgrbgfrf|8 years ago|reply
[deleted]