Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Launch HN: Nullstone (YC W22) – An easier way to deploy and manage cloud apps

news.ycombinator.com

Post reply on HN
Print view View original

41–50 of 67 posts

Re: Launch HN: Nullstone (YC W22) – An easier way to deploy and manage cloud apps

#41

Post by josegonzalez »

pelagicAustral wrote: post #28

Congrats on the launch... tbh, I have tried so many alternatives to this issue (as a Rails dev) and 'til today, I still find the oddest one of the all to be the only one straightforward enough to match the Heroku paradigm, that would be Hatchbox (which only dwells with Rails deployments). I will give this a shot, but I'm skeptical. Also, I want to thank the Dokku team, since recently I tried a few deployments and whi…

Dokku Maintainer here.

I'd love to get feedback from you on things that weren't great with your recent Dokku experience. If you want to shoot me a message, hit us up on discord/slack, or file a ticket on our github issue tracker, please do!

https://dokku.com/docs/getting-started/where-to-get-help/

Re: Launch HN: Nullstone (YC W22) – An easier way to deploy and manage cloud apps

#42

Post by krishadi »

ssickles99 wrote: post #35
krishadi wrote: post #30

I am looking for a service that helps me orchestrate the deployments of docker containers in AWS. These containers run Python workloads, but are not web-api endpoints. I want to be able to deploy them programmatically and, pause them if they've been idle (something like what supabase does). Is this something you are looking to provide? From a quick glance at your docs, it seems that you are mainly focussing on web fa…

Nullstone does support this use case, all applications are private by default. In order to make them public, you would add a Load Balancer, CDN, or Api Gateway. In your case, just don't add this and your application will remain private. We don't currently support the automatic pause of applications due to inactivity. However, we do support starting/stopping your app via the UI, API, or CLI.

Cool, could you point me a link to the API for deploying, starting, stopping the app?

Re: Launch HN: Nullstone (YC W22) – An easier way to deploy and manage cloud apps

#43

Post by krishadi »

codegeek wrote: post #31
ilrwbwrkhv wrote: post #3

These look all the same. I honestly don't know how people choose one over the other. It's like roulette, gotta pick a random one.

It is interesting that YC has invested in many of these similar PaaS already and they keep doing it. Some names that I have come across (all are YC backed): - Nullstone - Aptible - Porter - Flight Control - Fly.io I have a feeling I am missing more.

Do they all use the same IaC (guessing Terraform..) under the hood?

Re: Launch HN: Nullstone (YC W22) – An easier way to deploy and manage cloud apps

#44

Post by CharlieDigital »

krishadi wrote: post #39
CharlieDigital wrote: post #32

Earlier quoted context omitted.

Check out AWS Copilot CLI: https://aws.github.io/copilot-cli/ This is by far the best way to deploy compute into AWS in containerized workloads. The abstraction you want is Jobs: https://aws.github.io/copilot-cli/docs/concepts/jobs/ Building this any other way on AWS would require provisioning multiple artifacts. The Copilot Jobs abstraction basically encapsulates the provisioning of those artifacts into one repeatab…

AWS Copilot has been great for deploying `services`. But I wasn't sure if the `jobs` were what I was looking for, since they are event triggered. I'll test it our now. Essentially I'd like to build a docker image of code from a repository, and deploy and run it, and manage its lifecycle. Perhaps I could copy the CF template from the Copilot to do the same.

> Essentially I'd like to build a docker image of code from a repository, and deploy and run it

Presumably, you're running it based on some input. Jobs are the right paradigm if this input is periodic (for example, processing a batch of items in S3 every few hours).

Otherwise, you may want to consider a Worker: https://aws.github.io/copilot-cli/docs/concepts/services/#wo... which can be connected to an SQS queue and activated by publishing messages to the queue.

Lifecycle management is a matter of using the delete commands:

    svc delete
    job delete
    env delete
    app delete
To de-provision.

https://aws.github.io/copilot-cli/docs/commands/app-delete/

Hope that helps!

Re: Launch HN: Nullstone (YC W22) – An easier way to deploy and manage cloud apps

#45

Post by smt88 »

doctorpangloss wrote: post #23
smt88 wrote: post #16

Earlier quoted context omitted.

Which ones deploy to your own cloud accounts?

Kubernetes is kind of the intellectually honest, logical end point of this stuff.

That's like saying hammers are a logical end point of trying to get carpentry work done.

Kubernetes is an incredibly useful tool, but it needs at least one layer of abstraction (possibly multiple) on top of it to make it useful for the typical company that isn't doing anything out of the ordinary.

Re: Launch HN: Nullstone (YC W22) – An easier way to deploy and manage cloud apps

#46

Post by ssickles99 »

krishadi wrote: post #42
ssickles99 wrote: post #35

Earlier quoted context omitted.

Nullstone does support this use case, all applications are private by default. In order to make them public, you would add a Load Balancer, CDN, or Api Gateway. In your case, just don't add this and your application will remain private. We don't currently support the automatic pause of applications due to inactivity. However, we do support starting/stopping your app via the UI, API, or CLI.

Cool, could you point me a link to the API for deploying, starting, stopping the app?

We don't have our API documented yet but here is the documentation for the CLI. https://docs.nullstone.io/getting-started/cli/docs.html

To launch your application you would use the `nullstone up` command. To tear it down you would use the `nullstone down` command. To deploy your code, you would use the `nullstone launch`.

Each of these command are just making API calls under the hood. If you want to hop on our Slack channel, I'd be glad to share the details.

Re: Launch HN: Nullstone (YC W22) – An easier way to deploy and manage cloud apps

#47

Post by ssickles99 »

krishadi wrote: post #40
bsick7 wrote: post #36

Earlier quoted context omitted.

This is something we support as well. You're correct that most of our documentation (including quickstarts) focuses primarily on web-facing apps. Our current modules support running Python jobs using Fargate/ECS and Lambda (using Docker containers or packaged zip files). Today, it is possible to pause workloads by destroying the app (nullstone down --app= ). Obviously, that's not ideal and we do have plans to support…

Gotcha, do you also provide functions to build and store docker images from a code repo?

We support auto build/deploy upon the launch of your application and then on every code commit to the branch configured. The docker image is stored in a container registry in your cloud account.

Outside of the auto build/deploy process, we don't yet support ad-hoc docker builds.

Re: Launch HN: Nullstone (YC W22) – An easier way to deploy and manage cloud apps

#48

Post by almathew »

krishadi wrote: post #43
codegeek wrote: post #31

Earlier quoted context omitted.

It is interesting that YC has invested in many of these similar PaaS already and they keep doing it. Some names that I have come across (all are YC backed): - Nullstone - Aptible - Porter - Flight Control - Fly.io I have a feeling I am missing more.

Do they all use the same IaC (guessing Terraform..) under the hood?

I work for a company on the list (Aptible), and we do not use Terraform for our customer-facing infrastructure. We experimented with that approach a bit, but I didn't love it. The primary reason I didn't love it is because Terraform itself is prone to flakiness and failures that requires a real human to clean up. This doesn't matter if you're doing it on a small scale (i.e. if you're an SRE and it's just your infra), but doing it at any large scale for customers it just didn't make sense. I do think there's likely a path forward with more flexible tools like Pulumi and CDK, but those are going to have limits in terms of what they're capable of too.

I know less than I'd like about what some of the others on that list are doing, but for a majority of them, they're heavily k8s/Nomad based (which, we also aren't that either, but it's also something we've been poking around at), which lessens the dependency on IaC after you have the initial cluster up and running. Fly.io also has a problem which I consider potentially even more interesting, which is that they run their own severs, so most IaC doesn't even make sense.

Re: Launch HN: Nullstone (YC W22) – An easier way to deploy and manage cloud apps

#49

Post by styren »

codegeek wrote: post #31
ilrwbwrkhv wrote: post #3

These look all the same. I honestly don't know how people choose one over the other. It's like roulette, gotta pick a random one.

It is interesting that YC has invested in many of these similar PaaS already and they keep doing it. Some names that I have come across (all are YC backed): - Nullstone - Aptible - Porter - Flight Control - Fly.io I have a feeling I am missing more.

- Nucleus Cloud

- Argonaut

There's probably 3-4 more at least, can't think of them now.

Re: Launch HN: Nullstone (YC W22) – An easier way to deploy and manage cloud apps

#50

Post by sungrokshim »

krishadi wrote: post #43
codegeek wrote: post #31

Earlier quoted context omitted.

It is interesting that YC has invested in many of these similar PaaS already and they keep doing it. Some names that I have come across (all are YC backed): - Nullstone - Aptible - Porter - Flight Control - Fly.io I have a feeling I am missing more.

Do they all use the same IaC (guessing Terraform..) under the hood?

Co-founder of Porter (https://porter.run) here - we do not use Terraform under the hood. We moved away from an IaC based system earlier this year to better manage our users' infrastructure distributed across multiple cloud accounts. A decision that definitely turned out to be conveniently prescient :)

With this new system, we are also able to immediately reconcile drifts that occur in our user's infrastructure, which an IaC based system did not allow us to do.

Post reply on HN