Launch HN: Nucleus (YC S22) – Kubernetes platform for both devs and ops
It's expensive, time-consuming, and technically difficult to build a secure, scalable Kubernetes platform. Yet many companies that do this spend 6+ months building it themselves and then hire an expensive platform team to manage it. We've talked to customers who have spent $1.5M to build something that isn't their core product.
On the technology side, you have to solve for authentication, authorization, service registry and discovery, scalability, observability, infrastructure and more. Most teams end up stitching together a bunch of OS tools and cloud primitives just to end up with a fragile system that’s difficult to maintain as it grows. On the people side, it’s difficult and expensive to find developers and devops engineers who deeply understand Kubernetes and distributed systems. When they leave, tech and process documentation is incomplete, hard to find and often outdated.
Nick and I have been building infrastructure platforms for the past 7 years at companies like NewFront, Skyflow, IBM and Garmin. Companies like ours were spending a lot of time and energy in building internal developer platforms from scratch and then hiring expensive teams to maintain them. These were important platforms but never the companies’ core product. It seemed crazy to us that a series A company would have 2-3 developers spend 6+ months building something that wasn't their core product. We felt like there had to be a better way.
We’re building a platform that accomplishes 4 things: (1) Reduce the time it takes to spin up Kubernetes environments and services; (2) Provide an intuitive developer experience that simplifies working with Kubernetes; (3) Empower devops and platform teams to automate manual tasks and enable developer self service without spending months building infra; (4) Centralize, organize and be a source of truth for infra-related configurations, processes and documentation.
To get into the architecture a bit, you can think of Nucleus as three layers:
At the bottom layer, we build and manage pre-configured Kubernetes clusters in your AWS accounts. We install different add-ons into the cluster that enable key functionality such as security, autoscaling and metrics. You can find a full list in our docs - https://docs.nucleuscloud.com. The idea is that you can run Nucleus on autopilot without needing to be a Kubernetes expert. That said, many engineers want access to kubectl, so we make it easy to provision different user-profiles with different access to kubectl via an IAM role.
The next layer up is the service mesh layer. We built on top of Istio to implement things like authN, authZ, service discovery and registry. We were also really inspired by this blogpost from the neobank Monzo (https://monzo.com/blog/2022/03/31/how-we-secure-monzos-banki...). Each cluster has a dedicated load balancer that sits in a public subnet while the cluster and services are in a private subnet. Communication between these services uses mTLS. Private services are, by default, isolated and can’t talk to any other service unless you explicitly authorize it. We make that as easy as passing in the service name. This is all automated and transparent to the end-user. We’re soon going to be coming out with more features ...
43 comments
[ 3.0 ms ] story [ 100 ms ] thread- Who is your target customer?
- How does it compare to OpenShift?
- Can you bring your own Kubernetes provider?
- You have nothing on your page that would make me trust you enough to give you the level of access you need to deploy. Are you pursuing any kind of partnerships with AWS or security audits?
acorn.io ambassador architect brev.dev builder.ai buildkite.com bunnyshell circleci cloudbees.com codespaces crafting.dev cycloid.io d2iq.com dagger.io depot.dev devzero ergomake.dev facets.cloud flightcontrol.dev floxdev.com fly.io garden.io getport.io gitpod gradle harness.io hop.io kurtosis.com lambdalabs.com loft.sh massdriver netlify nomadproject.io nullstone.io oatfin.com okta okteto opsera.io porter.run quali.com rafay.co raftt.io railway.app refcetl.run release.com render.com replit.com reploy roost.ai shipyard signadot.com styra.com tesorio timoni.io tsuru.io tugboat uffizzi.com vercel.com vivun webapp.io withcoherence.com
Also, you missed out my company, argonaut.dev :-)
https://diggerdev.notion.site/DX-platforms-for-your-cloud-ac...
PS. This space is super competitive. One of the things I have noticed is that the life of an organisation using a platform like this is very short. For example, a startup might use this right away to become compliant and stuff, but once they mature and hire devops engineers, which they will when they hit PMF, they will plan a migration out of your platform.
I am wondering how you are planning to counter this behavior.
[1] https://github.com/debarshibasak/awesome-paas
1. Continue to build out integrations across the toolset. For ex. we provide a built-in CI/CD pipeline but know that most mature orgs will want to use Jenkins/Argo/Github Actions etc. so we are building out those integrations (have Github already). Our goal is to give customers an onramp to get started and then once they mature, have the integrations ready for them to easily adopt the tools they care about.
2. Continue to expand the platform into other areas of the service layer. We're working on building out a service cataloguing module and testing module to make it easy for teams to understand what services they have, who owns them, scorecards etc. and to test them. The goal is to expand across the service layer vs. up and down the stack (DB or front-end layer).
If you want to deploy a handful of services, databases, caches, queues, inside of a single private network, with load balancing, security, deployments, per-environment (versioned) config, rollbacks, blue/green deploys, etc... it is not trivial. It's easy for me because I have been building this stuff for the last 15 years, but I also get sick and tired of reinventing the wheel all the time.
My team and I built an internal PaaS on Kube to power Farmlogs back in 2016. This experience had a tough initial learning curve, but ultimately paid off bigtime and gave me the assurance that yes kubernetes can absolutely work in production at scale reliably. But it's tough to grok and use correctly. So I've been wanting to solve the aforementioned problem for a while now.
This product honestly looks like the perfect answer. My only hesitation would be longevity ie what happens if this company fails. Ultimately I want them to manage the thing, but I also want a reproducible artifact of my entire system so that if they get hit by a bus my business isn't fucked.
It checks all the boxes for me: heroku-style ui to enable devs from different levels of experience to contribute and have visibility into the system but I bring my own AWS account and therefore ultimately have sudo access to my network and how this env might interact with other envs.
This is what I came here to ask about. Managing my infrastructure only through a UI makes me nervous. I much prefer having the source of truth for configuration be in version control. Having said that, I do love what you've launched here, and totally get the value proposition. If I could get that value without sacrificing infra-as-code, this would really speak to me.
A way this could potentially work (albeit with a pretty significant bump in complexity I think) would be for the UI to sync with an IaC repo. That is, changes through the UI would commit to the repo and need to be applied (either automatically or on-demand), and changes to the repo outside the UI would need to be sync'd into the UI.
Just a thought! Nice work on this!
Are you considering supporting other cloud providers? I'd personally always choose GCP for UX reasons, and I know there are many who choose Azure for MS reasons, or Alibaba for price/language/location reasons. I understand starting with AWS, just wondering if that's set in stone or if others are on the roadmap.
> We’ve never been big fans of the complicated pricing that most SaaS companies have so we sell Nucleus as a single annual license where you get everything. In full transparency, we currently price Nucleus around $35k/license, or about 10% of what it would cost you to build and maintain this yourself.
Having come from a startup with ~10-12 eng, in the middle of your target market, using K8S, and building tooling around it, this is substantially more than I think we'd have spent on it. Our Datadog bill for comparison was about half that per year, and our cloud bill was only ~6x that.
Our tooling for K8S was a few thousand lines of Terraform config, a few hundred line Python script, and some GitHub Actions. We spent a fair bit of engineering time on these, but not quite _that_ much. I would imagine Nucleus would have been a much nicer experience, but in reality would only have saved us ~20% of an engineer.
Maybe we weren't the target market! Just my thoughts though. Nice one with having one flat fee, I like that.
Have you considered things like per-region, per-host, per-cluster, per-active developer etc?
Not to say that we won't change our packaging and pricing down the line (we certainly will) but for now we're trying to make it easy to adopt without having to think across so many pricing axes. But we've seen pricing questions a few times in this thread - so maybe it's worth evaluating sooner rather than later.
Plus, if the argument is to hold and we assume your 'bad' devs can't somehow reinvent K8s in a week and have to buy into this managed one -- surely they're going to waste an equal amount of hours learning and breaking it?
Lunacy!!
We are definitely considering other cloud providers. I'm currently working on adding GKE support. GCP's UX is top-notch in my own experience and is a breath of fresh air when compared to AWS. We've also found a lot of startups are choosing GCP over AWS these days. This at least has been the case for many prospects we've spoken to.
What's AWS market share? Analysts say 50%, and MS at 30-35%, and GCP at 10-15%. They're wrong. The target for this service is young startups, and in that segment, AWS is still at ~90% market share.
Ignore GCP and Azure for now. Focus on AWS.
Disclaimer: I was at AWS 2008-2014, and met with thousands of startups (I am not exaggerating). Since then I kept tabs on the market. I might be wrong, but I suspect I wouldn't be by much.
In reality, when you look at okteto and others who use usage based pricing, this would be comparable to their enterprise versions. If you're a team of 10 developers and you want to use Okteto, you're paying $100/month/developer or almost $15k/year for their pro version. Bump that to enterprise and it quickly goes up from there.
I think there is a pretty large market of people who have indeed used PaaS and have concluded that the flexibility of kubernetes is worth the complexity. It's not for everyone, but it is useful for a lot of organizations.
Would more granular pricing that meters users, environments, services etc. be more appealing?
However, we can definitely be more detailed and call out specific actions that we need in those areas. That still leaves us with IAM though. I think we can still do better here to further limit IAM, but as of right now we can still do a lot if we have full access to the IAM featureset. It's something we're working on improving, but for now, I always suggest folks turn on auditing in their AWS accounts to keep ontop of anything that is happening.
My suggestion is to price this at 20% of what it would cost a customer to run it independently. Perhaps you can make it to 10% for a limited time, but make it clear that the price will go up.
Why? Because:
1) You will need the price to go up.
2) You are positioning your product in a different (better?) way.
Note that things like Amazon RDS, etc, are at about 20-25% premium on top of the tools/softwares that they automate.
Your service is currently not as mature as RDS or others, and therefore it might be right to temporarily price it at 10%, but telling customers that it will eventually go up to 20%.