When scuba diving, a diver has releases on their equipment such that in cases where no alternatives are available, they can ditch heavy gear and swim for the surface.
I liken this to the approach teams take to building software, where the diver is the business logic and the equipment is the framework/s that they are relying on. Unfortunately, all too often, the business logic ends up too tightly coupled to the framework du jour and if the decision is made to change frameworks, replatform or otherwise refactor the code in some significant fashion, the project ends up like a diver without functioning releases, tangled, panicked and running out of air (be that time or money).
The sudden need to change frameworks is a serious threat to your projects. Often it is a combination of major breaking changes in version updates, dependency bloat, security vulnerabilities, scaling issues or just a biweekly case of something new and exciting surfacing on hacker news that everyone suddenly wants needs to use.
Serverless Framework Testing
Don’t get me wrong – frameworks are a great thing! They abstract out the undifferentiated heavy lifting, allowing you to deliver business value faster. Alike a good tradesperson, we shouldn’t blame our tools when we use them incorrectly.
Months ago, I attended a meetup where a presenter made the claim that because there was no test harness for the serverless framework, on their serverless project (built for commercial purposes on behalf of a customer) they elected not to write any tests.
Reflecting on this comment over time, I got two insights:
- Some developers & project managers still don’t see testing as a key measure in delivering quality software [concerning, but I suppose unsurprising]
- Some developers are writing their code incorrectly if they need to be provided with a test harness
Serverless Memebot for Slack
The second insight gave me an idea for a meetup presentation. I could demonstrate something fun that leverages a great framework but is written such that a change of platform is a relatively trivial exercise. So I decided to build a slackbot. Something different from our usual AWS Automation software, the end user can create memes leveraging the serverless framework to build and deploy to our service to AWS. We have shared the slides and source code.
Take a look, have a play and let us know if you have experienced similar problems in your organisation and how you have learned from them.
The post Building a Serverless Slack bot using AWS Lambda, cautiously… appeared first on GorillaStack.