Start-ups always grapple with the “right” way to do things, versus getting sh*t done, and all the while dealing with resource constraints. The obvious choices for companies to host their services are the public clouds like AWS, GCP, Azure, Digital Ocean and quick start hosted backends like Heroku, etc.
Words like technical debt, time to market, rapid iterations, and automated pipelines are thrown around, but what do they really mean? We’ll describe why we think the full-service public clouds are the right choice for most startups and why we chose AWS as the first cloud provider supported by Argonaut. It is not the same for all companies, but hopefully, it gives you some insight on how to pick your poison.
Most startups have two options — a cloud provider like a GCP, AWS, or a PaaS provider like Heroku, or Render. The advantages of PaaS are fairly obvious — easy deploys, not having to worry about DevOps overheads, and most importantly, fast iterations. While it is super easy to get started with a PaaS, it inevitably leads to a ceiling in terms of capability provided and this choice implies a tech debt. We talk about this in more detail in the next section. IaaS on the other hand have a much steeper learning curve for new teams and requires a lot more investment into tooling. This additional complexity is the primary reason why teams opt for PaaS offerings.
The best of both worlds - the developer experience of a PaaS, but on your cloud. There are two problems to be solved here for a comprehensive developer experience. The first is that of infrastructure - dealing with infra is the primary contributor to the complexity of the cloud platforms. The second is that of deploying applications, with simple primitives that devs can get behind without any learning curve.
Argonaut solves this by providing the capability to spin up infra and applications on your cloud - easily and within minutes, all from the same interface.
This focus on comprehensiveness and developer experience means that we necessarily need to support the cloud platforms incrementally. We chose to start with AWS.
PaaS is insufficient
On talking to more than a hundred teams, some common limitations because of which teams choose to build on a full cloud like AWS are:
- Database with backups and multi-region availability
- Ability to run long-running jobs or crons, for data processing
- Private networking - VPN support
- Object storage for media and static site hosting
- Leveraging massive existing ecosystems (around k8s, serverless, etc)
- ETL type or GPU based workloads
- CLI based tools
- Data warehouses, Kafka connectors, managed queues, data streams, ML capabilities, multi-region deployments, ...
Pricing is very different. Considering PaaS offerings are built as a layer on the public clouds, this one’s obvious, considering PaaS platforms like Heroku price on a per dyno basis (can become very expensive as the company grows) compared to the Pay-as-you-go Model of public cloud. Early-stage companies, especially ones which are not traffic-heavy, can operate practically for free on a public cloud. Oh, and this is not counting the generous $300-$100,000 credits offered by the public clouds.
There are cases where PaaS is the better option too! If the entire infrastructure consists of, say, a nodejs/Django/Rails backend and the frontend is hosted on Vercel/Netlify, a PaaS is a perfectly valid solution. However, infrastructure rarely stays that simple as teams start to grow and companies mature.
A few of these problems can be solved through architectural gymnastics. For instance, having some services hosted in AWS or GCP with compute workloads managed in a PaaS accounts for a resilient database but comes with other networking hassles specifically, and tech debt generally, over time.
AWS is tough love
AWS provides primitives that are great for supporting any use case flexibly. Specifically, there is an infrastructure to support complex architectures like microservices, event streams, etc. compared to a PaaS. Serverless runtimes are great, especially at low scale to manage cost effectively. However, dealing with AWS requires DevOps expertise to work with, and more time spent on managing infrastructure.
Argonaut - The Developer Platform on Your Cloud
We flipped the equation with Argonaut to deliver the ease of use of a PaaS, while not compromising on the flexibility of a full cloud provider.
- Ease of deployment
- It is extremely easy to configure and deploy. We could deploy in a matter of seconds Argonaut. You can use the CLI or the UI.
- Support for Kubernetes and AWS Lambda as the underlying runtime 1.This makes it easy for teams of all sizes to get started - either with batteries included Kubernetes setup for scaling teams or lambdas for cost efficiency or both!
- Integrations with dev tooling
- CI/CD: Github actions and Gitlab CI
- Observability stacks: Datadog, Prometheus, Grafana, ELK stacks
- Self-hosting third-party software: Clickhouse, Grafana, Hasura, etc.
- The entire Kubernetes ecosystem through custom helm charts
- Automated generation of terraform for all infra provisioned through Argonaut
On the IaaS front, most of our potential customers are using AWS or GCP, with a majority on the former which has a market share of 40.8% among public cloud providers. GCP and Azure are also great providers (GCP being the fastest-growing public cloud vendor) and we can’t wait to start offering it to users soon.
Some of these technical challenges are daunting. Because of this, teams sometimes knowingly incur the technical debt for the long term. Argonaut solves for common anti-patterns so that engineering teams can focus on business value.
- Technical debt for infrastructure is no more. Rewriting all platform code to run on AWS and changing the CI/CD in the next few years is daunting, and not a project one should undertake.
- Microservice architectures require the right networking and inter-service communication. That is seamlessly handled with Argonaut so users don’t have to hard code instance names per environment.
- Argonaut helps people deploy to AWS without DevOps, so it made sense for us to eat our own dog food, understand the problems faced b organizations in detail and provide solutions that work. This was the ultimate clincher for us in going with AWS. Deployments of Argonaut happen using Argonaut.
Integrating toolchains while enabling collaborative development, retaining full underlying flexibility, and providing one-click solutions is much harder than just hosting workloads.
“We must all face the choice between what is right and what is easy.” ~Albus Dumbledore
At Argonaut, we have chosen the path of providing a magical developer experience while doing the right thing.
So what should you choose?
In the end, the choices depend on the system architecture, app complexity, required managed services, and future flexibility. The factors above should give some direction and inform users in making the right tradeoffs.
If you want the benefits of an IaaS with the simplicity of PaaS, we believe using AWS with Argonaut is the way to go! Give it a whirl here.**
This blog was written by Surya Oruganti, Founder & CEO, Argonaut