Originally, I wanted to blog about my favorite re:Invent announcements. But as I started, I saw a higher level theme and decided to write on that instead.
Disclaimer that this post contains my individual opinions and yours might differ. I welcome your polite/engaged feedback and encourage you to continue this conversation.
- AWS Step Functions Workflow Studio is now available in AWS Application Composer
- AWS Application Composer IDE extension
My time spent as a software engineer at
$day_job is mostly writing Infrastructure as Code (IaC). When reflecting on the Serverless mindset, I believe that some aspects of this mindset conflict with how I spend most of my time at
✅ Pros of the status quo: writing IaC is repeatable, scalable, fun, and I’m good at it! 🙂
🚫 Con of the status quo: I find myself wanting to spend more time focusing on providing business value and less time thinking about tooling or specific settings for my cloud resources.
Then a thought occurred to me: What if we didn’t have to write IaC? Why not have a deployable diagram of the application instead?
Werner Vogels said in his keynote that “the most dangerous phrase in the English language is: ‘we’ve always done it this way’.” I think this applies to how we’ve historically approached IaC with Serverless development.
Anecdotally, I’ve noticed that some experienced builders are ignoring updates to tools like this because they already know how to write IaC and think they don’t need a visual interface. I politely disagree.
To me, being able to more quickly collaborate, share, and deploy cloud resources is a huge win for everyone, regardless of experience level or job title. The primary focus can then be providing business value rather than figuring out how to write IaC for a specific cloud resource.
We have so much more to offer than expertise in the tools that we use. Embrace the Serverless mindset and demand a brigher future. 😎