Migrating SmartMonsters to the Cloud. Part Two: Breaking Up the Bots.

TriadCity’s robots Death, Help, Marvin and Oscar are AIML-based chatterbots architected monolithically. Each bot is its own application: TriadCity client code, AIML interpreter, AIML files, plus each bot's layer of individual behaviors. They're built and deployed independently of each other. The plus side is they're free to evolve and scale independently; the downside is there's a lot of duplication.

While migrating to AWS we want to break them down to sharable components. We especially want a shared AIML interpreter accessible from multiple protocols and device types. Advantages:

• Enables a new generation of bots accessed independently of TriadCity. For example, we can turn Oscar into his own application, accessing a single scalable AIML brain from mobile devices, Web sites, Twitter feeds, and the existing TriadCity bot without having to maintain separate AIML repositories for each client.
• Enables AIML updates independent of the Java code for these multiple platforms, doable in real time without rebooting the bots.
• The shared AIML interpreter can scale independently, becoming fully elastic in The Cloud.
• Centralized AIML files can be validated globally within a consolidated staged CI/CD pipeline with appropriate tests at each stage.
• It's easier to swap-out or enhance AIML interpreters without having to rebuild and redistribute an army of dependents.

Here are the migration steps:

1. Pull the AIML interpreter out of the bot code, into a standalone application accessed as a RESTful service on Elastic Beanstalk.
2. Redesign the AIML interpreter to serve all of the bots. The REST API will be super-simple: a GET call parameterized with the bot name and the input String.  Return a JSON object.  EB provides elasticity.
3. Remove the AIML interpreter from the Web site, having the appropriate JSPs now RESTfully GET their conversations from the service on EB.
4. Remove the AIML interpreter from the TriadCIty bots, having them similarly call into the service.  I decided while I was at it to consolidate the four existing bots into a single JAR rather than continuing to build each as a separate project.  This is simpler, and there’s very little Java code distinguishing the bots.  A configuration file determines which bot to run; the consolidated code figures out which bot-centric classes to load.
5. Configure Jenkins to manage Continuous Delivery.  The CI build fires when updates are made to SCM.  The build lifecycle now includes two cycles of AIML validation.  A syntactic pass ensures XML correctness before changes are pushed to production; a semantic pass validates AIML rules by comparing expected to actual outputs.
6. Log interpreter inputs which fail to match AIML rules, triggering default responses.  This feedback will let our botmasters know what their users are interested in, and how their bots are performing.  Write logs to DynamoDB, with a simple schema: bot name, <input>, <topic>, <that>.  Schedule a weekly cron to report on these failures.

Migration took two working days. To my surprise, DynamoDB logging required a full third day.  I struggled to get connected — turns out the published Developer Guide is missing one key point, and incorrect on another.  To connect you have to specify the AWS region, duh.  Integer keys are not necessary, Strings are fine; there's a "@DynamoDBAutoGeneratedKey" annotation in the Java SDK which'll auto-gen them for you.

One more enhancement seems obvious.  Writing logs directly to db is synchronous: our RESTful API server will block a thread during the transaction.  We can avoid the block by posting log messages asynchronously to a queue. It's half a day to update the interpreter to write to SQS instead of directly to DB. An EB "worker tier" consumer pulls from the queue and does the DB write.

The platform is now in place upon which we'll build a new generation of bots more advanced than before. Watch this space.