![Serverless Framework Logo](/assets/images/blog/2022/07/14/00-cover.jpg)

I've been building enterprise cloud infrastructure with Terraform for the last 6 years or so. Mostly AWS
(Amazon Web Services), some GCP (Google Cloud Platform) and sadly even some Microsoft Azure 😉 mostly always using
Terraform. I like Terraform for many reasons, some of which will be highlighted during this post. Most won't be however
but maybe I'll write some follow-up posts to sing its praises who knows? But today I want to talk about both
Serverless Framework and CloudFormation.

For the last 6 months I’ve been using Serverless Framework and CloudFormation daily. I’d never used either of these
technologies before because honestly I've never seen a need to because I'm so happy and used to Terraform.  But I do
love to learn and evaluate new tech explore new ways of doing things, so I jumped into the docs and looked around some
existing serverless projects to see what it was all about. Let me tell you right off the bat I did not like what I saw
with Serverless Framework or CloudFormation... and 6 months later I like them even less.

### Serverless Framework gripes:

* Everything is a plugin
* Unpredictable behaviour
* Encourages bad practices
* Ridiculous Duplication
* YAML

### CloudFormation gripes:

* Change sets
* Very limited functionality
* YAML

Let me go through each of these and give you a little detail as to why I think they are a problem.

## Serverless Framework

#### Plugins

So first coming from a Terraform background I have long held a belief that one of the big reasons and major benefits of IaC
(Infrastructure as Code) is that your cloud infrastructure is clearly expressed as code, making it re-usable,
easy to reason about and easy to track changes over time. **Serverless Framework seems to do away with all of that!**

Before I go on I should preface my opinions that follow:

> As I've said I'm new to Serverless Framework so I don't know how it's evolved over time but if I had to guess I'd say
that it started as a relatively simple project that just let developers quickly get their code up and running in
AWS Lambda, and over time it's grown and grown through rampant scope creep and wild plugin system which now allows
engineers to do far more than they should...and that's less than ideal. - Liam Reilly

With that out of the way let's talk about Serverless Framework and it's many "useful" plugins.

When I first sat down to look at Serverless Framework I thought it looks harmless enough, define a few functions and a
couple of additional resources like SQS queues, SNS topics, S3 buckets etc. add some permissions via iam roles and deploy.
Nice, so far so good. For a hobby project this is awesome and I can see the attraction. But for enterprise you very 
quickly realise the limitations and find that you need to override or tweak something in your deployment. 
Now if you're lucky they will have thought of it and made available some kind of parameter you can override but most of
the time you're going to be looking for a plugin or completely ignoring Serverless Framework and just declaring the 
thing yourself in CloudFormation (I've done this extensively now).

Let's say you find yourself in this situation. You want to override or extend Serverless Framework somehow to tweak some
part of your deployment. Let's say you search the [Serverless Framework Plugins directory](https://www.serverless.com/plugins/)
and find one that fits your exact needs. You add it to your project and add whatever configuration it needs 
(the plugin page will include some example code serving as documentation of completely varying levels of quality) to 
override the thing you wanted to change and redeploy. Now you look over your deployed infrastructure and awesome 
it's all as you wanted it to be. Sure seems great, but I'd argue it's not!

* What exactly has this plugin done?
* What mysterious configuration has it generated and applied to your cloud infrastructure?
* What happens if the plugin maintainers change something you don't like in a future version?
* What happens if the plugin is simply discontinued altogether?

These are all good questions but it's the first one that I worry about the most. Yes I can see I've enabled a plugin and
yes I can see I've added some minimal configuration. First the most part I can easily deduce what my intended
outcome is, BUT I have to cross my fingers and hope that this is what actually happens or gets applied. Ultimately I have
no real way of knowing what is going on in my infrastructure because I didn't define it,  I cannot see it and I cannot 
control it!

**I do not like this.**

I also find the plugins to be very limited. Take for example the [serverless-deployment-bucket](https://www.serverless.com/plugins/serverless-deployment-bucket)
plugin. This plugin simply gives you some control on the S3 bucket that Serverless Framework uses to store deployment
artifacts. The plugin gives you more control over the name of the bucket and allows you to set encryption and things 
like that. However, it still doesn't do the one thing that I instantly hated about Serverless Framework; allow me to 
re-use a single S3 bucket and organise multiple projects/stacks into sub folders. Instead, I have to "waste" one S3 
bucket for every stack I deploy. From the get-go, on an enterprise project this sucks! Will this ever be addressed? 
Will the plugin ever be extended to improve this situation? We are held captive and not in control of our own destiny.

**I do not like this.**

This is not an issue if you use Terraform. With Terraform you have full control over where your IaC build artifacts and
state files live. You can use 1x S3 bucket say it's called `infrastructure`. You can then use sub folders inside here to
split your common infrastructure and app infrastructure up by the region you are deploying into imagine:

>infrastructure/eu-west-1/app1

>infrastructure/eu-west-1/app2

>infrastructure/eu-west-2/app3

In Terraform you have a single S3 bucket vs three already in this example. I don't want to pick on this plugin in particular 
too much because it's the same issue with or without the plugin. I just thought it was worth a mention because it's 
something that frustrated me from day one that I'd never given a second thought before.

#### Unpredictable behaviour

Again this might be related to the way I'm seeing Serverless Framework being used now, maybe because of the way it's
grown over time. I guess that this being the *Serverless* framework there was an expectation
that the infrastructure being built would be ephemeral/transient/temporary and tearing it down before it was re-deployed
would be standard practice. Instead, what we have now is permanent infrastructure being deployed in stacks where it's
never going to be desirable to tear them down again.

You'd think this would be fine it's just CloudFormation at the end of the day. It will simply look at my existing cloud
infrastructure and compare that to my latest `serverless.yml` configuration file and bring the two inline with each other.
Most of the time this is true but not always. Especially when you're working with Serverless Framework.

There are certain resources that Serverless Framework will create as specified **ONLY** on the initial deployment. An
example of this would be CloudWatch Log Groups. If you define `tags` for your Log Group on initial deployment they will be
added, but if you change these `tags` and redeploy they will not be added/amended. You won't be notified of this. They
just won't be updated.

**I do not like this.**

This is just one example, I've experienced other strange behaviour like this, API Gateway springs to mind. I've had a
number of headaches with this refusing to deploy new methods to a stage until I gave up, tore it down and redeployed
from scratch. Once again no indication that it hasn't deployed properly. You just realise it's broken and bits of it are
missing.

Who knows how many other weird things like this exist across all the other AWS services when using Serverless Framework?

#### Encourages bad practices

You may remember earlier on I mentioned how easy it was to get going on a new project using Serverless Framework.
One key reason it's so easy is because you simply define a list of permissions at the provider level
(think global stack level) and Serverless Framework will then make sure that everything you asked for is added to the
execution role for each Lambda Function in your stack. How helpful...

I've also noticed that it will also add in other permissions that you did not specify! A common example would be
CloudWatch Log Groups/Streams. These seem to appear in each Lambda execution role granting permissions to every Log
Group and Stream for every Lambda. Yuck. Call me old fashioned but I like to know that the permissions I clearly express
in my configuration are the permissions that are deployed to my cloud infrastructure.

**I do not like this.**

I fail to understand how this choice was ever seriously considered never mind actually implemented! What happened to the
principle of least privilege? You really don't want one size fits all when it comes to your Lambda functions execution
roles, but this is what using Serverless Framework encourages. As always there is a
[plugin](https://www.serverless.com/plugins/serverless-iam-roles-per-function) to work around this issue and define `iam`
roles at the function level, but you have to know it exists and then install/configure it when really it should be like
this out of the box.

#### Ridiculous Duplication

This one really irks me. There is soooo much duplication when working with Serverless Framework and CloudFormation in
general. Coming from a Terraform background it's almost hard to believe this is accepted.

In Terraform I'm used to defining `modules` (in this simple example just a folder with Terraform in) so that I can simply
re-use existing configuration many times over.

Say you need a couple of S3 buckets. In Terraform you would create a folder, let's call it `/modules/s3-bucket`.
In this folder you'd write a `main.tf` file and add some S3 resource configuration (as simple or comprehensive as you
like, remember you're only ever going to write this once). You might also choose to add a `variables.tf` file which
allows the user of the module to override certain values and opt in or out of certain features entirely.

To use the module you would do something like the code below which would create 2x S3 buckets one with encryption
enabled and one without. (Remember all the real comprehensive configuration to enable encryption on the bucket is defined
once inside the modules `main.tf`).

```javascript
module "secure-bucket" {
  source = "./modules/s3-bucket" 

  name                = "bucket-one"
  enable_encryption   = true
}

module "not-so-secure-bucket" {
  source = "./modules/s3-bucket" 

  name                = "bucket-two"
  enable_encryption   = false
}
```

Obviously this is a simplified example to prove a point but yes this is the extent of the duplication in Terraform.
I'm re-using a module that I already defined where all the decisions that were made were codified and signed off and
now adding another bucket is quick and easy and SAFE.

This is not possible in Serverless Framework or CloudFormation. Instead, for every new bucket I add I need to copy
and paste the same configuration and tweak as necessary. This wastes time, it produces unfathomable amounts of duplicated
code that is hard to reason about and difficult to maintain and if we want to change something we might have to make the
same change *everywhere* manually. What is this the 90's? What are we doing here? 

**I do not like this.**

#### YAML

This follows on nicely from what I was just saying about the duplication that Serverless Framework and CloudFormation in
general forces you to write. Instead of having nice modularised infrastructure code that's easy to organise and
understand you instead have thousands of lines of configuration in one sprawling `serverless.yml` file. Most of the
lines we've already discovered are duplication, so you already know something isn't right. Oh and the tooling for the
most part sucks. I cannot count the number of times I've tried to deploy only for Serverless Framework to tell me I've
cocked up the indentation of my configuration somewhere.

**I do not like this.**

In Terraform you do not have these problems. As I mentioned above Terraform allows you to build re-usable modules.
These can just be sub folders containing Terraform code but you can take this further. You can build these modules in a
completely separate repo if you like, or 1x repo per module (which is how I prefer to do it). You can then version these
modules independently following your standard `git` process simply make sure to `tag` the repo when you release a new
version. Then when using the module you can simply specify the `git::` repo address and `tag` number. So the example
from the previous section might look more like this:

```javascript
module "secure-bucket" {
  source = "git::git@gitlab.com:liam-reilly/tf-mod-aws-s3.git?ref=v0.0.2"

  name                = "bucket-one"
  enable_encryption   = true
}

module "not-so-secure-bucket" {
  source = "git::git@gitlab.com:liam-reilly/tf-mod-aws-s3.git?ref=v0.0.1"


  name                = "bucket-two"
  enable_encryption   = false
}
```

The secure bucket is using `v0.0.2` of the module which for the sake of this example let's imagine has added some extra
configuration to the encryption settings on the bucket to take advantage of some new feature or improvement from AWS. The
other bucket is still using the original version `v0.0.1` because it doesn't need this feature because it doesn't use
encryption.

Imagine this over many project across your entire organisation. Would you rather bump up a module ref for 50x buckets or
are you happy doing it the Serverless Framework/CloudFormation way and copy/pasting the entire new configuration
everywhere for each of the 50x buckets?

Oh and if you happen to use JetBrains IDE's like I do there is an absolutely amazing plugin for Terraform that makes 
writing it an absolute dream come true.

## CloudFormation

#### Change sets

This one was a real **WTF!?** moment for me. Again coming from a Terraform background I've become accustomed to the Terraform
`plan` and `apply` commands. In every pipeline I've ever built there has been a manual **review** step which runs a
Terraform `plan` and then lets me read over the output to see which resources are going to be **added**, **removed** or
**modified**. Knowing what is going to be **added** or **removed** is great but the level of detail for the resources which
are going to be **modified** is next level and has helped avoid so deployments over the years that would have resulted in
less than desirable changes! 

Another good thing about `terraform plan` is that it actually produces an artifact which can be uploaded for later use 
in the pipeline. Let's say you're happy with your review of the proposed changes, you click to trigger the next stage in
the pipeline, for argument’s sake this is `deploy` and it will run `terraform apply` using the artifact (plan) had been 
produced in the previous step.

This gives you complete confidence when deploying infrastructure. I do not have anywhere near this level of confidence
when deploying infrastructure using Serverless Framework/CloudFormation.

By default, in Serverless Framework V2 Change sets are not used at all. They can be used but you must opt in to this
manually. In V3 they seem to have addressed this and Change sets are generated but they are also might as well not be.
For a kick-off they are just automatically applied anyway, no manual review step here! But even if you were to review
the Change set, it's next to useless. It will tell you what's going to be `added`, `removed` and even `modified` but it
doesn't really give any detail on what the modifications are.

**I do not like this.**

Note: Serverless Framework will produce an artifact of sorts as well. It produces a CloudFormation JSON template 
showing the stacks desired state. It's not easy to follow or really designed for humans to read so whilst it's nice that 
it generates something you can look at, it's not as good as the output from Terraform which makes clear exactly what changes
are going to occur. It's also buried away rather than being front and center. I've never really looked at one of 
these files in any detail.

#### Very limited functionality

I do find CloudFormation to be very limited compared to Terraform. Terraform thanks to its proprietary HCL
(Hashicorp Configuration Language) is a purpose built programming language for cloud infrastructure. It has a lot of the 
things you'd expect to find in a programming language from `variables`, `functions` and `expressions` and some extra's 
all of its own like `outputs` and `data sources` (life as a cloud platform engineer without Terraforms data sources 
almost isn't worth living). It's very powerful and very easy to express comprehensive cloud infrastructure 
targeting any cloud provider you choose.

By comparison CloudFormation only works for AWS (obviously) and is massively restricted because of it's grounding in
`YAML`. It has barely any functionality compared to Terraform, making life much harder. 

**I do not like this.**

CloudFormation has just a handful of functions to help you out, I'm not sure how many Terraform has by comparison 
must be 100? Plus tons of other features.

#### YAML

I know I've already covered this once in the Serverless Framework section but I just wanted to say again. How did we
decide as an industry that we'd like to write giant reams of `YAML` for something as big as cloud infrastructure?
As soon as I started to look at CloudFormation it just brought back all those deeply suppressed memories of writing
Microsoft Azure ARM Templates many years ago. **Never again**

![Balance](/assets/images/blog/2022/07/14/01-balance.jpeg)

**Terraform was meant to bring balance to the force. Terraform IS the chosen one.**

Seriously everytime someone starts a new project and chooses Serverless Framework or CloudFormation instead of Terraform
a Jedi dies. Next time we are tasked with starting a new infrastructure project and the powers that be
are asking for Serverless Framework or CloudFormation, let's agree as an industry to remind them of Emperor Palpatine
executing Order 66 because this is essentially the same level of evil.

To finish let me just say I really have nothing against Serverless Framework or CloudFormation. I think like 
everything they have their use cases and can be good when used correctly. I wouldn't choose to use either myself even 
for my "hobby" projects but that's because I'm a professional and have extensive experience building enterprise cloud 
infrastructure with Terraform...Plus I've already built all my Terraform modules!  

The point of the post was just to allow me to get the things I've learned and observed over the last 6 months on 
paper as it were so that it's not forgotten. Hopefully someone else will find it useful. If you do find it useful let me
know! 

SERVERLESS FRAMEWORK - RANT

Did you enjoy this post?️

You Might Also Like

Testing T3 Stack Apps

I ❤️ PIZZA