Hacker News new | ask | show | jobs
by ilrwbwrkhv 1023 days ago
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.
3 comments

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.

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.

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.
- Nucleus Cloud

- Argonaut

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

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.

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.

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.

Which ones deploy to your own cloud accounts?
(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.

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.
I built yet another similar platform with the goal to keep accounts fully isolated, while it started with preview environments only, we started handling some prod deployments too.

There are nice perks on this approach but the complexity (for us) is non-negligible.

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.

I think of kube as the new de-facto OS, just like Linux back then. Of course it needs config to make it useful for your needs but I think it's really the platform to target for the next decade at least.
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.

Qovery, Porter, and FlightControl are at least a few examples