[HN Gopher] Launch HN: Argonaut (YC S21) - Easily Deploy Apps an...
___________________________________________________________________
Launch HN: Argonaut (YC S21) - Easily Deploy Apps and Infra to AWS
and GCP
Hello HN, I'm Surya, the founder of Argonaut
(https://www.argonaut.dev/), a unified platform that tries to make
software ops painless, so teams can focus on building features
instead of building and managing infrastructure. Argonaut combines
Kubernetes PaaS, a CI pipeline builder, and a Terraform state
manager with prebuilt AWS and GCP modules. Here's a demo:
https://www.youtube.com/watch?v=8DZsYXxA2tQ. I've helped build
infrastructure tooling from scratch at multiple companies and
realized two things: that the shape of the solution with the advent
of containerization, Kubernetes, and hyperscalers is quite similar
across orgs, and that highly knowledgeable engineers are needed to
build and manage this system. Internal infrastructure teams juggle
a multitude of tasks--provisioning cloud infrastructure,
configuring runtimes, building code, securing artifacts, running
tests, and deploying at scale. Post-deployment, they're also tasked
with monitoring app performance, errors, uptime, and cost
visibility. It's a lot of work, and having to build this tooling
in-house is a deep inefficiency in engineering teams. The root of
the problem is that AWS and GCP provide a lower level of
abstraction than the entities, such as environments and
applications, that developers have to deal with, and a ton of work
is getting duplicated, often by underfunded teams, across many
orgs. Argonaut's objective is to be the developer platform and
control center that you would otherwise have to build internally.
Argonaut provides an intuitive developer experience that simplifies
working with Kubernetes and enables developer self-service,
reducing the burden on devops and platform teams. We've productized
this workflow orchestration, incorporating best practices to
provide a push-to-deploy experience with flexible pipelines and
scalable infrastructure, all within minutes. Our users are
startups across various domains like healthcare, IoT, fintech, AI,
and SaaS products. Over the last two years, we've enabled customers
to scale their engineering teams 10x and manage 10+ environments in
parallel without needing a dedicated infra/DevOps team, saving them
precious time and resources. Argonaut lets you set up production-
ready infrastructure and customize as you scale. We then let you
set up automated deployments of your application in minutes. We
offer configurable build-and-deploy pipelines, powered by Dagger
and ArgoCD, and deep integration with GitHub Actions and GitLab CI.
In addition, we support container registries, multiple cloud
accounts, observability stacks, cost visibility providers, CDNs,
and the entire helm chart ecosystem of Kubernetes, with more
integrations on the way. Key features include: (1) easily create
environments encapsulating cloud infrastructure, applications, and
deployment pipelines (2) autoscaling deployments for apps and
cronjobs to GCP and AWS with a progression across environments (3)
compose deployments across multiple environments with our visual
pipeline builder (4) get cost estimates before making infra
changes, giving you a clear understanding of your expenses; (5)
managed Terraform state and pre-built modules that just work,
fostering team collaboration on infrastructure. Argonaut is self-
serve, so you can sign up and start using the product right away:
https://ship.argonaut.dev. There is a free tier that doesn't
require a credit card to get started. We'd be delighted to have you
try it, and are happy to help with onboarding. If your teams work
with AWS, GCP, or Kubernetes, I'd love to hear about your
experiences, pain points, and what you think a product like
Argonaut should be able to do. Looking forward to your comments!
Author : suryao
Score : 104 points
Date : 2023-06-26 14:41 UTC (8 hours ago)
| FBISurveillance wrote:
| Congrats on the launch. There was another YC-backed company that
| provided a ArgoCD as a service - https://www.koncrete.dev/
|
| It'd be interesting to know why they failed. I have to admit I
| got burnt a bit because we started to integrate with Koncrete and
| then they were out (and we've had to move away).
| suryao wrote:
| I don't have insider info about koncrete but there is akuity
| which does managed ArgoCD, built by the creators of ArgoCD, and
| that seems to be going well. Also, managed ArgoCD is one of
| ~4-5 things that we do - managed tf state and autogenerated tf,
| drag-drop CI builder, kubernetes management etc.
| mwcampbell wrote:
| Congratulations on your launch.
|
| Did you ever consider using Amazon ECS instead of Kubernetes? I
| made the move from EKS to ECS a couple of years ago, because ECS
| doesn't require you to pay for your own cluster control plane,
| and I feel that ECS integrates more seamlessly with the rest of
| AWS. I suppose that also means more AWS lock-in, but the Linux-
| based container images themselves are still portable. And
| overall, I've found that ECS is just less complicated and lower-
| maintenance than Kubernetes.
|
| But AFAIK, neither GCP nor Azure has an ECS-style shared
| container orchestration service. I wonder why that is.
| maccard wrote:
| Azure has Azure Container Apps.
| nightpool wrote:
| > But AFAIK, neither GCP nor Azure has an ECS-style shared
| container orchestration service. I wonder why that is.
|
| Isn't this what Cloud Run on GCP is supposed to be? Or am I
| misunderstanding?
| suryao wrote:
| Google CloudRun (equivalent to ECS) and AWS ECS are great but
| they have some limitations in the type of workloads you can
| run. The choice of EKS (and GKE) was done for a few forward
| looking reasons including the ability to run any kind of
| workloads and more complex scenarios including enabling cloud
| portability for example. Else, it would lead to potential lock-
| in as companies diversify in their requirements.
|
| With Argonaut, we try to make EKS easier to use than ECS to
| bring the best of both worlds. We handle the kubernetes version
| upgrades as well.
| zicon35 wrote:
| This is a solid problem to be solved! Small engineering teams
| ought to solve business problems and not manage AWS/GCP hell.
|
| As someone who saw the earliest version of the product, the
| product has come a such a long way! Congrats!
| sidcool wrote:
| I like the name. Is it based on ArgoCD?
| suryao wrote:
| Thank you! The continuous delivery is powered by ArgoCD, but
| the name was chosen because we have some great folks on the
| team :)
| WaitWaitWha wrote:
| Does this work in Azure?
|
| Does this work in AWS Gov, Azure Gov, Google Cloud Gov?
| suryao wrote:
| Reg Azure, pasting my response from elsewhere in the thread:
|
| _[...] in the Argonaut context, that only limits the overall
| infra management piece where we don 't have a seamless
| integration using IAM roles and can't provision infra like dbs
| and queues. The app deployments to Azure kubernetes (or any k8s
| cluster) work seamlessly though, and some of our customers
| deploy to AKS in this manner._
|
| We do not support gov cloud yet.
| bovermyer wrote:
| How would this integrate (if at all) with other CI/CD tools, like
| Jenkins?
| suryao wrote:
| The CI runner logic is built on top of a CI agnostic
| abstraction layer called Dagger.io. This makes it super easy
| for the CI logic and integration portability. We are working on
| adding more CI providers.
| juiiiced wrote:
| Is there any planned support for Azure? If not what is the
| reasoning (out of curiosity)?
| suryao wrote:
| We work with small-mid startups and not many of those use Azure
| :) IME, azure has higher adoption once there is a CIO in the
| company.
|
| However, in the Argonaut context, that only limits the overall
| infra management piece where we don't have a seamless
| integration using IAM roles and can't provision infra like dbs
| and queues. The app deployments to Azure kubernetes (or any k8s
| cluster) work seamlessly though, and some of our customers
| deploy to AKS in this manner.
| allanhahaha wrote:
| Congrats on the launch! I'm wondering how Argonaut compares to
| Porter (porter.run) when it comes to DevOps as a service. Thank
| you!
| suryao wrote:
| They are building a very cool product. The difference is the
| following: (1) we focus on the entire infra and env management
| apart from being a kubernetes PaaS. This means you can setup
| cloud infra like managed kafka (MSK), docdb, SQS, CloudSQL,
| etc. as a part of your env without resorting to a different
| tool. Our customers love that single-pane experience. (2) We
| have no on-cluster agents and all code that runs on your
| cluster is yours alone (3) there is a slight difference in
| transparency vs ux tradeoff. We have a few more knobs you can
| control and that leads to more user involvement during setup.
|
| From a value perspective, we have a simple per-seat pricing.
| jamescmartinez wrote:
| Ok, I'll bite. We (mergent.co) have looked at similar tools
| before but ended up managing our own infra. This is primarily
| because the tools we've found focus on recreating Heroku/similar
| on our AWS, which doesn't suit our needs.
|
| For example, in addition to traditional applications, we run: -
| Kubernetes + Knative - Apache Pulsar - ScyllaDB - Elastic -
| Clickhouse (soon)
|
| How would Argonaut help us with our (frankly, painful) infra?
| We're living in YAML hell over here.
| suryao wrote:
| This type of use case leverages Argonaut's flexibility
| maximally. For traditional apps, the push-to-deploy CI/CD can
| be setup. For Pulsar and ScyllaDB, and Elastic there are helm
| charts that can be used very easily as a part of our AddOns
| which we are expanding continuously. For Knative and
| clickhouse, the best way to run them would be through
| Kubernetes operators. While this can be setup using Argonaut
| today, the experience feels janky and we're working on making
| this a first class entity in the product.
|
| The way Argonaut would help is by managing the configs and
| deployments in one place for easy collaboration and deployment,
| across environments and having GitOps with secret management
| for all the configs.
| VWWHFSfQ wrote:
| I like the Terraform angle!
|
| The problem we always have with AWS K8S or Beanstalk or Lambda
| (or whatever) is that the performance is abysmal and the whole
| thing is extremely expensive. We deploy our whole backend on a
| few plain old Linux EC2 servers in an auto-scaling group
| provisioned with Terraform and Ansible for about 10% of the cost
| that running the same capacity in ECS/EKS.
| throw03172019 wrote:
| Congrats on the launch. How does this compare to Convox?
| ivanvas wrote:
| Both have SSO tax, it seems. Not nice.
| jagtstronaut wrote:
| Nice! Good luck to y'all.
|
| I'm in the middle of a particularly annoying ops ticket so this
| hits home today haha.
| suryao wrote:
| Every day is HugOps day in this land :)
| Tjedjjd8 wrote:
| You have 5k RUBLOX and you must just/: Give email
| thanks/welcome(good game)..
| narenkmano wrote:
| Congrats on the launch! I've had to deploy python/java services
| on AWS ECS services (for blue-green deploys) multiple times over
| the last six months and it's always been a pain to setup it up.
| Especially in a startup where I want to move as fast as possible
| it's been a pain to set up manually.
|
| Is that something that is easy to setup with Argonaut?
| leoh wrote:
| Are you using terraform?
| narenkmano wrote:
| No, doing everything by hand in the console, which has been
| super annoying. But don't want to spend time setting up
| terraform right now.
| suryao wrote:
| As an aside: argonaut sets everything up using terraform
| (everything is autogenerated from templates), though the tf
| code itself is not yet exposed to users. We're working on
| that functionality soon.
| earthling8118 wrote:
| Well, that's likely the issue. You're spending more time
| avoiding doing it the way that will make everything go more
| smoothly
| icedchai wrote:
| You're going to waste more time setting things up by hand.
| It's also error prone, and when you have to replicate
| things across environments (dev, test, prod, at a minimum),
| you'll spend a ton of time figuring out what you missed.
|
| The console is really only meant for prototyping. AWS
| should really emphasize this more.
| suryao wrote:
| This is central to what we do. I'd be happy to give you a demo.
| How it is done: (1) kubernetes and some essential tools for
| certificate and ingress management are setup. (2) connect
| github or gitlab repos and you get a push to deploy experience
| as the CI gets setup
|
| I assume you are already containerized, so there is not much to
| be done. There is a one time setup of a kubernetes cluster
| (EKS) that aws takes about 25mins for.
|
| This will give you a rolling zero down-time deploy out of the
| box along with a few other goodies. You can checkout a quick
| demo here (~4m) - https://www.youtube.com/watch?v=8DZsYXxA2tQ
| nraf wrote:
| This looks very interesting. Been maintaining terraform scripts
| for a while that are frankly a nightmare to deal with at this
| stage.
|
| Are there any plans to support private clouds in future?
| suryao wrote:
| We are currently on AWS and GCP, with plans to expand to Azure
| later this year. Private clouds have not come up much in
| discussions so far, but we are open to it. How do you foresee a
| solution that works with private clouds to look like?
| ryanSrich wrote:
| I think this is on topic.
|
| Does there exist a tool that gives me a fully abstracted layer
| like Heroku, but on my own AWS account? When I say fully, I mean
| fully. Where the tool will do maintenance, alert me a few days
| before it does it, autoremediation if something goes wrong, etc.?
|
| I essentially want the exact same functionality as Heroku, but
| with the cost savings of running it on my own infrastructure.
| ksajadi wrote:
| Yes. That's exactly what Cloud 66 is.
| suryao wrote:
| We handle things like maintenance. For example, kubernetes
| cluster upgrades are automated transparently for our users. We
| do not have auto remediation. That is a hard problem when we do
| not control the full runtime and hosting.
| gautambt wrote:
| We've been using Argonaut for a while and have been a happy
| customer :) We deploy and manage our software on customers cloud
| accounts and Argonaut has been super useful for helping us manage
| all our deployments! Also a shoutout to Surya and his team for
| always being available in supporting us.
| suryao wrote:
| It's been a pleasure working with you and the bytebeam team.
| avg-devops-guy wrote:
| This would be dope if there was a self service options.
| suryao wrote:
| Do you mean a self-hosted option, since the product is self-
| service with support from our team? If so, I'd love to
| understand your constraints that require self-hosting. Email is
| surya@companyname.dev
| [deleted]
| alexjv89 wrote:
| We at cashflowy.io has been using argonaut for a while now. As a
| single person dev team, I did not have the time luxury to deal
| with kubernetees and also handle customer support/business
| development etc. Wanted the flexibility of kubernetees but did
| not want the full kubernetees overhead being a small startup.
| Argonaut has worked out really well for us.
| nailer wrote:
| If you need containers on demand, why not just use a simpler
| service like ECS? There's a reason k8s is a meme for wasted
| engineering resources.
| suryao wrote:
| Responding on behalf of alex at cashflowy since I have some
| context. The team was originally on Elastic Beanstalk but
| chose to move to using kubernetes to leverage the rich
| ecosystem of helm charts. That enabled setup of tools like
| metabsse etc. very easily. Overall, it was lesser hassle for
| more functionality since CI/CD was also out of the box, and
| self-hosting these tools was a breeze with helm charts.
| g_delgado14 wrote:
| Same question here - what about something like AppEngine (or
| Elastic Beanstalk)?
| bjornsing wrote:
| Very cool! I've been fiddling with terraform, ec2 + microk8s,
| eks, rancher fleet and crossplane over the weekend, trying to set
| up infra for a novel key-value store I'm working on. But there
| sure are a lot of ways to screw this up and get bogged down in
| devops work, instead of building product.
|
| My only concerns would be: 1) do I have a realistic "exit
| strategy" or am I de facto locked into your platform and 2) as an
| old school engineer I don't feel fully comfortable with a click-
| ops platform, unless it can generate terraform or similar.
| suryao wrote:
| This is a concern we hear often. We have taken some steps to
| ensure that we do right by users in case users want an exit.
| Firstly, we use broadly adopted projects like ArgoCD for GitOps
| for apps and terraform for infra under the hood, though the tf
| is not exposed right now. All your config is in standard
| formats and can be transferred over. We are working on exposing
| these natively (and securely). You would be losing "push to
| deploy" CI pipelines though, since that requires hosted infra
| and workflow management that is actively done by Argonaut. Hope
| that answers your question.
| quickthrower2 wrote:
| > If your teams work with AWS, GCP, or Kubernetes, I'd love to
| hear about your experiences, pain points, and what you think a
| product like Argonaut should be able to do.
|
| Using Kubernetes in Azure (and this might be Azure specific),
| there isn't enough easy diagnostics via point/click for
| production issues. It is a nightmare trying to figure out why
| something happened and feels like you need to gain more expertise
| (at time sensitive times!) each time it does. Azure has improved
| over the years in this regard. But it might be a Kubernetes
| thing.
|
| A cool feature would be "This pod stopped, and didn't restart for
| 10 minutes" and the reason is "{the reason in plain English}".
|
| Kubernetes feels like a leaky thing to throw abstractions over,
| so the pain with using it is you need to become an expert in it,
| more so than the serverless offerings that are more genuinely
| abstracted, like the various app platforms that run the
| containers directly, or functions.
|
| I guess even when managed by the cloud host, it is more serverful
| (e.g. the need to SSH into VMs to do security hardening checks),
| but then there is this beast running on those servers you need to
| understand too.
|
| And at that point you need a lot of engineer time anyway and
| probably a platform separation to deal with it all.
|
| So I think if your product could remove some of those kinds of
| issues it would be good - but then I am still trying to work out
| "why choose Kubernetes and not some sort of app service" for the
| majority of users (I am keeping an open mind!)
| suryao wrote:
| > A cool feature would be "This pod stopped, and didn't restart
| for 10 minutes" and the reason is "{the reason in plain
| English}".
|
| There is a little "bulb" icon on the top. That enables a
| "highlight mode" where you can select some text, usually
| kubernetes error messages. That is sent to an OpenAI LLM to (1)
| convert the error into plain english (2) show potential fixes.
|
| This is limited by what GPT4 can provide but it is still
| helpful in some cases. Maybe we should highlight this feature
| more :)
|
| > Kubernetes feels like a leaky thing to throw abstractions
| over, so the pain with using it is you need to become an expert
| in it, [..]
|
| We believe two things: (1) k8s features exist because they are
| genuine user needs and we don't want to hide them (2) things
| get very complex very quickly because the "beast" is complex.
|
| Argonaut's approach is what I call "Progressive Discovery".
| There is a good happy path that works for 80% of use cases.
| When you need to deviate, we make it easy to work with the
| underlying primitives to enable your use case. This enables
| users to move fast without hitting an abstraction ceiling and
| it keeps the complexity in check.
|
| That said - Argonaut is not for everyone. If you have just a
| service or two, you're better off running it on a hosted runner
| instead of an aws or gcp or azure. It is going to be cheaper at
| small scale too.
| quickthrower2 wrote:
| Thanks. I think using AI to help with translating error
| messages, and perhaps finding the logs that matter, and even
| being an "expert system" of sorts to give an opinion on what
| went wrong is useful. Sort of how Windows diagnosis of why
| something isn't working (like wifi) has got better over the
| years, probably by adding more and more edge cases!
| suryao wrote:
| Yeah, I think there is a long way to go before the AI gets
| good enough to be trustworthy for infra type tasks but I am
| super excited for that future.
| bitlad wrote:
| [dead]
| candiddevmike wrote:
| I really don't understand how companies just give AWS and GCP
| access (along with infrastructure and release management) to fly
| by night SaaS companies like yourself. No security docs, no
| compliance audits, nothing. To me, I'd use your customer list as
| companies to avoid interacting with, because there's a serious
| lack of due diligence on their part.
| bovermyer wrote:
| The ad hominem attack and the hostility in your comment are
| unnecessary.
| suryao wrote:
| If I parse through and get to the concern being voiced, I'd
| rephrase it as "how can I trust you with access to my cloud".
|
| There is no easy answer but here is my response: 1. We take
| precautions to enable connections through oauth/app mechanisms
| for VCS integrations and IAM roles for cloud accounts like aws
| and gcp 2. Our incentives are aligned - we make money only if
| we earn and keep the trust of our customers 3. We have gone to
| extra lengths to enable easy exits in case companies want to
| move out.
|
| These, broadly speaking, are true for any other provider that
| you would use and may _now_ trust for app hosting or CDNs or
| version control or payments - some of which are SmallCos and
| some were SmallCos until just a couple of years ago.
|
| At some level, it all boils down to "trust us" but hope this
| provides context.
| alex_suzuki wrote:
| The calm and professional way you respond to a needlessly
| aggressive comment does you credit.
| alex_lav wrote:
| Because GCP and AWS give access to "fly by night" devs,
| companies, products etc. as part of their business? Anyone can
| create a company, create some dev infrastructure and then
| _also_ ignore security and "compliance" best practices? What do
| you think a cloud vendor's role in this process is?
___________________________________________________________________
(page generated 2023-06-26 23:00 UTC)