I previously wore SWE/SRE hats on GCP. Later, I was on the other side, managing thousands of machines. The friction points of onboarding and operating cloud systems are personal problems to me.
I’ve found it hard to keep track of all the random cloud resources floating around, especially as my team’s assets proliferated. Occasionally, there is a resource affecting an outage but no one remembers where it is.
I am constantly frustrated by existing tooling. APIs can work, after you’ve navigated the byzantine documentation, but I often find myself doing ad-hoc tasks which are best served by a UI. Unfortunately, the search bar in the GCP web console does not behave as you expect. For example, it only seems to search for prefixes, rather than substrings, on App Engine stuff.
The GCP web console as a whole is boatloads of JavaScripts, 90+ navigation items on the left menu, and a constant stream of UX/UI controls. I'm fond of HackerNews and Craigslists, because ultimately, we just need to list/search and maybe submit a webform.
This year I convinced my friend to quit their coding gig on Wall Street to help me make the cloud accessible. We’ve started with a small tool to this end: a search engine for the cloud. What we have demo-able for you today is the GCP component of it.
Our tech:
- Go with conservative sprinkles of VanillaJS. It allowed us to focus on the domain rather than the language.
- SSR. Right now the pages are under the magical 14kb, but we’re eyeing the
- HTMX (rendering fragments of HTML strings from the server) pattern
- We’ll dabble with Elixir, Rust, and Zig in other parts of the system
- GCP (We think GCP runs great once you get set. The problem is getting to that point, which is what we want to help others do). We also have some stuff on AWS.
- Plaintext. Our “agile process” was a TODO.org file, and Git. It’ll be super fun to do a timelapse of it.