atlas9 is about an itch I need to scratch.

There is so much stuff to figure out in software projects: API design, databases, builds, deploys, async tasks, auth, workflows, releases, docs, flags, config, tests, telemetry, monitoring, logs, infrastructure-as-code, and on and on.

Large amounts of energy (time, emotion, money) is spent on this stuff. And when teams get this stuff wrong, even more energy is spent either correcting it, or living with it.

I want to build something that takes care of the common stuff, so that software teams are happier and more efficient. But, what exactly should I build? Who exactly am I building it for?

I have thoughts and questions and some opinions, and I’m starting this blog to write those down, in the hope that they will resonate with others and that discussion and community will come to life.

Batteries not included. Glue required.

Part of the struggle is bringing technologies together.

There’s no shortage of incredible tools at our disposal – PostgreSQL, Kubernetes, S3, Dynamo, Docker, Django, Rails, GitHub, Terraform, OpenTelemetry, Datadog, Splunk, AWS, GCP, Azure, etc.

And yet, it feels harder than ever to pull it all together. Kubernetes and AWS are super powerful, and overwhelming. PostgreSQL feels easy and powerful, the query planner changes its mind at 1am, or you run out of connections, or your vacuum isn’t running fast enough, or you need to upgrade, etc. Terraform works great until it doesn’t. For all the words written about observability, I still struggle to set it all up and get the data I need (and I worked for an observability company for years!). Even in a sophisticated, mature web application framework, teams struggle with common things like API error messages, validation, defaults, database transactions or replicas, etc.

And each piece makes it harder to have a smooth developer experience, or one that usefully matches real-world production behavior.

The devil in the details.

I’m very fortunate to have always worked with great people. My favorite thing about work is always the people – they’re smart, experienced, fun, passionate, interesting, and I learn from them non-stop.

And yet, collectively, we (myself included) get so many seemingly simple details wrong. Like keeping fields consistently snake_case or camelCase in an API. Or apply defaults and validation to API resources in a consistent way. Or using database transactions correctly. Or where to set defaults in the many layers of config. I believe we all agree that by the year 2026, it should be really hard to get these seemingly simple details wrong.

It points to the fact that building software systems, especially with more than a couple people, is still hard. I hope atlas9 can be a tool that takes care of more of these details.

At the bottom of this post, I’ve included a long list of things that I’ve seen teams struggle with, or that I have struggled with myself. It’s a long list! And I bet it could be much longer if I A) had a better memory, B) didn’t block out bad memories, C) thought harder about it, and D) asked others to contribute their struggles. I think a lot of these topics are very common in software organizations of almost any size. It’s mind-boggling how much we have to figure out every time, and how much opportunity for missteps that creates.

A blurry vision of atlas9

My experience is mostly in web applications and distributed systems, so atlas9 is focused on the issues I’ve encountered there.

atlas9 starts with some thoughtful writing (and hopefully discussion) about various patterns and tradeoffs. That’s why I’m starting this blog.

atlas9 will most likely include an application framework, most likely written in Go. There are a lot of existing frameworks out there, most of which I’m not yet very familiar with, so I have some research to do. My experience with frameworks is that they’re flexible, and that flexibility leaves a lot of room for decisions to be made. Those decisions can take a lot of effort, and each decisions has some risk of being a misstep. Also, honestly, I’ve become fairly annoyed with some of the patterns encouraged by popular languages and frameworks, and over the many years of my career I’ve developed my preferred style, and I expect that will be reflected in atlas9 to some degree.

I suspect atlas9 will need to be fairly opinionated in some ways. I suspect that “taking care of the common stuff” will mean making decisions about which common patterns to use. The tradeoff might be that atlas9 doesn’t support every way of doing things, it doesn’t fit into every box, it doesn’t work for everyone.

I suspect that atlas9 doesn’t need to be just one design. I’ve been pondering the gap between small, medium, and large projects. A small project could be fine with a single server and a sqlite database. A medium project might want Kubernetes and multiple services. A different medium (or even large) project might be fine on a few servers with a single large postgres database. Can atlas9 be useful at all these scales? Which one am I designing for first?

This is not new.

People have probably been feeling this was about technology forever. “It should be better than this” is perhaps a great driver of innovation in all areas of technology and knowledge.

And there are people out there making it better, like:

  • Railway

  • Render

  • Fly.io

  • OpenShift

  • Supabase

  • many others I’m sure (send me a comment or message with others)

Some of these seem like really cool companies and products. I recognize that atlas9 is covering some of the same ground. That’s ok. There are probably still gaps to fill, and many people aren’t able or don’t want to use these hosted services. Figuring out what atlas9 can do that complements these projects is on the long list of questions I have in mind.

Interested?

If you’re interested in this idea, if you want to follow along or be part of the discussion, please let me know! You can subscribe, you can comment, or you can send me a message directly.

Brainstorm

This is the end of the post. Below is a big, messy list of common topics that I’ve seen software teams encounter.

Leave a comment or send me a message to add to this list. Let me know which common issues or struggles are important to you, and in the future I’ll publish an updated list.

  • Docs and discussion

  • Development Environment

  • Building and Shipping

  • APIs

  • Architecture

  • Databases

  • Caching and Performance

  • Messaging and Async

  • Auth

  • LLMs

  • Security

  • Infrastructure

  • Environments and Config

  • Observability

  • Resilience

  • Testing

  • Data Management

  • Search and Storage

  • Frontend

  • Internationalization

  • Multi-tenancy

  • Billing

  • Project Management

  • Teams

  • Support and Users

  • Analytics

  • Compliance

  • Costs