Live data from Hacker News

Launch HN: Runops (YC W21) – A better cloud shell for production apps

news.ycombinator.com

11–20 of 24 posts

Re: Launch HN: Runops (YC W21) – A better cloud shell for production apps

#11
post #7
post #5

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…

Ah, great, thanks. Some of the wording made it sound like perhaps it was hooked transparently. This appears very clear.

Re: Launch HN: Runops (YC W21) – A better cloud shell for production apps

#12

How did you acquire your first customers?

It was a combination of multiple things. The first customer came from the newsletter I run called SRE Teams (https://sreteams.substack.com). Others came from intros from my network and from reaching out to people I thought we could help. When I was running the DevOps team at Pismo we used to organize meetups and knowledge sharing sessions with other companies having similar problems, this also helped.

Re: Launch HN: Runops (YC W21) – A better cloud shell for production apps

#14

We’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!

Glad to hear we could help in the future, feel free to reach out any time. We would love to hear more about your use cases and the alternatives you guys have in mind to improve the PCI assessment results. We support Azure :)

Re: Launch HN: Runops (YC W21) – A better cloud shell for production apps

#15
post #9
post #6

The 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…

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

#16
post #15
post #9

Earlier 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

Teleport is a fantastic tool. The main difference are: 1) Runops doesn't require you to have tools (kubectl, psql, etc) installed locally and don't download temporary credentials to access resources, commands execute in the Cloud. 2) Runops has synchronous reviews workflows on the command/intent level, again as opposed to getting an open session for a period of time. 2) We automatically remove sensitive data from the results of every command. 4) Runops uses Git as the source of truth for the audit trails.

Re: Launch HN: Runops (YC W21) – A better cloud shell for production apps

#17
What 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 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

#18

What 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…

I agree with many of these points, here are some thoughts on how we deal them:

> 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

Post reply on HN