Blog
I Built a Kanban to Learn Autonomous Development on AWS
I built a kanban with autonomous AI agents on AWS as a learning project. Here’s what ‘autonomous’ actually meant, what broke, and how I keep it under $5/month.
May 4, 2026
Another category description is required
I built a kanban with autonomous AI agents on AWS as a learning project. Here’s what ‘autonomous’ actually meant, what broke, and how I keep it under $5/month.
Slack is an essential tool at Curious Orbit. We use it to communicate internally - whether we’re looking for project updates from Asana, figuring out who is on vacation, or even who is at the front door. We also use it for all our AWS Managed Support customers as a way to provide technical support and keep our customers up-to-date with what is happening in their AWS account.
At the last Re: Invent conference AWS announced several additions to their Artificial Intelligence and Machine Learning portfolio. One of the new services, in particular, caught my attention - AWS Comprehend. In previous posts, I’ve talked about how important AWS’ AI/ML solutions are to organizations, as well as how easy they are to use.
AWS Comprehend is no different. It’s an easy to use Natural Language Processing (NLP) service which allows you to analyze text. Since Re: Invent I’ve had some different ideas on how to test out the service. This week I landed on a plan to examine sentiment in tweets to @awscloud.
In a recent blog article, I talked about [Going Serverless in 2018] (https://curiousorbit.com/blog/going-serverless-in-2018/), so I figured I follow that article with a high-level overview of Lambda.
When I mention this strategy during a training session or maybe during a customer visit I often get this following question: “What the heck is a Lambda function?!”
I understand why I get this question so often. In the majority of cases when an organization decides to start using AWS for their computing needs they begin by ‘Lifting and Shifting’ a workload to the Amazon platform - while this approach is an entirely valid strategy it doesn’t mean your work is finished.
I know it’s the season to set resolutions for the year, but I’m suggesting we do something a bit different this go around. I’m not telling you to forget about your health-related goals - let’s chat in March - what I’m suggesting is adopting a Serverless first approach in 2018.
Exactly what do I mean when I say Serverless first? It’s pretty simple really - [we avoid adding additional Operating Systems] (http://curiousorbit.com/blog/go-serverless/) at all costs! Whenever possible, we use the following principle for solutions deployed on the AWS platform:
[Amazon EC2 System Manager (SSM)] ( https://aws.amazon.com/ec2/systems-manager/ ) is an agent-based solution that allows you to remotely manage and collect inventory data from EC2 instances as well as on-premise Windows and Linux systems.
Outside of managing long-running EC2 instances, you can also use SSM to manage your [Amazon Machine Images (AMI).] ( http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html ) Think of an AMI as a gold-image, it’s a pre-built server image that you can use as part of an [auto-scaling] ( https://aws.amazon.com/autoscaling/ ) solution, reference in a [CloudFormation] ( https://aws.amazon.com/cloudformation/ ) template or when manually deploying an instance via the CLI or through the Management console.
How often do you take EBS snapshots? EBS volumes are automatically replicated across multiple servers in the Availability Zone (AZ) where they were deployed, but for data durability you also need timely snapshots of your EBS volumes.
While it’s possible to manually create snapshots of your EBS volumes, a better, more reliable solution is to leverage AWS Lambda to automate the process.
During the first part of my career in IT, I helped organizations implement enterprise-grade Systems Management Solutions - think IBM Tivoli, BMC, HP Openview, etc. - you name it and I most likely installed, configured and maintained the systems companies use to monitor and manage their IT infrastructure. The ‘holy grail’ of Systems Management was a centralized console. The idea was to consolidate all of the information from all of the monitoring and management tools into a single dashboard where everyone could get the information they needed regardless of job function.
I had numerous conversations this past week about the future of Infrastructure-as-a-Service (IaaS) and how it is increasingly becoming the third option when building solutions on Amazon Web Services (AWS).
Granted, IaaS isn’t going anywhere soon, but based on the conversations I have been having recently, both Serverless and Managed Services seem to be gaining traction when you are building something new and not shifting existing technology to AWS.
The biggest benefit I see with building Serverless solutions is that you don’t have any OS’ to manage. I wrote about turning off as many OS’ as possible earlier this year, and I still believe the value of OS’ is diminishing - quickly.
When I first started using Amazon Web Services (AWS) back in 2007, the majority of people I talked to who were interested in leveraging AWS wanted to talk about how they could use AWS to help reduce their IT costs. In the vast majority of cases, those customers were interested in shifting IT related expenses from capital to operating expenditures.
As time went on, a change in how people thought about Public Cloud occurred - rather than using AWS to help them save money organizations now wanted to talk about how they could use AWS to deliver IT projects faster.
I love BaseCRM! It’s been my go to CRM for some years now, and when I decided to start my own AWS consulting and managed services business, I knew exactly which CRM tool I was going to use.
One thing I needed was an easy way to capture lead data from my static website which I’m hosting via the Simple Storage Service (S3) and delivering content via CloudFront. If you’re a regular reader, you know that one of my goals for 2017 is to shut down as many OS’ as I can, so I decided the integration of my S3 website with BaseCRM would serve as an excellent example of what is possible.
When I talk to folks about serverless computing on AWS they usually say, “oh ya, you mean Lambda right?”
Sure, Lambda is the grand-daddy of serverless computing, but the AWS platform has many other serverless technologies that you can leverage to build applications on AWS.
Before jumping into a few of the serverless options that are available to us, it’s important that we define what I mean when I say “serverless” computing. It’s pretty simple - I define serverless as any service where I don’t have to think about CPU, RAM, or Storage to use the service.
Let’s make 2017 the year where we wage war on the Operating System. I’m not going to lie to you; it won’t be easy. We’ve been frenemies for so long now, and OS’ have ingrained themselves so deeply in how we develop solutions for customers removing them is going to be tough. But their time has passed and here are just a few reasons why.
Be honest, how much time do you spend managing the operating systems in your infrastructure? I bet its way (way) more than you think. What benefit do we get out of this relationship? None. Operating systems wake us up at all hours demanding that we fix them, we have to regularly keep them up-to-date (which usually results in more late nights)
A few weeks back now I wrote an article about how I was using the newly released (at Re: Invent) AWS Rekognition service. Since then I’ve been asked by numerous people if I would write a follow-up article on my impressions and (most importantly) costs.
I know that this is what most folks are interested in, so I’ll start here. Before I jump into what it cost me to run this service, I think it’s important to take these numbers with a grain of salt. I didn’t write down exactly when I enabled the service, but I’m pretty sure it ran for roughly three weeks in December 2016. I’ll repost the full costs for January 2017.
Awhile back now I started adding IP cameras around various points of my house. It began as a way to quickly check if I had left the garage door up (I’m prone to doing that) and just grew from there.
I use an old Mac mini and a fantastic piece of software called Security Spy to manage all the cameras. The only issue is that even after adjusting the sensitivity and the capture areas I still get a ton of false positive alerts. By that, I mean notifications of motion with no people in the image.
Recently, I started to investigate the possibility of using a SaaS-based helpdesk for our AWS customers. After looking at the usual suspects, ZenDesk, FreshDesk, and GrooveHQ and comparing what we could do for $free$ (it is just a test case at this point) I decided to go with GrooveHQ.
After creating your account in GrooveHQ, they provide you with a forwarding email address. If you want to, you can provide this email address to your customers and start receiving support tickets right away. I wanted to use an email address tied to my domain, so I needed to forward inbound emails to the address provided to me by Groove.
Awhile back I wrote an article about how I have been using several AWS services (EC2, RDS, SQS, etc.) to run a small hockey pool website. In that article, I mentioned that one of my biggest goals was to move away from EC2-based Cron to Lambda and to build a more “loosely coupled” application.
Since a hockey pool website without stats would be pointless, I figured it was a good place to start. In this post, I’ll talk about how I moved from my original Cron-based setup to Lambda.
In my last article, I talked about how I moved from using Cron on an EC2 instance to download stat files for my hockey pool website to using scheduled Lambda functions.
In this article, I’ll talk about how I removed another Cron job by enabling S3 event notifications an, to add jobs to the SQS queues I use to parse all the stats.
Enabling S3 event notifications is really simple. Select the S3 bucket that you want to enable notifications on, select “properties” and then expand the “Events” menu option.
Send a paragraph about what you're trying to do on AWS. I'll come back with how I'd approach it, or a pointer to someone better suited.