Serverless Stacks in AWS: Cloud Components that Simplify Your Architecture

Amazon Web Services (AWS) is daunting, especially once you look beyond creating servers in EC2 and adding some static content into S3. There are now hundreds of services that span across multiple areas of computing and industry, with new services appearing regularly. AWS is so large that it is incredibly difficult for any one engineer to know every service or feature, which means that AWS is now too big to master.

There are so many AWS products that Amazon can't fit them onto a single page. Even broken up into categories, many of the 200+ services aren't easy to find. (from

Another way of saying this: you can’t know everything about AWS, so you won’t always know the right architectural solution to every technical problem. It’s not easy to know whether your solution is a near-perfect implementation of the right AWS products, or if it’s an over-engineered solution that will hurt you in performance or pocketbook.

AWS is now too big to master.

This is where serverless stacks come in.

First, the serverless part: while many organizations are moving to the cloud by lifting and shifting their servers into AWS, GCP, Azure, or other cloud platforms, there is a maturing methodology that looks at leveraging the strengths of the cloud over the familiarity of individual servers. Instead of lift and shift and nothing else, serverless allows you to re-architect your processes to gain from the serverless concepts.

Serverless is the idea of removing the generic operational tasks that all organizations require, such as server patching, capacity planning, networking, and storage; serverless allows organizations to focus on their applications and workflows instead.

For example, when creating an application using the traditional server methodology, you would have your client side (website, possibly mobile app or other client interface), your backend application, and your database. You would need to decide how many servers this application would require (the answer isn’t universal), servers that you would need to configure and maintain, and that’s before considering load balancing, caching, or other services required for scaling and high availability. Serverless means focusing on combining your code with services in your cloud provider, and letting your provider worry about what servers are needed to make it happen.

What many traditional small web applications look like, a pile of servers. Usually overkill (over-resourced), sometimes not enough to keep things running when usage grows. (icon by

So while there are servers in serverless, they are abstracted away and managed by your cloud provider, which means they aren’t driving your solution design anymore. This affects your backend code quite a bit, obviously, moving away from monolithic server applications toward smaller functions that orchestrate whatever services you need.

This is a very powerful way of reducing the amount of infrastructure maintenance and backend code, but knowing the right way to organize and connect cloud services is challenging, and the wrong architecture can cause issues with performance and cost, and also may prevent you from realizing the automatic, demand-based scaling that serverless handles so well.

That’s why serverless stacks are about to become a big part of serverless.

A serverless stack, in the wild. The FormKiQ Document Stack architectural diagram. (from

Serverless Stacks are ready-made architectures, cloud components that are built using Infrastructure as Code (IaC) to handle workflows that your organization requires. For example, in order to manage documents in AWS: rather than having to determine the best way to connect AWS Lambda, API Gateway, Cognito, S3, and CloudFront, and then creating queues and notifications, you can use our Document Stack to have all of these services initialized and connected, and then to receive support and updates whenever improvements are made within the AWS ecosystem.

A familiar idea in serverless is that whenever you find yourself writing a relatively large piece of backend code, you should take a step back and determine if the problem you’re trying to solve has already been solved by an existing service or component. This may prevent you from spending time on the wrong things, by creating code to maintain that could easily be replaced by code someone else will be maintaining (oftentimes by your cloud provider or a cloud component provider like FormKiQ).

Serverless stacks are based on that idea, not just for code but for the architecture itself. Let someone else build and maintain these serverless components, so you can focus on everything else your organization needs.