Suggestions
Cristian Magherusan-Stanciu
Highlights
Here's my LLM prompting technique that increased 2-5x the amount of code I churn out per unit of time and saved me from countless hours of typing code myself ever since I first got my hands on ChatGPT early last year.
I start with something as simple as this:
Write me a <program doing task>
- followed by a
- painstakingly detailed
- list of requirements
I just write this in my favorite LLM (currently using Claude), and it usually gives me a few hundreds of lines code in a matter of seconds.
Most times the code either fails to compile, crashes or just doesn't do what I need when first running it, but I don't expect any of that.
The trick is not to give up, this is just the beinning.
I then start to iterate on that code with hundreds of simple one-liner instructions that adjust the code in small steps until it finally does what I want it to do.
I use this for the code, but also unit tests mocks and detailed test cases for the more tricky parts of the code.
As a solopreneur (my focus is helping companies with AWS cost optimization and I'm building tools that help me generate savings for my customers), the increase in productivity and time this saved me is invaluable.
I've been using AWS for well over a decade, including a few years worked at AWS as Specialist Solution Architect for Spot and Graviton, which gave me a lot of domain knowledge making it easy for me to give those detailed requirements.
Depending of the complexity of the task at hand, I usually build an initial version of a new tool within a few hours or days.
I keep iterating on these tools over multiple customer engagements, and over time some of them became quite sophisticated, for example I have one that can rightsize RDS databases, as well as ElastiCache and OpenSearch resources with automated conversion to Graviton, based on metrics.
Over the last year and a half I used this method to build more than a dozen tools that can help optimize a wide range of AWS resources across many services like EC2, RDS, Fargate, Lambda, S3, CloudWatch, EBS, ElastiCache, OpenSearch, etc.
These tools saved each of my customers thousands and thousands of dollars.
I recently started releasing these tools as a bundle for anyone out there doing AWS cost optimization at scale, drop me a DM if you're interested in that.
#development #productivity #LLM #aws #finops #tooling #automation
As mentioned in my previous post a few days ago, the main topic of the week was RDS optimization, including rightsizing and conversion to/from Aurora Serverless for over a dozen databases of one of my customers.
Initially I spent some time sharpening my saw doing a bunch of enhancements on my RDS Aurora cost visibility tool to get a better picture of the initial state and alternative configurations for each DB, then based on this data I started converting instances to more suitable instance types.
After a couple of manual changes I built a new tool that automates the process by creating a new read replica, with graceful failover once the replica is ready, followed by manual deletion once connections are drained (the deletion is not yet automated but will should already be easy to automate after I make sure it works reliably).
This new tool already saved me a lot of time, and drastically reduced the chance of human errors by manual fiddling in the console when rightsizing dozens of instances.
Using this we initially converted a bunch of them to Aurora Serverless so we could see their actual needs, then we either kept them as serverless or converted them again to other provisioned instance types based on their actual needs and traffic patterns.
This sometimes resulted in massive cost savings (the most impressive were halving a single r7g.4xlarge DB from $1612 to $806, and a whopping 78% cost reduction by converting a $201 r7g.large to only serverless instance that costs $43 monthly at 0.5 ACUs), again without doing any commitments yet.
For a couple of them that had higher CPU utilization the Aurora Serverless capacity shot way over what we expected so we ended up bringing them back to the same provisioned Aurora capacity or just slightly reduced provisioned capacity.
Looking into the high CPU utilization instances I tried to help developers identify expensive queries based on the Performance Insights console and proposed alternative queries that would perform better and we're looking into rolling those out over the next weeks.
I even started to build another tool that aims to automate parts of this query optimization process. I didn't get so far yet considering the complexity of the problem, but as usual I'll keep iterating on it as part of my work.
All in all over the 14 DBs we optimized so far (the customer had over 40 DBs and we're not done yet) this resulted in some $2750 monthly savings for the customer($33k annualized), on top of the ~$4k($48k annualized) we achieved a couple of weeks ago by selecting I/O optimized only where appropriate, besides the massive tooling improvements that will help me automate much of this kind of work going forward.
I'm very happy with this progress and looking forward to continue this work over the next weeks.
If you or anyone you know run RDS Aurora at scale and may be interested in such an exercise, drop me a DM and let's take it from there.
#aws #costoptimization #finops #rds #aurora #serverless
