regiswilson

I apologise for the poor choice on my part. I'll take everything you said to heart and learn from this experience.

Speaking personally, the feeling is that for general compute like web servers and apis it is acceptable and will show a decrease in costs for the same performance. That is my understanding, and I am eager to try it.

Exactly right but also in our case, we support single and multi-tenant first/second, and even third party support. That is, we need to support any workload from any customer or customer's customer at any moment now or in the future. We can easily say "if you have an x86 cluster, we guarantee 100% compatibility." But if we switch to ARM, we'd have to make exceptions and do double the testing on any existing workloads, as well as all the complications with building twice and doing releases and notes for each arch... It really does spin out of control quickly.

I was referring to problems we found during initial development, but I appreciate that I didn't clarify that well.

Fantastic, we've already begun switching RDS instances to Arm64 (simple, easy, and effective), but still haven't cracked (yet) building for Arm64 compute containers in a safe and effective way. I love it!

Release engineer here. No, this tool merely complements our core offerings and also has some use as a standalone tool. We can currently use any of the AI API offerings that are compatible; OpenAI is the one that is most common though. If they shut it down, a lot of people would have to migrate to a different provider but our tool could still work.

Release engineer here. You can pretty easily audit the policy we use (Read-Only) and you can also add a permissions boundary if you want. We would love to get any feedback and improvements you can offer if you are inclined. We have a slack workspace users can join, check it out. https://release-ai.slack.com

Excellent idea, we do internally feed the answers back to the system to improve its own inputs and outputs. The funniest part of some of this experience has been to find cases where even humans were hallucinating: "Hey, I thought this was shutdown?!" or "I can't find the bucket!" Even on a bad day, the humans are still ahead though.

Release engineer here.

- Support Digital Ocean: We are always looking to add more integrations! - Read-only access to user data: You are welcome to check on the policy and/or adjust it. We default in the recommended case to Read-Only, but you can improve on that with a permissions boundary - How is it better than gathering output from AWS, copy/pasting it into a browser, reading the answer and copy/pasting back into terminal? Well, it's all in one place and it allows a tighter loop between gathering, analysing, and giving responses in one place. It gives lay people better access to data they might not know how to or be able to access, and it gives advanced users smoother, tighter loops on data and access they might already have. Hopefully that gives you some ideas.

That's an impressive article and a lot of good work put into it!

Release engineer here. I believe you have hit on some of the ideas we've certainly discussed way down the road (or sooner than you'd think?). For example, can we inform the AI about your existing infrastructure patterns, tooling, configs, etc. and then ask it to "suggest best practices", "compare to security and compliance policies", "improve" it, "analyse optimisations", "identify unused/overprovisioned pieces", etc. etc.!

Relase AI Bot: "Try switching to gp3, you will save money and likely see a performance boost!"

Release engineer here. You can do a bunch of cool tricks like go into `/expert` mode and view all the details. Join our slack workspace (https://release-ai.slack.com) and we have tonnes more tricks and techniques to share!

Release engineer here. That's an excellent question, and we worry about it all the time. The AI "seems" authoritative, but it can't even add 1+1 sometimes :crying-emoji:. We've tried to engineer the prompts and tooling so that it will say "I don't know" if it doesn't know. But we've still seen it say some crazy things, like "Your cluster is fine" when it clearly wasn't. :tounge-sticking-out-emoji: I guess the only real answer is you have to trust but verify.

Release engineer here, we see this as complementary to environments. When you spin up your infrastructure and environments using our service, how do you interact with them? How do you see what is happening? How can you (easily, as a lay person) figure out how to diagnose, maybe even fix, problems? That is the idea, hope you like it.

A primer on using docker build and buildx commands to host your website in seconds on production-grade kubernetes clusters.

The short answer is that, yes, embeddings are probably a hack in the same way that using bits or short variable names were hacks to reduce memory usage. At some point you are correct: someone would prompt "given <large amount of data>, answer <user request>".

Really proud of Sam's work here, using actual data to show some results instead of the usual fluff and puff.

I think ArgoCD is a good parallel to what Releasehub offers, so the question of what we offer is probably a bit of bias on our part. Objectively, though, what we offer is a fully integrated experience from a PR/git commit being built into a fully functioning environment every time. Sometimes the other side of that is just as important: when the PR is closed, we delete the environment!!

The other value add we offer, more subjectively, is the ease of use and reduced TCO of having someone else manage all the kubernetes, infrastructure, duct tape, and self-support required for open source solutions.

Releasehub goes all the way to CD if you build out a staging and/or production environment. Releasehub also does super fast builds with buildkit. So it's CB->CI->CD all the way.

CD is the real end-goal and there is an argument to be made to be an expert in only one. However, integrating all the different parts of these chains and tools just adds more compatibility and complexity problems, which is exactly what Releasehub tries to solve.

> that can't be easily solved by docker-compose?

Docker-compose only runs on my (your) laptop. What if you want to share that with someone else? I have to git stash, checkout a branch, tell someone else to do all that... I think you're on the right idea: it's "easy" to do with existing tooling, but there's a big gap between it's easy to do and then go and spend the time to do it.

I love this article because I wrote it!