Introduction

The first time I worked with serverless technologies was in August 2018. I was hired to create an application that would use GraphQL as its API and it was only me as a developer. There was a lot of work to do and I didn't want to manage a server - creating a virtual machine, installing the dependencies, configuring the network, and so on - so I've decided to use a managed GraphQL server and I've found AWS AppSync because the project owner has chosen AWS as his cloud provider. This technology surprised me in a very positive way because I could be able to deploy a GraphQL API with a few configurations and lines of code.

I'll use AWS AppSync to tell you my journey, but it could be narrated by any other AWS service which can be created using AWS CloudFormation (CFN).

So the project begins. Once I had had some front-end drafts, I started working on the API. My first AWS AppSync implementation was using its console, in which I've created the schema, the resolvers, and some configurations. It's pretty neat working on there since your API is small, but when it starts to grow, some problems appear.

The first trouble I've found was that I had to click a lot to change the schema or the resolvers. Depending on your Internet connection, this process becomes slower. Also, if I wanted to copy some VTL template, I'd have to open two tabs or go to the source resolver template, copy and go back to the target template.

The second big issue was that I didn't have version control. This is a huge problem. Once I wanted to get some old template or schema, there wasn't a way to retrieve them. The AWS AppSync console just keeps the most recent configuration (at that time, 2018).

The Team Grows

Ok, this is not a problem, right? It depends. At least when you and your partner have to work with the same AppSync API using the console. Imagine the mess when you both make updates that replace the other. The solution was creating another API, but we had to copy/update/replace the schema and the resolvers in both APIs...

At this point, you've already realized that we had a lot of problems developing cloud in that way. Let me show you how we overcome all these problems.

Let's Talk About CloudFormation

After some research, we've discovered the AWS service called CloudFormation that solved most of our problems, really. It's a service that allows you to create a template file to model and provision your cloud resources in the AWS environment. This is awesome because it helps you achieve some good design principles when developing cloud computing.

My goal with this article is to present to you all the advantages I had (and still have) since I've started using CloudFormation to build my applications. I'll use AWS Well-Architected and my personal experience to explain these advantages.

AWS Well-Architected

It's a framework that shows to you "architectural best practices for designing and operating reliable, secure, efficient, and cost-effective systems in the cloud". It relies on The Five Pillars of the Framework, named as Operational Excellence, Security, Reliability, Performance Efficiency, and Cost Optimization. Each one of them has its design principles.

Operacional Exellence Pillar

The Operational Excellence pillar includes the ability to support development and run workloads effectively, gain insight into their operations, and to continuously improve supporting processes and procedures to deliver business value. Reference.

Design principles achieved:

Perform Operations As Code

When creating cloud resources with CFN, you have a template that can be versioned together with your application repository. Only this design principle solves some problems I've mentioned above.

Annotate Documentation

Your team can create comments on templates that will help future developers understanding the reasons why that resource was created in that way.

Make Frequent, Small, Reversible Changes

With a template and a version-control system, your team can make some changes, deploy it, test, rollback, and do this process over and over again until finding the best configuration for the application.

Performance Efficiency Pillar

The Performance Efficiency pillar includes the ability to use computing resources efficiently to meet system requirements, and to maintain that efficiency as demand changes and technologies evolve. Reference.

Design principles achieved:

Democratize Advanced Technologies

Not only AWS, but all cloud providers release services every time and you must pay attention to increase your cloud tools to always provide the best solution to your application. But it's not easy to learn every new service every time. A method that I use to get an overview of some AWS service is checking its CFN documentation. Taking AWS DynamoDB as an example, when I check its CFN properties, I understand the whole service.

Go Global In Minutes

This is mind-blowing. Once you have the template, you can deploy your resources and they are global in seconds or minutes. We've used this principle to create multiples APIs for the team developers to test their code in an isolated environment.

Experiment More Often

You can test a lot of configuration combinations. Taking the AppSync example, once you have your template done, you can change the way that the authentication is done in the API with few lines of changes.

Conclusion

It was very natural for me to start coding cloud computing using CloudFormation. This methodology reduced my time creating backend resources drastically. I can state that, before CFNDD, my proportion of time spent developing frontend and backend was about 1:1. With this methodology, the proportion is about 4:1 😮

But the most important fact is that CFNDD brought fun when I project and code cloud resources. It's exciting to read and study more about those processes and ways to improve it.

I hope I was able to show you some advantages of this methodology and how it improves my development processes. If you don't work with CloudFormation, I do recommend you give it a try by studying some examples. AWS provides a lot of templates.

---

Thank you for reading!

I hope you enjoy this post as much I do writing it to share a little of my experience as a cloud developer. If you want to contact me or discuss more this topic, you can send a message to me via Twitter or leave a comment here. It'll be a pleasure to hear your ideas and share experiences with you.