RigD simplifies your work, specifically your AWS serverless deployments. Everything is brought together in Slack where you can use RigD to perform activities. An activity is run against a specific tool that RigD is connected to, that means an AWS account you provide. The goal of this guide is to explain how we designed RigD and help you appreciate the value it can provide you. Deploying faster and with less context switching allows developers, architects and DevOps teams to deliver functionality to the business faster.
Like most applications it all starts with the user interaction, for RigD that’s Slack. We chose Slack as our vehicle for user interaction for a few reasons.
First, it’s one our users and developers love. So, we don’t have to set off on an impossible voyage convincing our busy users to spend a lot of time and energy learning a new interface.
Second, it’s a great product with the right set of capabilities to serve our needs and those of our users. We can provide a text focused interface and throw in just the right amount of web forms style functionality to ensure users can get the job done.
Finally, and most importantly, it’s fundamentally a collaboration platform and we firmly believe that communication and collaboration are central to effective execution.
Our RigD Slack App will deploy our Bot RigD, into your Slack workspace. When you send it a message it will send it on to our service and provide responses back. It can listen for messages sent directly to it or any sent in a channel.
We at RigD will be the first to tell you that having a poor Natural Language Processing (NLP) experience can be frustrating and quite a few people have suggested it might even be too hard to pull off. However, we believe that just because something is hard doesn’t mean it’s not worth doing. Our goal has been to build a Natural Language interaction experience that is truly great. We know we’re not there yet, but we think we have something that works now.
In our NLP service we take the messages from Slack and identify what activity you are trying to perform. Once identified, we will carry on a dialog with you to gather any inputs needed to execute the activity. Additionally, we will attempt to simplify your work by learning from your past interactions and providing suggestions.
Since we know we don’t have a perfect system, we’ve also made sure we are set up to learn from our mistakes. Any time there is an error we will capture the interaction and evaluate if and how we can improve the system. This could be things like:
We know we won’t find everything on our own, so we always appreciate your feedback and suggestions.
This is where all the grunt work happens. We take all the info gathered through the NLP service and transform it to a ready to execute API calla then we pair it with the securely stored tool information you provided to RigD. These Calls are then executed against your environment.
While this is grunt work, it’s also the most important part of RigD. When you provide us with the right information, you expect and deserve to get results. We’ve made an effort to help ensure this by ensuring we collect required inputs and validating input types where possible. In the unfortunate case where something does go wrong we will evaluate it to identify any opportunities for improvement. Your feedback on things like error messaging is greatly appreciated, as what’s clear to us might not be clear to all.
This one’s pretty straightforward. While there are some activities which strictly work against RigD, the fundamental objective is for us to help you get your work done. So RigD needs to be able to operate against your environment. We realize this can seem a bit unsettling to some, but there isn’t really a way around it. We strongly encourage you to establish a permissions model for the account you provide to RigD that you are comfortable with.
For AWS users this means a policy attached to the RigD user that allows only what you want to be able to perform through RigD. This will ensure that any attempt to perform an activity which is not allowed will meet with failure.
As RigD continues to evolve we will keep you up to date on what RigD can do and how to best enable or disable activities.
Our last step in this process is to handle the API call response and send it back to you. Easy right, just dump the text into slack and we’re done? Well we tried, turns out not all API calls give back great messages, or any message. Here again we have tried our best to organize the information in a way that’s easy to consume, and feedback is appreciated.
Another advantage of using Slack is you can leverage the Slack search to quickly find the results of an old activity or rerun a past activity from RigD’s History.
We mentioned a few times how we log errors and evaluate them for improvements, well we also analyze successful activities in order to make your work easier. Every time you run an activity with RigD we evaluate it in order to provide better suggestions and an overall better experience for you.
Now let’s look at how you interact with RigD. Since we want it to be as efficient as possible to interact with RigD we don’t make you use Slack Slash commands or always start a message with @rigd. You just start typing and we’ll respond.
Here is a simple example
As mentioned before we are striving to put together a truly excellent Natural Language interaction. However, we are not yet at a point where we can properly interpret wide open messages. We’ve started with the following general structure to help ensure success.
Each activity starts with a verb something like; create, list, delete, update, get, start, or stop. Our NLP engine supports some flexibility here in that we will pick up on variations; add, new, or deploy, for example, would be interpreted as create. With things like list and get, alternatives can get a little tricky; list generally returns to you a numbered set of items, while get returns details on a specific item. Words like show or display can be hard to interpret when both list and get are both applicable.
After the verb we look for a service identifier. This is the text that helps us know what service you are trying to operate against. In the case of AWS this would be text like; lambda, codebuild, or apigateway. The service identification helps drive down the possibility of incorrect identification as many services have very similar objects and operations.
Finally comes the context, this is what enables us to zero in on what you are trying to do. Some examples of context from AWS Lambda might include; function(s), alias(s), or function code. As we mentioned before, verbs like show might be for a list or a get activity, a context that’s singular or plural can help us figure that out. We’ve also started expanding the context to support including inputs. This gives RigD a more CLI like feel.
When we put it all together your typical activity structure looks like this:
verb service context
And here some examples and variations
There are lots more activities available and we are adding new ones all the time. You can always run the activity help for general help and to see the list of available services.
For details on the activities for each service and an example run help <service name>.
We hope this has provided some insights into how RigD Works and inspired you to give it a try. You can sign up and try RigD for yourself. Our mission is to help you get work done faster. Faster deployments of your serverless architectures, means your customers get what they need sooner.