8 ms·

Universal Now: Now, on Every Cloud

206 points by sorenbs 9y ago

cstpdk 9y ago
Bad luck to announce support for `every cloud` the day alibaba cloud reaches the frontpage
- deleted 9y ago
  [deleted]
thebiglebrewski 9y ago
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. But it is a really cool thing.
- thangngoc89 9y ago
  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
  - thebiglebrewski 9y ago
    I've also done this with Dokku specifically and it was really cool. The project has probably matured a lot since then (8+ months ago) but...I do have a pretty high level of trust in Heroku that's been hard to erode. (Waiting for all the comments saying I shouldn't have that trust in t-minus...)
    - thangngoc89 9y ago
      Yep. Dokku is another option since you've work with Heroku before. But Heroku is so expensive.
- djsumdog 9y ago
  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.
  - luke3butler 9y ago
    "Aside from "Function as a Service" providers, we also are working hard on bringing the Now experience to container management solutions such as Kubernetes. These systems provide a lot of power to their administrators, but typically don't offer a great "last mile" experience for product developers and designers." I'm looking forward to this.
thangngoc89 9y ago
I must say that this sounds exactly like TJ's Up blueprints [1]. TJ've been working on Apex Up for over a month [2]. [1]: https://medium.com/@tjholowaychuk/blueprints-for-up-1-5f8197179275 https://medium.com/@tjholowaychuk/blueprints-for-up-1-5f8197... [2]: https://github.com/apex/up https://github.com/apex/up
- tjholowaychuk 9y ago
  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".
  - juancampa 9y ago
    > Funny thing is it doesn't even follow best practices, they clearly don't have much experience in the space Do you mind elaborating on this?
    - tjholowaychuk 9y ago
      All of their resource management for DNS, certs, domains, etc is done using sub-commands which are not reviewable. Sure they can have an audit trail of events, but Terraform/CloudFormation are industry standard now, as changes can be easily previewed and reviewed by peers. Single-command deploys are cute, don't get me wrong, but it's ultimately a gimmick. It's great for solo or small teams, but for larger teams, they'll ALWAYS use CI, and they'll ALWAYS want to restrict damage that a single team member can do to the infrastructure. There's nothing novel about single-command deploys. Hell at Segment we had "/deploy blog" in Slack for the simple cases that we weren't worried about, tons of companies do this stuff. Most at very least have git -> CI deploys which is a more correct way to do things for real teams.
zitterbewegung 9y ago
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.
- deleted 9y ago
  [deleted]
pseudobry 9y ago
> 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 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-emulator https://github.com/GoogleCloudPlatform/cloud-functions-emula... [2]: https://github.com/googleapis/googleapis/blob/master/google/cloud/functions/v1beta2/functions.proto https://github.com/googleapis/googleapis/blob/master/google/...
conceptpad 9y ago
Zeit is simplifying product development and delivery in a very tasteful way. Thank you and keep going!
dvcc 9y ago
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?
- luke3butler 9y ago
  This surprised me too, but it looks separate. You log in directly to GCP or AWS.
- arunoda 9y ago
  (I work at ZEIT) 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 :)
- deleted 9y ago
  [deleted]
deleted 9y ago
[deleted]
nikon 9y ago
Worth noting the pricing [0] [0]: https://zeit.co/pricing https://zeit.co/pricing
- luke3butler 9y ago
  This is only if you deploy to their servers. Other cloud providers are completely separate.
  - nikon 9y ago
    Nice. My bad. Realised it's actually open source!
deleted 9y ago
[deleted]
davidjnelson 9y ago
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? Edit: Autocorrect fix
efgrbgfrf 9y ago
hi hows it going Sergio BenitezSergio BenitezSergio Benitez
DonbunEf7 9y ago
I use Nix and NixOS and nixops. What can `now` do for me?

206 points by sorenbs 9y ago

cstpdk 9y ago

Bad luck to announce support for `every cloud` the day alibaba cloud reaches the frontpage

deleted 9y ago
[deleted]

thebiglebrewski 9y ago

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. But it is a really cool thing.

thangngoc89 9y ago
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
- thebiglebrewski 9y ago
  I've also done this with Dokku specifically and it was really cool. The project has probably matured a lot since then (8+ months ago) but...I do have a pretty high level of trust in Heroku that's been hard to erode. (Waiting for all the comments saying I shouldn't have that trust in t-minus...)
  - thangngoc89 9y ago
    Yep. Dokku is another option since you've work with Heroku before. But Heroku is so expensive.
djsumdog 9y ago
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.
- luke3butler 9y ago
  "Aside from "Function as a Service" providers, we also are working hard on bringing the Now experience to container management solutions such as Kubernetes. These systems provide a lot of power to their administrators, but typically don't offer a great "last mile" experience for product developers and designers." I'm looking forward to this.

thangngoc89 9y ago

I must say that this sounds exactly like TJ's Up blueprints [1]. TJ've been working on Apex Up for over a month [2]. [1]: https://medium.com/@tjholowaychuk/blueprints-for-up-1-5f8197179275 https://medium.com/@tjholowaychuk/blueprints-for-up-1-5f8197... [2]: https://github.com/apex/up https://github.com/apex/up

tjholowaychuk 9y ago
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".
- juancampa 9y ago
  > Funny thing is it doesn't even follow best practices, they clearly don't have much experience in the space Do you mind elaborating on this?
  - tjholowaychuk 9y ago
    All of their resource management for DNS, certs, domains, etc is done using sub-commands which are not reviewable. Sure they can have an audit trail of events, but Terraform/CloudFormation are industry standard now, as changes can be easily previewed and reviewed by peers. Single-command deploys are cute, don't get me wrong, but it's ultimately a gimmick. It's great for solo or small teams, but for larger teams, they'll ALWAYS use CI, and they'll ALWAYS want to restrict damage that a single team member can do to the infrastructure. There's nothing novel about single-command deploys. Hell at Segment we had "/deploy blog" in Slack for the simple cases that we weren't worried about, tons of companies do this stuff. Most at very least have git -> CI deploys which is a more correct way to do things for real teams.

zitterbewegung 9y ago

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.

deleted 9y ago
[deleted]

pseudobry 9y ago

> 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 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-emulator https://github.com/GoogleCloudPlatform/cloud-functions-emula... [2]: https://github.com/googleapis/googleapis/blob/master/google/cloud/functions/v1beta2/functions.proto https://github.com/googleapis/googleapis/blob/master/google/...

conceptpad 9y ago

Zeit is simplifying product development and delivery in a very tasteful way. Thank you and keep going!

dvcc 9y ago

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?

luke3butler 9y ago
This surprised me too, but it looks separate. You log in directly to GCP or AWS.
arunoda 9y ago
(I work at ZEIT) 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 :)
deleted 9y ago
[deleted]

deleted 9y ago

[deleted]

nikon 9y ago

Worth noting the pricing [0] [0]: https://zeit.co/pricing https://zeit.co/pricing

luke3butler 9y ago
This is only if you deploy to their servers. Other cloud providers are completely separate.
- nikon 9y ago
  Nice. My bad. Realised it's actually open source!

deleted 9y ago

[deleted]

davidjnelson 9y ago

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? Edit: Autocorrect fix

efgrbgfrf 9y ago

hi hows it going Sergio BenitezSergio BenitezSergio Benitez

DonbunEf7 9y ago

I use Nix and NixOS and nixops. What can `now` do for me?