[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 : 96 points
Date : 2021-07-27 16:07 UTC (6 hours 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!
| 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?
| 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-27 23:00 UTC)