This is pretty cool and I think the right direction. Would like to see more companies do this. I've built out systems like this in the past that essentially only handle tokens instead of sensitive data whether it's secrets, PII, etc.
You can also take this a step further and do mathematical operations on encrypted data using homomorphic encryption without ever having to decrypt the data.
Just one small nitpick (mainly because I worked in this space for a few years) is that tokens and encrypted values are different. Tokens aren't encrypted and instead randomly generated using a KV pair look up table so that an attacker could never reverse engineer them. Whereas encrypted values obviously use a key (whether symmetric or asymmetric) and could theoretically (although pretty much never practically if you're using something like AES256) be hacked if someone got the key.
Good question! If you already have GKE or EKS + all of your CI/CD pipeline then we can help automate other manual tasks that devops or platforms have to do today. For example, the ability to easily clone and replicate environments for developer self-service, or to get ephemeral environments. We're working on releasing blue/green deploy and multi-cloud features as well. This would require a migration to Nucleus, so you would have deploy your services on to Nucleus from your existing clusters.
Thought I replied here but must have missed it. It's a solid list! From my perspective, our market is a much smaller market than just "developer tools" we're really focusing on teams that want to move to kubernetes but don't have the expertise/don't want to spend the time setting it up or teams that are on kubernetes but having challenges managing and scaling their systems.
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.
@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?
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.
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.
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).
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.
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).
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.
You can also take this a step further and do mathematical operations on encrypted data using homomorphic encryption without ever having to decrypt the data.
Just one small nitpick (mainly because I worked in this space for a few years) is that tokens and encrypted values are different. Tokens aren't encrypted and instead randomly generated using a KV pair look up table so that an attacker could never reverse engineer them. Whereas encrypted values obviously use a key (whether symmetric or asymmetric) and could theoretically (although pretty much never practically if you're using something like AES256) be hacked if someone got the key.