As Serverless developers, we develop our services with infrastructure as code (IaC) and, recently, with infrastructure from code (IfC), but mostly, it means that we write code or configuration to generate our AWS resources. What if we have been doing it wrong all these years? What if there's a better and simpler way to build serverless services on AWS?
In this post, you will learn how to build serverless services by drawing infrastructure diagrams with AWS Application Composer. I will share my experience using it, its strengths and current limitations, and present my wishlist.
Table of Contents
IaC and DevOps are Hard
Writing resource configuration files or AWS CDK, SAM, or Terraform code is difficult.
You need to learn the tool, review its documentation, learn its best practices (read my CDK best practices post here), and write code or configuration, and plenty of it.
Historically, developers swayed away from writing configurations that build resources such as Helm charts (I shudder at the thought of K8S), which slowed down the adoption of such tools among developers. However, with technologies such as serverless that go hand in hand with newer tools such as AWS CDK and SAM and the recent trend of infrastructure from code, developers embrace the DevOps mentality and are more open to writing infrastructure code. But it's still hard.
Today, I want to present a new option I came across - building resources by drawing a resource diagram - no code required.
Yes, drawing infrastructure diagrams. We all do it at some point at work.
As an architect, I draw high-level designs that describe service behavior and how service domains connect one with another.
Service infrastructure diagrams are a great tool to present a new feature, introduce the service to a new teammate, or even get a clear understanding of how the service works.
However, infrastructure diagrams have their issues too.
Diagrams are (almost) Always Out of Sync
As time goes by, features are added, and bugs are fixed. Developers change the original designs, and some design elements are dropped due to priority and are never developed. Remember that original infrastructure diagram you meticulously created and were so proud of? It's no longer in sync with the real service infrastructure and quickly loses value.
To solve this issue, you always go back to the code or the infrastructure configuration files (AWS CDK, in my case). Code doesn't lie, but looking at code takes time and skill.
The optimal solution would be to sync the service infrastructure diagram with the service code. It's a real pain to remember to update the diagram constantly. Nobody does that.
Luckily, AWS devised a way to do just that automatically, simultaneously making building service infrastructure more intuitive and fun.
They achieved that by building AWS Application Composer, which lets you draw infrastructure diagrams and convert them into AWS SAM or CloudFormation templates.
AWS Application Composer
A few years ago, in 2021, AWS bought a startup named "Stackery" that attempted to solve this very problem. Fast forward to December 2022, AWS Application Composer was born.
Instead of working in the console and doing diagrams, I can now use Application Composer from the comfort of my Visual Studio IDE.
Let's go over the user experience and development flow.
The User Experience
You can either start a new empty project or load up an existing project. I decided to load up my AWS Lambda Handler cookbook template project and see how it works.
This is the service diagram (which, ironically, is out of sync with the infrastructure; it's missing CloudWatch alarms and dashboards):
Now, let's generate a diagram out of the existing project CloudFormation template and see what we get. On Mac, you click 'CMD + SHIFT + P' and choose the project's CloudFormation/SAM template:
Make sure you installed the AWS toolkit extension!
The initial output on the screen is a diagram containing many resources with connections between them. Each resource has its AWS familiar icon, resource name and its current configuration.
A super useful feature allows you to group resources under a group or a logical domain. I've split my resources between CDK constructs, but that split didn't make it to the CloudFormation. It took me two minutes to sort everything, and I got this beautiful diagram:
I have my CRUD API group (API GW, Lambda function, two DynamoDB tables), CloudWatch resources, and AppConfig group and all the connections between the resources.
Initial impression: I'm impressed; this is highly readable and solves the diagram out-of-sync issue. Remember that problem with the diagram being out of sync? Every change you make here will automatically be translated and written into your SAM or CloudFormation template. Even the groups! They added a cool new 'ApplicationComposer' attribute into CloudFormation.
Let's see how easy it is to add and configure new serverless resources.
Adding Serverless Resources
Let's say I want to add a new CloudFormation resource. The resource search is excellent and fast; you can add over 1000 resources. Let's select a Lambda function. We are greeted with an easy-to-use menu with all the essential fields with a dropdown list:
Usually, I'd write lots of CDK code for the same thing, but here, I can do it in the UI.
Adding Less Common Serverless Resources
Let's try to add another resource, an AppConfig deployment.
Here, the experience could be better. The resource configuration panel does not have predefined drop-down lists. I'm required to write CloudFormation config code. Many less common resources don't have the same drop-down lists as Lambda function has but rather a key value configuration box where you put all the configurations. This is a bit hard to fill and understand. However, you have a link to the official resource documentation, which is a nice touch, and an AI suggestions button for sample configuration examples.
Overall, you are golden if you use the more common serverless resources. In time, more and more resources will get the VIP treatment. And in all fairness, I can compare that to CDK not having L2 constructs abstractions for many new services.
You can draw lines from one resource to another to connect them. You can connect resources such as an API Gateway to a Lambda function, and it configures the specific function as the route's destination. Very easy. However, only some resources are supported. I tried to connect an SQS queue to an SNS topic and had a tooltip popup telling me it's not supported yet. When supported, the experience is effortless.
So, we've already discussed two limitations:
Resource configurations - lack of drop-down experience, which is not an ideal user experience, but you can make it work.
I can't connect some resources that should be connected by drawing lines between them.
However, there are other limitations that we should discuss.
I've used Application Composer on a larger scale services' CloudFormation template and was greeted with a resource limit warning. It will be solved, but it's a limitation for now.
The diagram I got was very large, and it would take a lot of time to sort and group it. Another limitation is the lack of CDK support. Yes, I know, generating suitable L2 CDK constructs is extremely hard, but a boy can dream...
Despite all the above, the service has a bright future and will become part of my daily tool once these limitations are ironed out.
Should You Use It
Is the experience better than writing IaC? Is it more intuitive or even fun? Yes, 100%; when all the resources are supported and have their custom drop-down selection, yes, it's super easy.
Will it replace CDK for me
No, not until it has full CDK support, but it has its use cases especially for infrastructure diagram building for the sake of documentation.
Who is it for
It fits people who want to draw low-level designs or get an accurate infrastructure diagram representation of their small to medium service, people who want to build proof of concepts fast, and, of course, it fits people who use native CloudFormation or SAM. Even if you won't use it to build resources, it makes sense to use it for drawing the infrastructure diagrams. I've recently added an Application composer resource image to the AWS Lambda Handler cookbook documentation because it was easy to generate and made explaining the service simpler.
I'm excited about the service and its future; it has plenty of potential and places to grow. Once it irons out the user experience, it will be hard not to use it, and the team is headed in the right direction.
Lastly, if anyone from App Composer is reading this, my wishlist and vision for the service are below.
Application Composer Wishlist
If we get even part of this wishlist, Application Composer would be outstanding:
Infrastructure from Chat: Why should we bother defining diagram resources and connecting icons when we have AI utilities (Amazon Q and CodeWhisperer) right in the AWS toolkit in the IDE? I want to tell my AI assistant what to design and have them draw and configure the infrastructure diagram.
Automatic resource grouping - group some types of same resource types - CW dashboards, AppConfig resources, etc.
High-level design diagram option - create an option to "merge" objects into a domain group to abstract them, not just place them in a group. While at it, let's visualize nested stacks in separate diagrams in the IDE.
Resolve the limitations: Add L2 CDK support and support more resources with detailed configuration options.
Github/Jenkins plugin to visualize changes - when I review a PR, I want to visually understand what infrastructure configuration or resources were added, removed, or changed. We already have some tools that partially do that, such as 'CDK notifier.'
Copy-pasting element - I couldn't get this working for some reason. Maybe it's a bug, but I'd like to add similar resources quicker.