[HN Gopher] Launch HN: Nucleus (YC W23) - Kubernetes platform fo...
___________________________________________________________________
Launch HN: Nucleus (YC W23) - Kubernetes platform for both devs and
ops
Hi HN! We're Evis and Nick and we're the founders of Nucleus
(https://nucleuscloud.com), a Kubernetes developer platform. We
automate infrastructure, security, integrations, and more, helping
developers ship faster while also automating a lot of repetitive
tasks for devops and platform teams. Here's a demo:
https://www.loom.com/share/95265177704346c7b379e981978cd8c5. 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
around managing load balancers and enabling blue-green deploys with
zero downtime cutovers. The top layer is our integration layer. We
provide a bunch of integrations and we're continuing to building
out more. This includes container registry tools (DockerHub, ECR,
Github), Observability (Datadog, Prometheus, Grafana), Secrets
Managers (param store), DBs (Aurora, MongoDb), and CI/CD (github
actions). The idea is that you shouldn't be spending time trying to
build integrations for each of your services, you should just
point-and-click which ones you need. We've built a permissioning
system which makes it easy to give/revoke access for an integration
to any service or environment. For example, if you want your dev
services to have access to your dev db, you shouldn't have to build
that separately for each service. You just configure it once, pick
the services or environment that needs access to and we
automatically expose those environment variables to those services.
Ultimately, the vision is to build a platform across all cloud
providers that developers and devops teams can use to build, test,
deploy and manage environments and services transparently. We
strongly believe that developers and devops/platform teams should
be working on the same platform. So many of the communication and
siloing issues happen because teams use different platforms and
tools. Consolidating those into one platform helps everyone stay in
sync and have access to everything they need. 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. Our current customers range from small
startups who want to focus on getting to market fast and not worry
about infra or devops, to mid-market companies that want to empower
their existing devops teams with automation. Their main use-cases
are: 1. Automatically containerizing their services (with our
built-in CI/CD pipeline) and deploying them on Kubernetes 2.
Building out a microservices architecture (we have a built-in in
service mesh) 3. Making it easy for developers to self-service
environments, environment variables and more. If you're interested
to learn more, check out our docs (https://docs.nucleuscloud.com)
and you can sign up for a free account here
(https://app.nucleuscloud.com). We're always looking for feedback
so please let us know your thoughts/questions and thanks for having
us!
Author : evisdrenova
Score : 48 points
Date : 2023-06-05 15:39 UTC (7 hours ago)
| Sytten wrote:
| Looks interesting but at 35k per license I am not sure who you
| are targeting with this. Why would anyone use this compared to an
| okteto, a porter or a qovery? They are all priced in the sub 1k$
| for essentially the same thing as far as I can tell.
| evisdrenova wrote:
| Thanks for the feedback! We're definitely still working on the
| pricing and work with our customers to find something that
| makes sense and works for them. We really only offer one
| version of our platform which is an enterprise version of
| unlimited users, environments, services etc for one price.
|
| 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.
| danpalmer wrote:
| > At the bottom layer, we build and manage pre-configured
| Kubernetes clusters in your AWS accounts
|
| 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.
| evisdrenova wrote:
| Thanks for the feedback! We're still an early company and
| working through the right pricing - we have some customers who
| pay less than that and some who pay more. Goal is to get happy
| customers and being an early stage company we have flexibility
| on it (the flat pricing makes that much easier).
| danpalmer wrote:
| I always find pricing in terms of developer time saved to be
| a tough sell, because different companies have different
| opportunity costs, value the product differently, pay
| differently, and different engineers have different
| productivity. That's a lot of axes to reason about. Most
| tools boil down to this eventually, but some are obviously
| things you'd never build internally (for a given size of
| company), whereas some are incremental improvements over what
| you might already be doing. I think Nucleus is in the latter
| category for many which makes this harder.
|
| Have you considered things like per-region, per-host, per-
| cluster, per-active developer etc?
| intelVISA wrote:
| It's a deliberately misleading metric overall imo as it
| frames the value prop on your developers rather than the
| product.
|
| 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!!
| evisdrenova wrote:
| We definitely have considered those axes to price against
| but so far haven't adopted them because we deploy nucleus
| into your account and its honestly felt a little strange to
| us to charge a company by region, host, cluster etc. when
| ultimately you're paying the infra bill.
|
| 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.
| nickzelei wrote:
| > 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 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.
| candiddevmike wrote:
| Your product looks neat but I think you're a few years too late,
| for most folks the Kubernetes platform is kind of a done deal.
| Couple of questions:
|
| - 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?
| cpach wrote:
| It might not be a done deal for companies that were recently
| founded. And definitely not for companies who have yet to be
| founded.
| debarshri wrote:
| I have been curating list of PaaS, kubernetes abstractions etc.
| in Awesome PaaS [1].
|
| 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
| evisdrenova wrote:
| Totally fair question - we're thinking about this in 2 ways:
|
| 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).
| evisdrenova wrote:
| Thanks for the feedback! Answers below: - Target customer is
| small to medium sized companies - we see the best fit with
| companies that have 2->30 engineers - we definitely have
| similarities but I think we have a better developer experience
| + we're much much cheaper than their managed version - we're
| working on releasing support for over this in the next 1-2
| months - we're SOC 2 type 1 certified right now, and will be
| getting our SOC 2 Type 2 in 1 month. We have a few partnerships
| that we're working on but they're not ready to completely
| announce just yet.
| avbanks wrote:
| So this runs on top of AKS?
| nickzelei wrote:
| Today our platform is built ontop of EKS. We are currently
| working on GKE support, and then AKS to follow.
| whalesalad wrote:
| Huh, I have the opposite. There is a huge hole in the ecosystem
| between Fly.io/Heroku and managed Kubernetes.
|
| 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.
| evisdrenova wrote:
| Appreciate the feedback! That was the experience we had as
| well - there wasn't anything in between render/heroku/fly.io
| and EKS and why we started Nucleus. We're not going out of
| business anytime soon but its a very fair concern and there's
| ways that we can help mitigate that i.e. offering an on-prem
| version, exporting terraform files, etc. Working towards this
| but it will take some time.
| 2023throwawayy wrote:
| I have to agree here. I have collected a list of companies in
| this space. Unless you have a large differentiator, you've got
| your work out for you trying to attract customers.
|
| 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
| jaguar75 wrote:
| Impressive list indeed! Co-founder of Signadot here. Btw, we
| don't manage Kubernetes (K8s) environments; instead, we
| enable multi-tenancy for test tenants within a customer's
| existing K8s setup, without duplicating infrastructure. We
| leverage sidecars or a service mesh for request-based
| isolation, dynamically routing traffic based on request
| headers (typically propagated using OpenTelemetry).
| tommiegannert wrote:
| namespace.so by friends of mine.
| suryao wrote:
| Yeah, customer acquisition and dev experience makes all the
| difference here.
|
| Also, you missed out my company, argonaut.dev :-)
| debarshri wrote:
| Is it also a YC company?
| suryao wrote:
| Yes, we are a YC S21 company and are on the awesome PaaS
| list you've compiled. We have been focusing on building
| in stealth so far and are planning some public launches
| over the next few weeks. We are already more mature and
| feature rich than most of the tools on the list for
| instance.
| rubenfiszel wrote:
| Missing windmill.dev :)
| stevelacy wrote:
| I've built several massive-scale k8s systems for prior companies,
| all scaled using the underlying built-in primitives without
| extreme cost. Where do you get the improvement metrics from? For
| instance: "5x faster deployments"
| intelVISA wrote:
| rand();
| evisdrenova wrote:
| This is based on what we're seeing with our customers + our own
| experience. One example from a customer is that it was taking
| them 14 minutes to deploy one service to production.
| Combination of slow build pipelines + manual process to update
| a tag in a kustomize file and then manually trigger deploy.
| Given the automation we have in place, they're not pushing to
| prod in less than 3 minutes. Everyone's environments are a
| little different but we're seeing encouraging results.
| ksajadi wrote:
| Congratulations on the launch! It looks neat. I wonder if you're
| deploying your own k8s on AWS or using AWS EKS. There is value in
| both, the former being able to move across cloud providers that
| don't have managed k8s (ie OpenShift, Cloud 66, ...) and the
| latter improving the DX on k8s (Convox, etc)
| nickzelei wrote:
| Thanks! Today we are leveraging EKS. We're also currently
| adding support for GKE. They each have their quirks though and
| support different things. In the future I'd love to add
| generic, un-managed support for the reasons you state.
| gizzlon wrote:
| PaaS .. it's a thing. Try it out before k8
| alex_lav wrote:
| Would really love some kind of pricing clarity. "Free Forever"
| with hard caps and "Custom" with negotiable caps doesn't really
| suit my needs, and I don't have any idea at all what to expect in
| terms of pricing "after free but before scale"
| evisdrenova wrote:
| @alex - we don't meter usage, environments, services, users,
| etc. for our paid plan so you have free reign over all of that.
| We have customers who pay a variety of price points depending
| on what they can afford/makes sense.
|
| Would more granular pricing that meters users, environments,
| services etc. be more appealing?
___________________________________________________________________
(page generated 2023-06-05 23:01 UTC)