Team Stackery has been hosting the PDX Serverless Architecture meetup at our Portland office since June of 2018, although the meetup began the year before. It’s always great to see repeat visitors and new faces, and especially to see our community change over the months.
In February, we had an entertaining, dynamic, and knowledgeable speaker in Yves Gurcan. The Stackery crew met Yves at our January meetup and were thrilled to see his name on our sign-up form beside a suggested topic of “AWS CloudFormation 101”.
Sitting next to/working with the serverless engineers building Stackery, it’s easy for a non-developer such as myself to assume that every engineer uses CloudFormation or at least has a very solid foundation of it. This assumption of widespread AWS understanding is something we work very hard to avoid at Stackery because our tool is built to aid AWS tooling comprehension — an echo-chamber will aid precisely nobody.
Yves requesting to speak on this topic was a great reminder that AWS is simply too vast for all engineers (no matter their level) to fully grasp without guidance. The number of attendees reflected this as well: we used every chair available in the office to seat the group that showed up. Clearly, CloudFormation = crowd formation (I’ll be here all week, folks).
Here’s a look into what Yves shared with that crowd.
Yves started out by polling the audience about their feelings about CloudFormation on a scale of 💩to 🌈(maybe with a ⛏️ in extreme cases). Very few people raised their hand for any of Yves’ categories which revealed something important: not many had interacted with CloudFormation at all! Perhaps there was a cursory understanding, but experience seemed to be strictly limited, which is perhaps why Yves drew such a crowd with this topic. Yves confirmed this suspicion with another poll: “Who here uses CloudFormation in their job or on their team?” Only a few hands shot up (— and yes, the Stackery engineers who graciously stayed late to help host the event raised their hands).
Given the results of Yves micro-poll, he delved into what CloudFormation actually is for the un(or barely)initiated. I love a choose-your-own adventure talk!
He explained that in a serverless sense, AWS CloudFormation is built for those who are tired of zipping Lambda functions by hand every time they want to deploy to production. It’s a solution that lets you deploy your entire application to AWS from your local machine. CloudFormation lets you deploy and connect cloud resources that are organized as stacks using continuous integration/development. All of this, while abiding by IAM roles & policies with automated rollback and error-checking at no additional cost!
Any presentation or piece of writing about AWS tooling can easily generate a misconception that the individual tool in question can do literally everything: it’s not helpful to read a list of features without learning the problems these tools were never meant to solve or are just plain bad at solving. All of this turns into a confusing disservice faster than you can say YAML. So, I was grateful when Yves outlined what CloudFormation doesn’t do.
Then, Yves shared a barebone CloudFormation code snippet. I appreciated that he pulled out such a small portion of code to show us what it looks like in production. As anyone who’s seen a development-focused PowerPoint knows, slides with dense code aren’t very helpful, especially when you’re a novice. He directed us to a GitHub repo filled with simple examples of CloudFormation templates. You can view them here.
After running us through the creation of his CloudFormation stack from the code snippet slide, Yves touched on a common part of the standard CloudFormation workflow: checking the AWS Console to ensure that our Lambda function did what it “said” it would do: in this case writing a new record to a DynamoDB table. It did.
As my colleague Nica Fee explained to me afterward, this part of the process is very much like sending an important email and, while anxiously waiting for a response, checking your sent folder to ensure you triggered everything properly — not necessary, but a good way to soothe any development nerves.
After we confirmed that everything was working properly via the console, Yves did something I didn’t expect: he launched into a full Stackery demo!
I knew Yves had signed up for Stackery ahead of his presentation with the intention of exploring our tooling to discover how we help users generate CloudFormation templates extremely fast. But a full (efficient) dive into Stackery was a pleasant surprise. It’s always really exciting to see customers benefiting from our product in real-time — and demoing it to other uninitiated onlookers!
Yves explained that Stackery provides AWS users with:
Then, Yves logged into the Stackery app and showed the audience Stackery’s GUI and how exactly he built the stack he’d been describing with our visual drag-and-drop editor — and the resulting auto-generated CloudFormation template.
Naturally, Yves ended by fielding questions and there were a bunch! I’ve noticed that the more introductory/multi-level the topic, the more questions arise. I believe it’s because the friendly and inclusive nature of these kinds of talks emboldens people to ask the questions they might otherwise think are “silly”. Many of the questions were actually about Stackery itself and this isn’t surprising at all: in the context of describing an AWS tool like CloudFormation, introducing a new workflow claiming to make the use of that tool more intuitive should result in questions and perhaps even suspicion.
**The two questions/topics that generated the most conversation were: **
A) “What’s the relationship, if any, between Stackery and AWS SAM/Serverless Framework?”
Answer: You can import existing projects or create new stacks in Stackery based on several types of serverless framework templates. This means that if you already have a repository with a valid template file (an application Blueprint), you can either import that repository directly, or create a new repository based on it.
In Stackery, new stacks are created using the AWS SAM template format by default, though both AWS SAM and Serverless Framework formats are supported. More here.
B) “Let’s talk about other cloud configuration languages beyond CloudFormation”
The person who asked this question was referring to TerraForm. They had used it previously and really saw the merits of cloud agnosticism (which TerraForm supports) as well as the open-source nature of the tool.
Yves is not a TerraForm user, but it was an interesting discussion. While cloud-agnosticism is certainly a notable advantage, CloudFormation has the strength of supporting extensive AWS coverage: nearly every service and resource you can create in AWS can be modeled in CloudFormation. Additionally, CloudFormation templates are authored in JSON, which is extremely helpful for version-control.
With Terraform, there might be a support gap in terms of the provisioning of certain AWS services — if you are fully bought into AWS, CloudFormation is probably the way to go.
Thanks to Yves for spending his time and energy speaking to the PDX Serverless Architecture Meetup group! The group loves talks like this one: engaging, accessible, and interactive; check, check, and check!
If you want to get in touch with Yves, you can reach him on these platforms:
Otherwise, we hope to see you at a future event as an audience member. Don’t forget the most important part: we always have food and drinks (and great company).