I'm curious if it's visually obvious that commands are running in a non-dev environment. Saving people from the scenario where they walk away for a coffee, return, then accidentally start typing into the wrong terminal window.
I've done that and can relate to the problem! It's common for Kubernetes, where you never know which cluster kubectl is pointing to. The Target (what we can where you are running things), is one of the options in the CLI. So you have to at least provide: the Target and the script to run a command. This way you always know where you are running things, it's something like this: runops tasks create --target mysql-demo…
Launch HN: Runops (YC W21) – A better cloud shell for production apps
11–20 of 24 posts
Re: Launch HN: Runops (YC W21) – A better cloud shell for production apps
#12How did you acquire your first customers?
Re: Launch HN: Runops (YC W21) – A better cloud shell for production apps
#13Re: Launch HN: Runops (YC W21) – A better cloud shell for production apps
#14We’re an Azure/M365 house, but some of the things this tool explicitly solves were mentioned as areas of improvement for us during PCI assessment recently. I’ll be keeping an eye on this. Great work so far!
Re: Launch HN: Runops (YC W21) – A better cloud shell for production apps
#15The information on https://runops.io/ is light, does not have information on examples, workflow etc. what is the setup like (is it cloud hosted or hosted by onself in a cloud). Is your code open source? how is authn/authz if I want to use this?
Yes, we have a lot of work to do on our landing page to better explain these points. It's early days, but we will get there! Here is some light on them: It's cloud hosted, and we do support self-hosting for enterprises. The code is not open-source. We support Okta, Google, and other OAuth providers for Authentication. For Authorization we have the concept of Targets, which are abstractions of your cloud resources to…
how does your service compare to services such as teleport
Re: Launch HN: Runops (YC W21) – A better cloud shell for production apps
#16Earlier quoted context omitted.
Yes, we have a lot of work to do on our landing page to better explain these points. It's early days, but we will get there! Here is some light on them: It's cloud hosted, and we do support self-hosting for enterprises. The code is not open-source. We support Okta, Google, and other OAuth providers for Authentication. For Authorization we have the concept of Targets, which are abstractions of your cloud resources to…
Thanks!. how does your service compare to services such as teleport https://github.com/gravitational/teleport
Re: Launch HN: Runops (YC W21) – A better cloud shell for production apps
#17> You run an AWS CLI command in the terminal and it goes to Runops instead of AWS
Most enterprises are wary of handing over control to a vendor, especially if it's the underpinning of all operations in the company. I suggest a self-hosted/Enterprise release. After a few years of trying to make it work, the Enterprise will gladly pony up more money for a hosted cloud solution, but the self-hosted will get you in more doors.
> We do everything using Lisp. The CLI uses Clojurescript; the REST API uses Clojure.
Do you expect regular people to be able to contribute to or modify this? Do you find a lot of Lisp/Clojure devs out there for when you need to expand?
> Painless audit trails: No need complex for ETL to connect trails from Cloud Trail, Database Audit Logs, Kubernetes audit, etc.
You still have to audit those things. If a hacker gets in to your infrastructure, you have to know what they did.
Re: Launch HN: Runops (YC W21) – A better cloud shell for production apps
#18What you've basically created is automated change control, but lacking some change control features. You might want to add a set of features specific to managing change control, because otherwise I'll have to build a change management system around this. > You run an AWS CLI command in the terminal and it goes to Runops instead of AWS Most enterprises are wary of handing over control to a vendor, especially if it's t…
> Most enterprises are wary of handing over control to a vendor
Great point, we do have the Enterprise version, which is self-hosted.
> Do you find a lot of Lisp/Clojure devs out there for when you need to expand?
We won't hire engineers based on the language they know, but instead in general engineering skills, and they can learn Clojure here (already worked for the first one:)
> You still have to audit those things
Yes we do, but mostly to trigger alerts if anything happens there and to show that the accesses are either from Runops or the applications during audits. This is way lighter than relying on these as the source of truth for trails.
I'm curious about the Change Management features you think are missing. We do have review workflows and other CM-related features I didn't add here, this demo shows some of it: https://see.runops.io/videos/demo
Re: Launch HN: Runops (YC W21) – A better cloud shell for production apps
#19Re: Launch HN: Runops (YC W21) – A better cloud shell for production apps
#20Could one refer to this as a so-called "API Gateway".