[HN Gopher] Launch HN: Abbot (YC S21) - ChatOps as a Service, in...
___________________________________________________________________
Launch HN: Abbot (YC S21) - ChatOps as a Service, inspired by
GitHub's Hubot
Hi HN, we're Phil and Paul and we make Abbot (https://ab.bot/) - a
tool for building and running simple automation via chat (currently
Slack, Discord, and MS Teams). It's common to go from "I have an
idea" to having a fully deployed chat command in under an hour.
The term "ChatOps" comes from GitHub, where the two of us worked
together. GitHub was always a distributed company and early on
developed a culture of doing most work via chat. Engineers
automated the most repetitive processes (and some of their sense of
humor, too), and that grew into a shared chat-based command line
called Hubot. By typing terminal-style commands into chat, you can
execute any sort of process that it makes sense for your team to
automate. And because it's in a shared chat room rather than hidden
on your own machine, every time you run a task, you teach someone
else how to do it. Hubot has been wildly successful at GitHub and
is amazing in action. We saw GitHub's ops team fight off the
biggest DDoS attack in history from chat using Hubot, while people
were cheering along in another channel using Hubot to find
appropriate hype gifs. But the effect on day-to-day work was even
more amazing. Anyone could easily find out what was recently
deployed, how to deploy, monitor servers, page people, you name it.
New employees could see how to do all those things as soon as they
joined. Since there were fun commands inside of Hubot, it was great
for team building, too. We believe more companies would benefit
from working this way. When Covid hit, many companies suddenly
found themselves struggling to make distributed teams work better.
It is challenging to understand what everyone is doing, or even how
to do regular tasks, since it's not easy to tap someone on the
shoulder and ask. We decided to build Abbot to help teams adopt
this style of work. When we started, we built a list of what
_wasn't_ fun about Hubot. Hubot required a lot of configuration,
wasn't reachable if chat was down, testing new scripts could be
painful, there was no unified way to manage permissions, and so
forth. We built Abbot as a hosted platform that handles all these
things so developers don't have to. Because Abbot is a platform,
we provide a unified interface for auditing, access control, data
access and more. If users understand how to use a single Abbot
command (or "skill" in Abbot parlance), they'll know how to use any
other Abbot command. Since we built Abbot to support multiple chat
systems, we made it so that all Abbot commands are cross platform -
commands written for Slack will work in Discord, and so forth. You
can write commands in C#, Python, or JavaScript (we will support
more languages in the future). We also do a lot of things Hubot
does not, like allowing users to control access to the execution of
their commands from inside of chat, or exposing an API endpoint for
every command so that they can react to the outside world. There's
nothing to fork or configure - you can get started in two clicks
from our website. Abbot has a Package Directory where people can
share the commands they've written. There are a few dozen packages
in the directory today, with more being added every week. Packages
are MIT licensed and installable in one click. Because it's so easy
to create new commands, teams tend to create a lot of small ones
that accomplish a single task. For example, we have a `tweet`
command that allows us to use chat as our communal Twitter client
(available in the Package Directory at
https://ab.bot/packages/aseriousbiz/tweet). Today, people use
Abbot to deploy Git branches to staging environments, track daily
standups, figure out time zones for all their teammates, give each
other internet high-fives (well, sparkle points), and even open
their office door. We are focused on DevOps and customer support
teams right now, but believe ChatOps can make a big impact on every
team that has a channel in your chat. We are open for business!
You can add Abbot to your Slack, Discord, or MS Teams chat by
clicking "Try for free" at https://ab.bot. We have a free tier that
allows people to try it out without any commitments. We don't ask
for any information to sign up, you just have to authorize Abbot
into chat. For paying users, we charge based on the number of
custom commands, number of actions taken, or access to paid
features like access controls. Right now we are SaaS only, but will
offer a hybrid-premises version in the future. We are sure that
many of you have built your own chatbots and ChatOps tools before.
We're especially interested in hearing about what worked well and
what was challenging when building and operating them! And we hope
you can give Abbot a try. Have at it, HN!
Author : icey
Score : 136 points
Date : 2021-07-27 16:07 UTC (1 days ago)
| holman wrote:
| Super stoked to see you launching after working on it for so
| long!
|
| I still think Hubot (and bots in general, a la GitHub's internal
| usage) is severely undervalued. GitHub's usage of internal chat
| was pretty groundbreaking, which I think led to the movement
| behind Slack's growth. But there was a missing point in the rise
| of chat- namely, scripting automated processes and debugging
| collaboratively in public (internally). Which makes sense, since
| Hubot was a pain to set up and build a company around. So yeah,
| really excited about Abbot to jump in that hole in the market.
| haacked wrote:
| Thanks holman! That means a lot coming from you! :)
| airstrike wrote:
| A bit off-topic but the name immediately reminded me of
| https://www.abbott.com/ which is a ~$215B market cap behemoth
| icey wrote:
| We tried to buy their domain from them, but they haven't gotten
| back yet. I'm still hopeful :)
| arthurcolle wrote:
| abbot.com might be cheaper
| haacked wrote:
| And better fits the brand. We want to avoid that extra "t"
| at the end. :)
| nuclear79 wrote:
| Sweet, this is sick!
| haacked wrote:
| Thanks!
| eob wrote:
| I've been playing around with Abbot for a few months and the
| experience has been awesome. It feels like Twilio but for chat:
| takes the cost of writing a bot down to just a few lines of
| simple code. Excited to see it on HN -- congratulations on all
| the progress!
| icey wrote:
| Thank you Ted!
| tyingq wrote:
| Interesting, though I'm struggling a bit for when "chat
| initiated" is the best trigger for things that aren't in the fun
| category.
|
| That is, when is chat-initiated typically a better fit than
| something initiated by a check-in, build, incident detection, and
| so on?
|
| (Not knocking it, just curious)
| icey wrote:
| Great question -- chat is a great interface for anything that
| falls out of the "easy to fully automate" category. As an
| example, we use continuous deployment internally; but there are
| times where we might want to deploy a branch to a branch lab
| for experimentation. If that happens, doing it from chat lets
| everyone else know that it's out there (and how to do that
| deployment).
|
| Chat is also a great environment for getting notifications
| about extraordinary events. We get notifications in chat if a
| link on our homepage is 404ing, whenever deploys happen, or as
| scheduled updates for things we want to pay attention to but
| don't want to manage a separate website to handle them.
|
| We usually start with small commands and then grow them to
| automate more of the "well trodden path" as we understand what
| we want to automate. Because every command (we call them
| skills) can expose an API, it's possible for an Abbot skill to
| respond without any person being involved.
| haacked wrote:
| Another example we just published is about tweeting from your
| company's Twitter account from chat. This is a great use-case
| from chat. https://blog.ab.bot/archive/2021/07/27/tweet-from-
| chat/
|
| A big benefit is that you don't have to share credentials from
| the Twitter account, but still make it available to people in
| your company.
| karlclement wrote:
| This is amazing, can't wait to setup my DevOps processes to be
| triggered by Abbot commands. Winner winner.
|
| Can I use Abbot along with Terraform on ECS? Would love to setup
| some deploy scripts
| haacked wrote:
| Thanks! I'm not too familiar with Terraform on ECS, but if
| there's an API, then you can script it with Abbot.
|
| For example, we have an existing package that uses the GitHub
| deploy API to deploy software
| https://ab.bot/packages/aseriousbiz/deploy
|
| If you trigger your deploys using GitHub's API, then you could
| just use that skill. Otherwise, you can copy that skill's code
| and adapt it to your needs. Hope that helps!
|
| (In case it's not clear, I'm the "Phil" in the post) :)
| karlclement wrote:
| Thanks Phil, this is awesome. I'm sure I can leverage AWS
| API/cli. Also could be a great fit to use Github Actions
| along with Abbot
| icey wrote:
| boto3 is available in Python skills too, so there's
| probably a shortcut there for you :)
| cocoflunchy wrote:
| This looks great, I just created a command to trigger a job in
| circleci and it was very easy to get started.
|
| Is there a way to have commands that are approved by another
| person (for example, `@abbot deploy skip-tests` that has to be
| approved by another team member with a thumbs up reaction or a
| reply?)
|
| Is there a way to add replies to the original message from the
| bot directly? Or at least respond to the same channel? (like: I
| trigger a deploy, and the bot sends a message to the slack
| channel when the deploy is done)
| haacked wrote:
| Yes, you could use Abbot's support for messages with buttons.
| https://blog.ab.bot/archive/2021/06/08/user-interface-suppor...
|
| In that case, when someone runs `@abbot deploy skip-tests`,
| you'd present a message with a button. You'd have to validate
| the user that clicks the button yourself.
|
| Abbot does have support for ACLs on skills, but it's for the
| whole skill. It doesn't yet support restrictions on actions
| within a skill.
|
| Let me know if you attempt this and run into problems. I'm
| happy to review code! :)
| thanksforfish wrote:
| Any thoughts on how customers should think about securing their
| skills? ChatOps exposes skills that may provide deep access to
| deploy code or modify system configuration. Slack doesn't have
| the same security as an SSH session (password protected private
| key). I'm seeing concerns around phone theft, evil maid, spouses,
| or former employees who haven't had Slack access pulled.
|
| From my end, I think these are solvable but may require thinking
| about the problem differently. How are you thinking about
| security?
| haacked wrote:
| Absolutely! We think about security on multiple levels.
|
| For our threat model, we focus on _companies_ using Slack,
| Discord, and Teams, though our efforts apply to communities,
| etc. For the sake of this question, I'll focus on companies
| using Slack, but most of it applies to the others.
|
| Even without Abbot, if someone gains access to an employee
| Slack account, they can do immense damage. So it's very
| important for companies to enforce good security on Slack such
| as 2-factor auth, etc. If you use Abbot, that's even more
| important. To interact with Abbot in chat, a user must be
| logged into your Slack organization. So we encourage customers
| to take their Slack account security seriously.
|
| Now it may happen that a Slack account is compromised despite a
| company's best efforts. So the next level of protection is the
| ability to protect skills using Abbot's access control. You can
| restrict skills to a limited set of users. That makes it
| possible to follow the principle of least privilege and reduce
| exposure of the most sensitive skills.
|
| Finally, despite our best efforts, there may be the case where
| someone gains access to a privileged account. Abbot logs every
| interaction it has with users, whether through the Bot console
| (in the website) or via chat. So if someone does somehow get
| access, you can audit what activities they took, what secrets
| they accessed.
|
| It's also important to look at security from the perspective of
| a skill author. To create a skill, a user has to be a member of
| the "Members" role in https://ab.bot/. This requires that they
| are a member of the associated Slack organization and have
| logged into https://ab.bot/ with their Slack account (we don't
| implement our own authentication).
|
| An Abbot Administrator can choose to let anyone in the Slack
| organization automatically be added to the "Members" role when
| they log in. That may be appropriate for smaller high-trust
| companies. For larger companies, administrators may want have
| tighter control on access to the website.
|
| Skill authors are encouraged not to embed tokens and other
| secrets in the code for skills. Instead, use the secrets
| management built in. There's also a proxy link feature for
| certain cases where a secret is embedded in a URL and you don't
| want the secret exposed even to skill authors.
|
| That's where we are today.
|
| In the future, we'd like to integrate with Active Directory,
| LDAP, etc. for managing access to the site and skills. Also, we
| know that many systems people want to access are going to be
| behind a firewall. So we are looking into onprem options, but
| those may be further down the road.
|
| If you have some ideas on where we can improve or areas we
| should be thinking about, we are definitely interested in
| hearing about it. This is very important to us.
| thanksforfish wrote:
| Great answer, thanks for the detail!
| xfitm3 wrote:
| Slack is often misconfigured - mid-sized companies without a
| proper IAM team/engineer often enable auto-provisioning which
| sends an invite to @<whitelisted domain>. If you can identify
| a e-mail reflection vuln on the domain you can parlay that
| into a Slack invite, and while ChatOps might be the least of
| the concerns I fear this is reinforcing bad hygiene.
|
| Additionally companies forced to be SOX compliant require
| separation of duties, which is often incompatible with slash
| commands that impact production or revenue generating
| infrastructure.
| icey wrote:
| > If you can identify a e-mail reflection vuln on the
| domain you can parlay that into a Slack invite
|
| On reread, I realize that I'm not sure I understand what
| sort of attack you're talking about. While I think we've
| done a good job of making Abbot a safe entity, could you
| describe how this works? It's possible there's an attack
| vector we haven't considered. Thanks for sharing!
| icey wrote:
| For teams that are concerned about whether their Slack is
| configured correctly, Abbot can be put into a waitlist mode
| where an administrator on the Abbot team has to explicitly
| approve any access. No matter how Abbot is configured, all
| commands are still logged.
|
| SOX compliance is a bit outside of our domain of influence;
| our goal is to give people the most powerful tools we can,
| in a way that they can run it in their environment without
| having to reinvent the wheel.
| TechBro8615 wrote:
| Sounds nice. I would encourage you to build a Mattermost
| integration too; it should be similar to Slack.
| icey wrote:
| Mattermost has come up a couple of times recently. Along with
| Matrix, it's probably our top requested platform. Right now
| we're focused on improving the core platform, but the nice
| thing is when we add new platforms all the skills written for
| other platforms should work on day one. I added your request to
| our internal tracker for Mattermost and will try to reach out
| once we add it (your email isn't in your profile, so if you
| want to email me at paul@ab.bot I can add you to the list).
| emilycook wrote:
| Hey I'm the Community Manger at Mattermost, if yall do build
| the integration and need any help with anything, feel free to
| reach out to me (emily.cook@mattermost.com) or join our
| community server http://community.mattermost.com/
| icey wrote:
| Wow, awesome! Thanks Emily!
| gingerlime wrote:
| Neat. We used Hubot for a bit, but it was fiddly and cumbersome,
| so we eventually ditched it. I think we managed to automate the
| few useful commands with our CI/CD instead... but I definitely
| liked the idea in principle.
|
| Can you explain what dedicated skill runner means? saw it on the
| plans page, but couldn't find (or missed? on mobile now) what it
| is and why it costs extra...
| icey wrote:
| Hubot still has a special place in our heart. The only reason I
| ever learned Coffeescript was to build scripts for it. But I
| have definitely broken installs more than once. We tried to
| make Abbot very simple to run for exactly that reason!
|
| Right now all skills run through the same infrastructure. We
| are figuring out our package management story currently, but
| today everyone has the same packages loaded, and all requests
| come from our shared infra. Some companies we talked to have
| specific library needs (especially internal libraries) or
| requests for dedicated IPs for their runners. For most teams,
| this probably isn't needed. We spend a lot of time making sure
| things are fast and scale, so it's mostly about control for our
| customers.
| ianceicys wrote:
| Very cool to see. Going to have to play around with this. Would
| love to see additional quick take youtube videos about the value
| prop. Thanks!
| icey wrote:
| Thanks Ian! That's great feedback, we should absolutely make
| more YouTube videos (we have a few here, but it's been a little
| bit since we've released a new one: https://youtube.com/playlis
| t?list=PLs8WZvPC2qpBFpmzI6Fpa-6NB...).
|
| We also wrote a blog post about how we think about our problem
| space and value proposition recently:
| https://blog.ab.bot/archive/2021/07/15/tools-for-inside-
| the-....
|
| Not quite as succinct as a video, but it might help paint a a
| more vibrant picture of how we see the world.
___________________________________________________________________
(page generated 2021-07-28 19:02 UTC)