TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Launch HN: Nucleus (YC S22) – Kubernetes platform for both devs and ops

77 点作者 edrenova将近 2 年前
Hi HN! We’re Evis and Nick and we’re the founders of Nucleus (<a href="https:&#x2F;&#x2F;nucleuscloud.com">https:&#x2F;&#x2F;nucleuscloud.com</a>), 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: <a href="https:&#x2F;&#x2F;www.loom.com&#x2F;share&#x2F;95265177704346c7b379e981978cd8c5" rel="nofollow">https:&#x2F;&#x2F;www.loom.com&#x2F;share&#x2F;95265177704346c7b379e981978cd8c5</a>.<p>It&#x27;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&#x27;ve talked to customers who have spent $1.5M to build something that isn&#x27;t their core product.<p>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.<p>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&#x27;t their core product. We felt like there had to be a better way.<p>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.<p>To get into the architecture a bit, you can think of Nucleus as three layers:<p>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 - <a href="https:&#x2F;&#x2F;docs.nucleuscloud.com">https:&#x2F;&#x2F;docs.nucleuscloud.com</a>. 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.<p>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 (<a href="https:&#x2F;&#x2F;monzo.com&#x2F;blog&#x2F;2022&#x2F;03&#x2F;31&#x2F;how-we-secure-monzos-banking-platform" rel="nofollow">https:&#x2F;&#x2F;monzo.com&#x2F;blog&#x2F;2022&#x2F;03&#x2F;31&#x2F;how-we-secure-monzos-banki...</a>). 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.<p>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&#x2F;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&#x2F;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.<p>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&#x2F;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.<p>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&#x2F;license, or about 10% of what it would cost you to build and maintain this yourself.<p>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&#x2F;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.<p>If you&#x27;re interested to learn more, check out our docs (<a href="https:&#x2F;&#x2F;docs.nucleuscloud.com">https:&#x2F;&#x2F;docs.nucleuscloud.com</a>) and you can sign up for a free account here (<a href="https:&#x2F;&#x2F;app.nucleuscloud.com">https:&#x2F;&#x2F;app.nucleuscloud.com</a>). We&#x27;re always looking for feedback so please let us know your thoughts&#x2F;questions and thanks for having us!

10 条评论

danpalmer将近 2 年前
&gt; At the bottom layer, we build and manage pre-configured Kubernetes clusters in your AWS accounts<p>Are you considering supporting other cloud providers? I&#x27;d personally always choose GCP for UX reasons, and I know there are many who choose Azure for MS reasons, or Alibaba for price&#x2F;language&#x2F;location reasons. I understand starting with AWS, just wondering if that&#x27;s set in stone or if others are on the roadmap.<p>&gt; 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&#x2F;license, or about 10% of what it would cost you to build and maintain this yourself.<p>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&#x27;d have spent on it. Our Datadog bill for comparison was about half that per year, and our cloud bill was only ~6x that.<p>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.<p>Maybe we weren&#x27;t the target market! Just my thoughts though. Nice one with having one flat fee, I like that.
评论 #36199086 未加载
评论 #36233849 未加载
评论 #36198970 未加载
candiddevmike将近 2 年前
Your product looks neat but I think you&#x27;re a few years too late, for most folks the Kubernetes platform is kind of a done deal. Couple of questions:<p>- Who is your target customer?<p>- How does it compare to OpenShift?<p>- Can you bring your own Kubernetes provider?<p>- 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?
评论 #36198222 未加载
评论 #36203168 未加载
评论 #36198141 未加载
评论 #36198545 未加载
评论 #36199440 未加载
stevelacy将近 2 年前
I&#x27;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: &quot;5x faster deployments&quot;
评论 #36198889 未加载
评论 #36200302 未加载
simonebrunozzi将近 2 年前
&gt; we currently price Nucleus around $35k&#x2F;license, or about 10% of what it would cost you to build and maintain this yourself.<p>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.<p>Why? Because:<p>1) You will need the price to go up.<p>2) You are positioning your product in a different (better?) way.<p>Note that things like Amazon RDS, etc, are at about 20-25% premium on top of the tools&#x2F;softwares that they automate.<p>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%.
Sytten将近 2 年前
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.
评论 #36199407 未加载
gizzlon将近 2 年前
PaaS .. it&#x27;s a thing. Try it out before k8
评论 #36246567 未加载
alex_lav将近 2 年前
Would really love some kind of pricing clarity. &quot;Free Forever&quot; with hard caps and &quot;Custom&quot; with negotiable caps doesn&#x27;t really suit my needs, and I don&#x27;t have any idea at all what to expect in terms of pricing &quot;after free but before scale&quot;
评论 #36200939 未加载
hitsurume将近 2 年前
I&#x27;m confused, if someone is already using something like GKE or EKS, what do you do? Presuming people are using cloud build&#x2F;code pipeline with their setups.
评论 #36216541 未加载
nm3将近 2 年前
Giving admin access to a production AWS account is kinda scary, have you thought about curating the permissions to make them less permissive?
评论 #36214811 未加载
ksajadi将近 2 年前
Congratulations on the launch! It looks neat. I wonder if you&#x27;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&#x27;t have managed k8s (ie OpenShift, Cloud 66, ...) and the latter improving the DX on k8s (Convox, etc)
评论 #36198762 未加载