[HN Gopher] Launch HN: Nullstone (YC W22) - An easier way to dep...
___________________________________________________________________
Launch HN: Nullstone (YC W22) - An easier way to deploy and manage
cloud apps
Hi HN! We're Brad and Scott from Nullstone (https://nullstone.io),
a developer platform to deploy and manage cloud apps and
infrastructure. Here's a demo:
https://www.loom.com/share/924b1f57ba2143eeabb43ee8cbe3fe88?....
Running your app on a major cloud provider makes a lot of things
easier, but it's tedious to configure IAM, security groups,
networking, secrets, autoscaling, health checks, zero-downtime
deployments, and more. It is also difficult and time-consuming to
release and synchronize app and infra changes across many apps and
environments. Nullstone provides an intuitive developer experience
to deploy any app--be it an API, web app, static site, or one-off
job--to AWS or GCP. We provide a simple, consistent experience for
automatically deploying to any platform (e.g., Fargate, Kubernetes,
Lambda, etc.). We provision and configure infrastructure depending
on your use case (e.g., networks, clusters, datastores, load
balancers, third-party logging providers, and much more). We offer
many features that are hard to build in-house: automatic secrets
management, GitOps, and preview environments. Everything runs in
your own cloud accounts. You own your data and we cannot access it.
Secrets are stored in your secrets manager. We support all app
types (e.g. APIs, web apps, frontends, jobs, etc.) and platforms
(e.g. containers, serverless, s3 sites, VMs, etc.). Instead of
being a black box, our infrastructure modules are open source and
you can hot-swap each module for your own Terraform. You can
automate deploys and preview environments via GitHub integrations,
CI/CD integrations, CLI, or API. All infra/deploy logs are easily
accessible through the UI, CLI, and API. We scan our modules
against compliance frameworks to provide a foundation of compliance
for your infrastructure. If there are vendors or platforms we don't
support, we provide a quick framework and open hooks to add
support. Nullstone is intended for software teams that don't want
to build an in-house platform. Our customers span many industries
and have used us to reduce cloud costs by up to 90%, provide
developer self-service, fully automate deployments, migrate to
containers, and more. Previously, we built an internal developer
platform at McKinsey (serving 300 workloads across 1000 engineers)
to solve a major pain point: engineers were building apps in weeks
only to wait months to provision and secure infrastructure (and
once provisioned, making changes to the apps was a frustrating
back-and-forth process). Later I joined a cybersecurity company and
as our team grew, I saw the same challenges: we were spending more
time configuring infrastructure than building the product. We
decided to build Nullstone because no existing solution fit our
needs. Some of the products we found were all-in-one solutions,
meaning we had to sacrifice the tooling we liked and use
infrastructure with insufficient security, compliance, and
reliability controls. Other products, built for enterprises,
provide a poor developer experience in exchange for costly licenses
and significant internal resources to operate. To provide a fully
customizable experience that is easy-to-use for developers, we had
to solve a few problems. (1) We had to present infrastructure as
code configuration in a way that isn't overwhelming, but allows for
flexibility to handle various architectures. (2) We had to insulate
developers from infrastructure-as-code errors that would confuse
them, while maintaining a level of transparency that devs demand.
(3) We had to build tooling around module development because
infrastructure takes 10x longer than app code to get feedback on
whether it's working properly. Nullstone is free for individual
use. After that, we charge $100/user/month. A user is anybody
committing code that is deployed through Nullstone. Our docs are
at https://docs.nullstone.io/ and our public roadmap is at
https://github.com/orgs/nullstone-io/projects/1/views/1. We would
love for you to try it out and give us feedback, and we look
forward to your comments!
Author : bsick7
Score : 74 points
Date : 2023-09-05 13:21 UTC (9 hours ago)
| pelagicAustral wrote:
| 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
| while there was hiccups along the way, the platform has improved
| quite a lot since the last time I tried it.
| ssickles99 wrote:
| Thanks!
|
| In terms of matching the simplicity of Heroku, I feel like
| Render is probably the closest thing to it.
|
| I'm curious, anything in particular that you are skeptical
| about?
| josegonzalez wrote:
| 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/
| bsick7 wrote:
| We appreciate the honesty, but more importantly, we appreciate
| the willingness to try another one out. We welcome your
| feedback to see where we're doing things right or wrong.
| brianfitz wrote:
| Great work and as a product guy, I find the preview environments
| feature explained on your website to be a potential game changer.
| Being able to spin up and seed environments on demand via pull
| requests keeps things very clean as I could just look at a
| particular branch in isolation without the need for fixed dev ->
| stage environments. By seeding the data, it also means I can
| "replay" the same scenario again if the developers deploy a
| change while in the review process.
| [deleted]
| nkotov wrote:
| Congrats on the launch! Are you affected in any way by the
| license changes made by Hashicorp?
| bsick7 wrote:
| Thanks! We are not affected by the license changes. We are a
| tech partner with Hashicorp which requires us to not be
| competitors. If Hashicorp ever changes this position, we have
| plans on our roadmap to support other IaC tooling.
| esilverman wrote:
| amazing progress here, very impressed
| krishadi wrote:
| 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 facing applications.
| CharlieDigital wrote:
| 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
| repeatable pattern.
|
| Fully extensible with CDK and CF if the out-of-the-box workload
| abstractions aren't enough or you need deeper customization. I
| have found that the OOB abstractions are "right-sized" for most
| common workloads and rarely require extension aside from
| occasionally IAM when integrating with other AWS services.
| krishadi wrote:
| 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.
| CharlieDigital wrote:
| > 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!
| krishadi wrote:
| Thanks a ton!
| ssickles99 wrote:
| 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.
| krishadi wrote:
| Cool, could you point me a link to the API for deploying,
| starting, stopping the app?
| ssickles99 wrote:
| 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.
| bsick7 wrote:
| 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=<app>). Obviously, that's not ideal and
| we do have plans to support pausing workloads to reduce costs.
| krishadi wrote:
| Gotcha, do you also provide functions to build and store
| docker images from a code repo?
| ssickles99 wrote:
| 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.
| nicdevok wrote:
| We've been using Nullstone for a few weeks now, and it's been
| great. Definitely speeding up our infrastructure migration plans.
| The app is great, and keeps getting better with improvements
| launched on a regular basis. The best feature has been the
| support, though. Most of my questions were answered within
| minutes, and the team knows their stuff.
| eliranw wrote:
| Your user was created 4 minutes ago just to reply this comment
| typeofhuman wrote:
| I create alts sometimes when I evangelize a company. I'm not
| always able to publicly acknowledge the inner operations of
| my employer.
| dcow wrote:
| Gotta start somewhere. A positive testimonial is awesome.
| nicdevok wrote:
| That's correct, I don't usually hang out here, but I wanted
| to support what I think it's an awesome product and team.
|
| I am a real person, and I'm not affiliated with Nullstone.
| This is me https://github.com/nicdev if you have any
| questions, feel free to reach out directly. Same username on
| Twitter/X
| ksajadi wrote:
| Good to see tools like this. However, are you not affected by the
| recent change in the Terraform licensing?
| bsick7 wrote:
| We are a Hashicorp Tech Partner
| (https://www.hashicorp.com/partners/tech/nullstone#all). This
| partnership requires that we're not competitive in nature.
|
| We have plans on our roadmap to support other IaC tooling if
| Hashicorp makes future changes to their licensing that prevents
| this arrangement.
| jmscholen wrote:
| I'll plug in my 2 cents.. and yes, I just created a new account
| to give a thumbs up because Brad and Scott have been awesome in
| helping me get a whole array of infrastructure stood up as we
| migrate away from a system that uses puppet. If you have ever
| needed to read thru the dizzying array of AWSs docs or blog posts
| about how to do this, then you will be relieved at how easy
| Nullstone makes it.
|
| They have a full suite of modules that most application can use
| out of the box to standup your infrastructure in minutes. Now
| there may be some uptime on learning the UI and how to connect
| modules together but spinning up and tearing down is easy. I just
| built a module for deploying an aurora instance that was not
| available within their registry, but with their help, I was able
| to code one up in a few hours and have it deployed before the end
| of the day.
| niklearnstodev wrote:
| Looks great, and I'm excited to try it for a personal project
| (nice free tier). It looks like it can act as the entire devops
| team for my single-person project.
| bsick7 wrote:
| Thanks! Join our community slack or message me directly if you
| hit any issues setting it up.
| dcow wrote:
| Have you considered a community Discord?
| bsick7 wrote:
| We considered Discord, but went with Slack (mainly because
| we have dedicated support channels for customers).
|
| If we provided a Discord, would that be more appealing to
| join?
| scarlson wrote:
| Voice of 1: I prefer Slack so it's closer my work comms.
| Having a shared channel with y'all is infinitely easier
| than hopping between workspaces or apps.
| doctorpangloss wrote:
| Is there ever going to be another Dropbox?
|
| B2C for developers is really something. Some junior in some huge
| org, is he going to put his AWS security credentials into a box
| and expense the $100 a month? Maybe.
|
| It seems really against trend. You're making something for ultra-
| junior developers who are going to be asking ChatGPT (or whatever
| soon-to-be vendor LLM) for a solution, which can't interact with
| UIs. And how is your thing going to have more representation in a
| dataset than a docker compose file or whatever hackneyed idea is
| simple enough for this user to adopt?
|
| > We offer many features that are hard to build in-house
|
| I am just saying you should try asking ChatGPT with GPT4 for
| examples before you make this the premise. What was once super
| arcane is now just another blob of opaque bullshit Berkeley CS
| '23 is going to be copying and pasting into somewhere.
| bsick7 wrote:
| Thanks for the feedback!
|
| I do think that AI is going to have a massive impact on
| development including cloud infrastructure; however, we rarely
| see junior developers setting up cloud infrastructure because
| it is dangerous.
|
| Our motivation is to make the cloud easier for all skill
| levels. In many organizations, this usually requires platform
| engineers or lead engineers that determine what works best with
| their technical strategy.
|
| Our goal is to (yes, remove the arcaneness), but also remove
| the tedium and distraction from development.
| doctorpangloss wrote:
| > we rarely see junior developers setting up cloud
| infrastructure because it is dangerous.
|
| So whom is this for?
|
| Doesn't this set up cloud infrastructure? Dangerous how
| exactly?
|
| It's not a tautology. Someone who can't handle like, using
| AWS directly, is a junior developer.
|
| Another perspective is the founderese is not very reassuring.
| bsick7 wrote:
| Sorry for the confusion. It's dangerous for junior
| developers to interact directly with cloud providers. Our
| motivation is to provide guard rails for developers of all
| skill levels to build and run their infrastructure without
| exposing their organization to risk.
|
| Here are some dangers we've seen from our customers: -
| Misconfigurations that result in no backups, disabled
| encryption, etc. - Resources accidentally configured with
| Internet access - Exposing internal secrets or credentials
| in source code - Misconfiguration of IaC that results in
| destruction of databases
|
| I'm not claiming that we have eliminated these dangers.
| Instead, our goal is to provide a platform for software
| teams to codify their security and compliance practices so
| that all developers on their team can avoid these dangers.
| ilrwbwrkhv wrote:
| 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.
| codegeek wrote:
| 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.
| intelVISA wrote:
| Can't blame them really, wrapping a few AWS calls in $lang
| and pitching it to VC as a "disruptor" is a decent techbro
| playbook. Don't hate the player, etc.
| styren wrote:
| - Nucleus Cloud
|
| - Argonaut
|
| There's probably 3-4 more at least, can't think of them now.
| krishadi wrote:
| Do they all use the same IaC (guessing Terraform..) under the
| hood?
| bsick7 wrote:
| As other replies have mentioned, Terraform is challenging
| to create a smooth experience. We have spent many cycles
| working on smooth orchestration so that it's fast and
| intuitive. Our primary motivation was to avoid hiding
| infrastructure behind proprietary technology.
|
| We have support for other IaC tools on our roadmap so that
| each team can use what is comfortable.
| almathew wrote:
| 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.
| sungrokshim wrote:
| 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.
| smt88 wrote:
| Which ones deploy to your own cloud accounts?
| doctorpangloss wrote:
| Kubernetes is kind of the intellectually honest, logical end
| point of this stuff.
| smt88 wrote:
| 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.
| bsick7 wrote:
| Kubernetes is a powerful platform. It has become a standard
| language for building and operating cloud/on-prem
| infrastructures. It _will_ be the end point for how
| infrastructure is orchestrated and configured.
|
| However, Kubernetes is more a primitive for infrastructure
| rather than a tool to build automation workflows for
| software teams. Our focus is to complement teams that may
| or may not choose Kubernetes.
| zoomzoom wrote:
| (I'm the cofounder of Coherence)
|
| I consider the "best-in-breed" tools with this shape to break
| into the following categories:
|
| "Infra Abstractions": DuploCloud, Massdriver, Stacktape "PaaS
| in your own cloud": Nullstone, Zeet, Quovery, Porter,
| Architect.io, FlightControl "SDLC Platform for Teams":
| Coherence (withcoherence.com) - the key difference here is in
| how CI/CD (incl integration tests) are handled, how
| development environments are configured alongside other
| environments, and how production is segregated from other
| environments.
|
| This a somehow both a crowded space and an emerging one. But
| we believe that even with the diversity of choice that there
| are clear reasons that most teams will by (vs. build) their
| internal dev platform in the future: namely the cost to buy
| vs. to build/maintain, and the productivity from better
| tools.
| 408user wrote:
| We are from DuploCloud and hence the following note might
| be biased. The downside of a pure paas solution like
| porter, Quovery at al. is that they have a limited scope
| say kubernetes, pieplines and diagnostics. All of the lower
| layers of the Devops stack from IAM, networking, AWS
| services (including non containerized workloads like
| Lambda, EMR, Airflow etc), scores of compliance and
| security controls are left out of scope. Then one needs a
| expert Devops to write boat loads of TF. Our apporoch is of
| a E2E platform that should do all of what a human devops
| manually scripts. Thus fundamentally deliver self-service,
| labor reduction and compliance.
| ssickles99 wrote:
| Qovery, Porter, and FlightControl are at least a few examples
| ssickles99 wrote:
| Yes, there are a lot of PaaS and Developer Platforms out there
| to choose from. In my past roles leading development teams, I
| always found it hard to make existing solutions fit because
| they were too black box and I couldn't customize or add the
| things I needed support for. I also had security and compliance
| considerations that were difficult to navigate because I wasn't
| in control.
|
| The things unique to Nullstone are: 1. Nullstone launches
| everything to your cloud account. You keep full ownership of
| your data. 2. 100% of the infrastructure is launched using
| modules. You can add your own or customize the out-of-the-box
| modules to support whatever your use case. 3. Many other
| solutions just handle your apps (no databases or other
| infrastructure). Nullstone supports launching apps, datastores,
| any cloud managed service, and integrations with tools like
| Datadog, Twilio, Sendgrid, and more.
|
| Hope that gives you an idea of how we differ from other
| solutions.
___________________________________________________________________
(page generated 2023-09-05 23:01 UTC)