Howdy out there in automation land!!!! So.... To Atomic or Not To Atomic.. that is the question? Is it not? This post is going to break into the string of "back to the basics" as we have gotten a lot of interest in Action Orchestrator of late (which is stellar) and we have a lot of customers interested in building their *OWN* adapters. The question is... do you do atomics or compiled/custom adapters or what? And what is best for you? That is what I plan to investigate and give you guys information on for this blog. You have multiple options with AO... so I want you to make the best one for your automation needs!
For a movie poster.... let's see, that line at the top sounds like something I might have pulled from some famous play....
I think works pretty well right? This is the version I liked the best out of all the movie versions.
So let my preface the two "sides" of the fence I'm going to talk about. Atomic Adapters and Compiled or Custom Adapters. To start there is two places you can look for (in documentation) to see these constructs...
So what is the difference and what do you get out of one versus the other?
Atomic Adapters
Let me start with Atomic Adapter. An atomic adapter is made up of Atomic workflows. One of the key benefits of it is that you do not need *ANYTHING* else other than AO to make it work. You build workflows in AO, mark them as Atomic and you are done! How do you do that?
1. Open up your workflow
2. Go to the main workflow properties
3. Click the "Is atomic workflow" checkbox and give it a Group. What is a Group? That is how the atomic workflow will be organized in the UI. This will position it in your ACTIVITIES section as a drag and drop component. The group will be the heading it will be under.
So where and when do these fit best? In my opinion, if AO can make the calls and already has all the functionality you need built in, then these make the most sense. They are also quickest to develop and deploy and require no extra coding knowledge/skill/etc. If you are building an atomic adapter you should make all your atomic workflows very "micro" workflow in nature. In other words, do just 1 operation, maybe wrap it in a little error handling if you like... and be done. Do *NOT* make them overly complex or do a lot. They should be a bunch of micro workflows or activities in nature only. A word of caution... make sure the workflow is tested and good to go. Once you check "atomic" and make it an atomic workflow, you cannot click the "RUN" button anymore to test it. You can always unmark it from being an atomic but in my experience I suggest fully vetting out the workflow, then checking the atomic box and moving onto the next thing. The drawbacks to Atomic Adapters is that they are bound to what AO currently can do and bound to the AO basic UI. If you feel you need something a little more advanced... then the next section is for you!
Compiled Adapters
Also called "Custom" adapters in the documentation. These are adapters you *BUILD FROM SCRATCH*! So it is an exciting feature but pretty advanced in nature. I might have a series on how to do this coming out on the blog later this year.. but I need to figure out how to make it most effective for my great readers! So what do I mean, build from scratch? Well at a high level you must do the following things in creating a customer adapter....
- Get the adapter template code base (GO, Python, or Java) from Support (TAC). Cisco provides you with a basic foundational structure in one of those 3 languages so all you have to worry about is filling out the code for your main parts. We provide the dockerfile, yaml for Kubernetes, basic code, etc in these templates.
- Write Schema for your adapter as you have to "teach" AO how to understand your adapter. You must create them in the order of ACCOUNT KEYS, ADAPTER, TARGET, then ACTIVITIES and EVENTS. You can do this via the UI under Admin->Schema or you can do this directly via API call. You can make the API call against the /schemas endpoint and the body would need to be both schemas(data and view, see below).
- Design activities for your users in the UI via the schema
- Write the appropriate code (GO/Python/Java) for your target, adapter, account keys, and activities.
- Compile your adapter as needed
- Convert your compiled adapter to a docker image
- Deploy your new docker image to a Pod via Kubernetes into your CCS/AO setup
As par of your schema creation you have to understand that you would need to create both "DATA" and "VIEW" schema. Data is what is passed across the wire and view is what makes up the UI/UX. I am not going in too deep on this post because that is not what this is about... this post is about you making the right decision for your use-case on what path for you to take!
So what is the value here.... the pros? The pros are pretty much anything is possible. You can bring in packages from other languages and design your activities pretty much in whatever you want. I find custom adapters are best when...
- You have a pre-existing SDK for some system/API that you can just wrap the adapter code around
- The system you want to plug into has some kind of authentication scheme or endpoint scheme that AO does not support yet.
- You want to do some advanced work with the UI/UX on your activities
- You want to create highly customized targets, events, etc
So am I pushing you in one direction or the other? Of course not! I have wrote adapters in both!!!
Cisco does as well. The adapters you have when you install AO are custom or compiled adapters. The adapters we also offer on our public git at https://github.com/cisco/ActionOrchestratorContent are atomic adapters. They include ones like ACI, UCSD, VMWare, Azure, etc. For those you can just plug into our git and download at will... not authentication required! For me personally, I have wrote a couple atomic adapters for our internal systems that just use basic API calls and what not.... on the custom side I have been working on the following adapters: Webex Teams, Intersight, MongoDB, and CSOne (our support case system). Both CSOne and Intersight are great examples of the SDK "reason" to use custom adapters. In Intersight there is already a great python SDK we publish...so why re-invent the wheel??? Word of advice, don't! :) Just wrap it in the adapter code and use it. Same thing with CSOne. I wrote a python API wrapper package for it and instead of keeping up multiple code bases, I just wrap it in adapter code and now just keep up the python package and I have less work to do but I can serve multiple user bases. The other side of the coin with custom adapters is that is it is a very advanced concept and does require a bit more work and knowledge of coding.
Overall, I think you should be fine to use either one. Pick what best fits your use-case. Use them both! Use AO a ton! But with the amount of questions and queries I've been seeing from customers I thought it was time to put this on paper... or blog in this case. If you have any questions on these, please post below or hit me up on my email or social media below!
As always I have a video on the same and dive into it a bit deeper with you.... I also (in the VOD) will give you a sneak peek look inside some of the great AO work that was done at Cisco Live US this year in San Diego... we did some major stuff, including pushing an ROI of just under 1.25 million during the show... using AO only in the span of just 6 days. Can you imagine doing the same for your IT department??? Why would you not want that? :) Do you want to know how? You have to watch the video :) If you have interest in AO or getting plugged in... please reach out to me and I will get you plugged into the right folks! My email and social contacts are always posted at the end of the blog.
As always... ONTO THE VIDEO!
|
Play recording (25 min 35 sec) |
|
|
Recording password: mP7dgTdh |
|
Standard End-O-Blog Disclaimer:
Thanks as always to all my wonderful readers and those who continue to stick with and use CPO and now those learning AO! I have always wanted to find good questions, scenarios, stories, etc... if you have a question, please ask, if you want to see more, please ask... if you have topic ideas that you want me to blog on, Please ask! I am happy to cater to the readers and make this the best blog you will find :)
AUTOMATION BLOG DISCLAIMER: As always, this is a blog and my (Shaun Roberts) thoughts on CPO, AO, CCS, orchestration, and automation, my thoughts on best practices, and my experiences with the products and customers. The above views are in no way representative of Cisco or any of it's partners, etc. None of these views, etc are supported and this is not a place to find standard product support. If you need standard product support please do so via the current call in numbers on Cisco.com or email tac@cisco.com
Thanks and Happy Automating!!!
--Shaun Roberts
Twitter: https://twitter.com/LordAutomation
LinkedIn: https://www.linkedin.com/in/srobertsmba/
