## Problem Statement

Recently, I encountered the Error `DEPTH_ZERO_SELF_SIGNED_CERT` with a NextJS
app. After millenias of debugging, of course, since no meaningful error message
arose. My app simply refused to process requests to the `/api/*` routes of the
app. 

Reading multiple GitHub Discussion, GitHub Issues and StackOverflow answers
like:

- https://github.com/vercel/next.js/discussions/10935
- https://stackoverflow.com/questions/70440486/locally-developing-nextjs-and-fetch-getting-self-signed-cert-error/71558621

brought me nowhere. 

There are several development scenarios in which self signing a certificate is
useful and common practice so I was a bit salty about the lacking support.

## Solution

I found the solution to this problem buried somewhere deep in the Node
documentation. There is an option to disable the rejection of unauthorized TLS
certiticates `NODE_TLS_REJECT_UNAUTHORIZED`. So, adding this to NextJS dev
script did the trick for me:

```js
...
"scripts": {
        "dev": "NODE_TLS_REJECT_UNAUTHORIZED=0 next dev",
		...
    },
...
```

Self Signed SSL Certificate in NextJS


Today, software is often shipped as Software as a Service (SaaS) instead of local applications or on-premise hosting. This raises a whole new set of requirements 
and challenges that come with providing the service 24/7. In order to solve these challenges, we typically use hyperscalers like AWS to build and host
cloud-native applications. The complexity of these cloud landscapes is increasing rapidly, and it is becoming more and more difficult to maintain and operate them.

Infrastructure as Code (IaC) is a great approach to manage cloud landscapes in a declarative, reliable and transparent way. If we think one more step ahead, we don't
only want to declare our Infrastructure, we also want to automatically deploy and configure it. Especially for Kubernetes clusters, GitOps is a very powerful approach
that combines the power of IaC with the power of Git and Kubernetes operators. In this post, we will take a look at how we can use GitOps to manage cloud landscapes 
at scale and go beyond simple examples.

## What the heck is GitOps?

Although this concept is getting more and more popular, it's not yet widely known unfortunately. GitOps is based on IaC, but takes it one step further. We don't just
have a declarative description of our infrastructure, we also rely on a version control system like Git. Fairly, besides from GitOps you probably also want to have 
your IaC configuration in Git, but the purpose there is mainly for versioning and collaboration. 

With GitOps, we also want to use Git as a source of truth for the IaC configuration. Furthermore, that single source of truth is then used to automatically deploy the
configuration to the landscape. This requires the managed infrastructure to be completely projectable via declarative code. Additionally, we need an operator that 
monitors the state of the Git repository and applies the changes to the infrastructure.

![GitOps Flow](/assets/blog/posts/gitops/gitops-flow.svg)

Especially with Kubernetes, GitOps can be easily adopted. There are multiple open source tools that can be used to manage Kubernetes clusters with GitOps - the most
common ones are [Argo CD](https://argo-cd.readthedocs.io/en/stable/) and [Flux CD](https://fluxcd.io/). Both tools are very similar in their approach and can be 
used to manage Kubernetes clusters. Since Argo CD provides a great integrated web UI that also visualizes the deployments and sync operations in a very nice way, I
will focus on Argo CD in this post.


## Git Repository Setup

So when we want to have all our configuration in Git, how and where is the best place to put it? Some people tend to write Kubernetes configuration directly beneath
the source code, but I have a clear answer for that: Throw **everything** into a single
and separate repository. Even if you have a monorepo for your source code, a clean separation between code and configuration just makes your life easier. There is
a more detailed explanation in the [Argo CD Best Practices](https://argo-cd.readthedocs.io/en/stable/user-guide/best_practices/#separating-config-vs-source-code-repositories)
if you're interested in the benefits.

## Cluster Setup

The first question to be answered is: How does our cluster setup looks like? The answer heavily depends on the scope of the application and the budget. For small to
medium sized landscapes, it is often sufficient to have a single Kubernetes cluster. You can just deploy Argo CD in the same cluster as the deployments it manages - 
likely in an own namespace. 

However, for larger landscapes that also must fulfil enterprise compliance requirements, it is often a good idea to have multiple clusters.
This allows the separation of different environments physically from each other to have a strict separation of concerns. Also access control is easier to handle
when having multiple clusters, although Kubernetes RBAC is also a very powerful tool to manage access control within one cluster. Additionally, having multiple clusters
also enables customers to have a service that is hosted in their region. Especially for enterprise applications that must comply with local data privacy 
requirements, this can become very important.

Nevertheless, whatever landscape setup it is - we can always use Argo CD instance to manage all clusters. In the best case, we have an own cluster that only runs 
Argo CD (and maybe other related components). With having this in place, it's easy to define the requirements for each cluster independently. Although an outage of Argo CD 
is not business-critical (since it only means you cannot update the configuration via Git), it is still a good idea to have an independant high availability setup.

![Cluster Setup](/assets/blog/posts/gitops/cluster-setup.svg)

We can connect Argo CD with other clusters and also filter the resources by the cluster. That means all the configuration is at one place, we don't have to switch
tools / instances for different clusters and just have to manage access to one instance. Overall, it reduces the complexity since no direct operation on the
clusters is required anymore and everything is controlled by a single system.

## Concepts of Argo CD

So how do we actually configure Argo CD to deploy something? Well, this post is not a hands-on step-by-step guide how to setup Argo CD. If you're looking for that, 
just go to the [documentation](https://argo-cd.readthedocs.io/en/stable/getting_started/) ;). However, I still want to give a brief overview over the concepts Argo CD uses.

![Argo CD Concepts](/assets/blog/posts/gitops/argocd-concepts.svg)

### Applications

An [application](https://argo-cd.readthedocs.io/en/stable/operator-manual/declarative-setup/#applications) in Argo CD is set of Kubernetes resources that are deployed together. 
This can be a single deployment, a whole Helm chart or even a whole Git repository.
Normally, we want to have each component of the service in a separate Argo CD application. This allows having a clear separation of concerns since synchronization and
access control happens on application level.

### Application Sets

Now we know what applications are and created ones for all components, great! But what is with multiple environments that have the same components? We don't
want to duplicate the configuration for dev, staging, prod, whatever right? This is where [application sets](https://argo-cd.readthedocs.io/en/stable/operator-manual/applicationset/) 
come into play. An application set is basically a template that dynamically creates applications. In the next chapter, we will take a look at how we can use application
sets to create applications for multiple environments, maybe even distributed over multiple clusters.

### Projects

[Projects](https://argo-cd.readthedocs.io/en/stable/operator-manual/declarative-setup/#projects) are a virtual grouping of applications that share the same configuration. 
They configure access, source repositories, clusters, synchronization windows and more for their applications. Each application must belong to a project - there's always
the `default` project that can be used when there's no custom one.

## Repository Structure

The way how we now stucture the configuration in the Git repository is really important and should be well thought out. It's hard to change the structure later on and
requires lots of effort, so it's better to find a good setup from the beginning. Unfortunately, I can't give you a one-size-fits-all solution here, but I can explain
some approaches that I have seen in the wild and that have their individual benefits.

### Multiple branches

One approach to handle multiple environments is to have a branch for each environment or cluster. The advantage is, that we can adjust the configuration of each
environment individially, but additionally have the ability to merge configuration between branches. This comes in handy when we make changes first to a 
development cluster, but then want to ship the exact same config to other environments.

In Argo CD applications, the branch from the GitOps repository can simply be specified via the `spec.source.targetRevision` property of the `Application` Kubernetes
resource.

This might sound really practical at first glance, but in practice the merging between branches can get a bit tedious. Besides possible merge commits, we might not
want to merge **all** of the changes, just some of them - and there it starts getting annoying. In practice, this is not always that smooth, that's the reason why
people tend to choose other approaches that are explained in the next sections.

### App of Apps

The "App of Apps" concept for Argo CD refers to a way of organizing and managing applications within a Argo CD instance. In this approach, a "parent" application is 
used to manage and coordinate the deployment of multiple "child" applications, allowing for a more centralized and organized way of managing the applications.
We can then manage multiple applications at one place - instead of managing each application seperately.

That means a file for each application for each environment is required. This approach can be combined with the previous ones, [multiple branches](#mul
and [Kustomize](#kustomize).

### Application Sets with Matrix Generators

The App of Apps concept is great, but we still have duplications when having multiple environments since there needs to be an application for each one. 
A solution to reduce boilerplate and duplicated code is to use [Application Sets](https://argo-cd.readthedocs.io/en/stable/user-guide/application-set/). 

An Application Set is an abstraction over applications that allows to dynamically generate applications based on some data. The set has an application template
that is parametrizable. Then we need some kind of data source that is used to generate the applications, it can be just hardcoded but also a path to JSON files
in a git repository.

This approach assumes that the only diffenrence between the environments is the configuration of the deployments. So when we have Helm charts, we have just 
different `value.yaml` files for each environment. However, this is also the downside of this concept, at least if we replicate environments this way: If we 
change the Kubernetes configuration, we change it for **all** environments instantly. Changes for _individual_ components can **only** be rolled out by updating the 
respective `value.yaml` file! If there are frequent changes to the Kubernetes configuration, you might not want to solve the environment replication this way. 

A repository using this approach could look like this:

```
applications/
    sets/
        application-set-components.yaml
    root-deployment.yaml
charts/
    component-a/
        ...
    component-b/
clusters/
    staging/
        values/
            environment.yaml
            component-a.yaml
            component-b.yaml
        config.json
    production/
        values/
            environment.yaml
            component-a.yaml
            component-b.yaml
        config.json
    ...
```

The `root-deployment.yaml` just deploys all Application Sets, it could look like the following example:

```yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: application-sets
  namespace: argocd
spec:
  project: default
  source:
    repoURL: git@github.com:code-specialist/gitops.git  # GitOps repository
    targetRevision: HEAD
    path: applications/sets
  destination:
    # adds app in same cluster that Argo runs in, but sets can still be in other clusters
    server: https://kubernetes.default.svc
    namespace: argocd
```

An Application Set would then look like this:

```yaml
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: components
spec:
  generators:
    - matrix:
        generators:
          - git:
              repoURL: git@github.com:code-specialist/gitops.git  # GitOps repository
              revision: HEAD
              files:
                - path: clusters/*/config.json  # will generate an application for each occurrence / match of this file
          - list:
              elements:
                - component: component-a
                - component: component-b
  template:
    metadata:
      name: "{{component}}"
      namespace: argocd  # this is just the namespace of the Argo CD application, NOT of the Helm chart
    spec:
      project: "{{cluster.name}}"  # you can also separate apps in different environments via projects
      source:
        path: "charts/{{component}}"  # Helm chart directory
        repoURL: git@github.com:code-specialist/gitops.git  # GitOps repository
        targetRevision: HEAD
        helm:
          valueFiles:
            - "../../clusters/{{cluster.name}}/values/environment.yaml"  # values that are used by whole environment
            - "../../clusters/{{cluster.name}}/values/{{component}}.yaml"  # component-specific values
      destination:
        server: "{{cluster.url}}"
        namespace: components  # namespace where the Helm chart is installed
```

With this setup, Argo CD will automatically spin up new applications when clusters are added to the `clusters` directory, and also updates the configuration
when value files are updated.

### Kustomize

[Kustomize](https://kustomize.io/) is a tool that allows writing a single "base" configuration for the deployments and then overwrite it with customizations
for each environment. It is also supported natively by Argo CD, you can find for more information on the corresponding 
[documentation page](https://argo-cd.readthedocs.io/en/stable/user-guide/kustomize/).

This approach is the most flexible and powerful of the described ones in this post. It allows configuring each environment individially without having to
duplicate the whole configuration. It requires a bit more boilerplate code than the other ones, but especially in large and complex landscapes this will be 
acceptable. However, you first have to dig a bit into Kustomize to be able to use it properly 😉

A project structure with this approach could look like this:

```
base/
  component-a/
    kustomize.yaml
    ...
  component-b/
    kustomize.yaml
    ...
overlays/
  staging/
    kustomize.yaml
    ...
  production/
    kustomize.yaml
    ...
kustomize.yaml
```

With using Kustomize, we also can also renounce using Helm. Although it is possible to combine both tools, Kustomize in combination with GitOps covers everything
Helm can do - and even more. The templating is replaced by the overlays and the Helm lifecycle (upates, rollbacks, ...) is covered by GitOps. When we want to rollback
a change, just revert the latest commit!

## Operating the Landscape

So after we've setup the Argo CD setup and have all clusters connected and runnning, I hope you're starting to see the benefits of GitOps. But after the initial 
setup, we probably want to go live and have production environments running. This is where the real fun begins.

So how can we deploy changes in an agile, reliable and smart way? Since we're using Git, we can just create new branches for the changes and open pull requests.
This is just awesome, because we can do code reviews and collaborate. But not just that, we can also run pipelines that perform stuff like linting and policy checks.
Furthermore - and now it gets really fancy - we could deploy the new configuration to a dedicated cluster for pull requests and run automated tests on it. Sure, that
means **a lot** of effort to set this up and maintain this, but for huge enterprise landscapes where lots of engineers from different teams make frequent changes to 
the infrastructure configuration, this is just gold. On the other side, if that's not the case - just deploy the changes on dev first to verify and test ;)

![Operating productive Environments](/assets/blog/posts/gitops/productive-operations.svg)

## Further Steps

Haven't heard of [CrossPlane](https://www.crossplane.io/) yet? You should definitely have a look! Especially in large infrastructures and enterprises you want to
automate as much as possible and have all of the infrastructure as code. This can get quite complex when you have lots of different services, providers and platforms
as part of the infrastructure. Usually, such configuration is done via [Terraform](https://www.terraform.io/), which is a great tool.

But what if you can go one step ahead and make it even better? With CrossPlane, you have a Kubernetes control plane that can manage configuration for you. It uses
the Kubernetes operator pattern to synchronize the infrastructure with your configuration which you provide via custom Kubernetes resources. And even better - you
can combine this with Argo CD and other Tools to also have this configuration as IaC in your GitOps repository!

CrossPlane is open-source and really easy to extend. So if you're interested, I can definitely recommend looking into it 😄

---

We've reached the end of this post, thanks for reading! If you have any questions, comments or further ideas and tips that can improve GitOps setups, feel free to
post them in the comments!


Kubernetes Cloud Landscapes at Scale with GitOps and Argo CD

import AvailabilityCalculator from '/src/components/SLACalculator/AvailabilityCalculator.tsx'

## What is an Service Level Agreement?

A **key performance indicator** (KPI) that many cloud service providers and
cloud product vendors use is **service availability**. It is usually recorded as
**uptime per year** and defines the **service performance** in a so-called
**service-level agreement** (SLA) or sometimes also external service agreement.

A service license agreement contains information on a certain level of service
that is delivered to a particular customer. Sometimes there are various levels
of service for different pricing models. SLAs are not static documents and may
change over time.

It's important to note that there are different types of SLAs, they are not
restricted to software or services. Also, not all software- or service-related
SLAs come with an **uptime warranty**.

| Availability | Downtime per year     | Downtime per month    | Downtime per week    |
| ------------ | --------------------- | --------------------- | -------------------- |
| 95%          | 18 days 6 hours       | 1 day 7 hours         | 8 hours 25 minutes   |
| 99%          | 3 days 16 hours       | 7 hours 12 minutes    | 1 hour 41 minutes    |
| 99.9%        | 8 hours 46 minutes    | 43 minutes 12 seconds | 10 minutes 6 seconds |
| 99.97%       | 2 hours 38 minutes    | 13 Minutes 8 seconds  | 3 Minutes 2 seconds  |
| 99.99%       | 52 minutes 34 seconds | 4 minutes 23 seconds  | 1 Minute 1 second    |
| 99.999%      | 5 minutes 15 seconds  | 26.3 seconds          | 6.1 seconds          |
| 99.9999%     | 31.5 seconds          | 2.63 seconds          | 0.61 seconds         |

Why availability is also called the "**number of nines**" should be clear after
checking the table above.

These service agreements are not mere lie-documents but define authoritative
**service standards**. An SLA is a binding contract and a missed KPI is a
contract breach. When a service provider is not able to keep up his performance
standards they usually compensate customers either in direct refunds or
**service credits**. How service credits are calculated is also part of Service
Level Agreement. Some vendors also describe a right to earn back service
credits, when their service performed above the defined goals.

AWS for example states that the service credit percentage for EC2 is 10% between
99.98 and 99%, 30% between 99% and 95% and 100% for less than 95%. So Amazon
Webservices will refund 100% of your costs if the service was unavailable for
more than 1 day and 7 hours in a specific month.

## Calculating the availability

There are certain things you should keep in mind when calculating the
availability of your service:

- The availability of your system is calculated by multiplying the availabilities of all your components 
- Redundancy decreases the fail-rate by one potency (Increases the number of nines by one potency)
- The availability may not exceed the availability of your most available service
- Redundancy increases the availability of specific components but may not exceed the availability of the wrapping service 


## Example with AWS EC2

Let's look at a simple example to shed light on these rather abstract claims.
Assume you have a service running on AWS EC2. AWS EC2 has an uptime warranty of
99.99%.

Assuming your service runs smoothly, does not encounter unexpected errors and
AWS keeps up their promise, the uptime of your service is thereby expected to be
99,99%.

If you now want to deliver an uptime that is greater than 99,99% availability,
the temptation is great to just spawn another EC2 instance with the same service
and load balance these. That would result in a fail-rate of 0.0000001%

<math>
A(Service)=99.99\%\\\
\\\
A(2 * Service) = 1 - (1 - A(Service))^2 = 0.99999999 = 99.999999\%
</math>

But the problem to this calculation is, that the bottleneck here would be
wrapping service, such as Elastic Load Balancing for example. Elastic load
balancing itself has an uptime warranty of 99,99% thus, your service may not
exceed that value using only EC2 and Elastic Load Balancing.

## Example with self-hosted components

Lets assume you have an application consisting of 4 microservices and a database
running on different servers of some random Infrastructure-as-a-Service (IaaS)
vendor. Your service itself has an availaiblity of 100% the servers offered by
your vendor have a uptime warranty of 99.95%. All your services have a simple
redundancy and are wrapped by a load balancer that comes with 99.99% availability.

Your availaiblity would now be calculated the following way:

<math>
A(Service)=99.95\%\\\
A(Load Balancer)=99.99\%\\\
\\\
A(2 * Service) = 1 - (1 - A(Service))^2 = 0.99900025 \approx 99.9\%\\\
A(All Services) = A(2 * Service)^5 = 0.999^5 = 0.9950099 \approx 99.5\%\\\
A(System) =  min(A(Load Balancer), A(All Services)) \approx 99.5\%
</math>

Your system could possibly provide an uptime warranty of 99.5% which would sum
up to a maximum downtime of 1 day and 20 hours per year.

## Availability Calculator

I wrote a small calculator that calculates the availability of your system based
on your input. It may not fit all use cases but its easy to get a rough
understanding of how specific components affect the overall availability of your
system.

<AvailabilityCalculator />

Availability in Service-Level Agreements (SLA)

Handling form submissions is (still) a time-consuming and disappointing task.
Sometimes all you want is to create a form that triggers an email with the
provided details. The sad truth is, there is no such solution available for free.

But there is a solution that comes with nearly zero cost and effort: Utilizing
[AWS Lambda](https://aws.amazon.com/lambda/) and
[AWS Simple Email Service (SES)](https://aws.amazon.com/ses/).

![Form data to email architecture proposal](/assets/blog/posts/form_aws_lambda/aws-gateway-lambda-ses-form-data-architecture.svg)

If you never worked with AWS, no worries,
this requires absolutely no in-depth knowledge. All you need to know, is how to
[navigate AWS](https://www.youtube.com/watch?v=A43m4TDFCUM). However, I recommend you read
about the
[Well-Architected Framework](https://aws.amazon.com/architecture/well-architected/)
and to create a
[budget alert](https://docs.aws.amazon.com/cost-management/latest/userguide/budgets-create.html)
when you're starting to use AWS to avoid costly mistakes.

## Components

Even though it might seem trivial, I want to lose a few words to the components
in use. Feel free to skip this section if you're already familiar with the AWS
API Gateway, AWS Lambda, and AWS SES Services.

### API Gateway

The API Gateway is a fully managed service that allows exposing business logic
via API endpoints. The API Gateway supports containerized, serverless workloads
as well as web applications. It is the entry point to your application logic.

We utilize its feature to invoke Lambdas via a public endpoint in our case.

### Lambda

Lambda is based on the serverless concept. Instead of ever-running EC2 instances
(the AWS solution for virtual machines), lambdas only consume resources when
they are invoked. The actual costs are calculated in Gigabyteseconds (GBS). This unit
is calculated by multiplying the required main memory times the execution time. For
example, if you have a memory consumption of 80MB and your Lambda takes 560ms to
compute, this equals ~0.044GBS

<math>
  GBS(80MB,560ms) = \frac{'{'}80{'}'}
  {'{'}1024{'}'}GB*0.56s = 0.04375 GBS
</math>

1GBS is currently billed at _$0.00001667_ which means your request effectively
costs _$0.0000007293125_ or in other words, you can make about 1.37
million requests until you have to pay a single dollar.

The savings in resources are hilariously high. While virtual machines usually
cost at least a few cents an hour at any given cloud provider; you can make
thousands of serverless requests until you have to pay the same.

### Simple Email Service (SES)

The AWS SES is a service to send and receive emails. It supports various nice
features such as DKIM. This will almost certainly ensure your mails won't get
tagged as spam as long as your content does not behave like phishing.

To use SES in this scenario, you will have to confirm the email or domain you're
going to use to send mails. The SES wizard is clear and concise about the
instructions; you should not run into any issues here.

## Why use AWS

When it comes to architecture, in 9 of 10 cases, the definitive answer to your
question is: _„it depends“_. So maybe let's take one step back and talk about
why this solution might fit your use case.

The two factors that led to my decision were **Availability** and **Costs**.
Neither is a solution with low availability nor high costs tolerable for
submitting mere forms.

### Availability

The availability of this solution is at least **99,9%**. Which equals about 8.7
hours of downtime per year. The AWS API Gateway and the AWS Lambda Service have
an availability of at least 99,95%, according to their service level agreements (SLA).

<math>Availability(API Gateway, Lambda)=0.9995 * 0.9995=~0.999 = 99.9\%</math>

This is enterprise level availability and most likely much higher than the
availability of your self-hosted backend. Also, if necessary, it would be pretty
easy to increase the availability by utilizing availability zones, for instance.

### Costs

The costs are staggeringly low. All of this easily fits in the free-tier
offering of AWS and thereby your costs for the first 12 months would be $0.

After that, your costs are that low; they won't even sum up to a total of $1 per
year. But let's calculate that.

Let's assume:

- your website is frequently visited, and 50 people submit a form each day
- the lambda takes 75MB of main memory and 80ms to complete (my average)

That would be _18250 submissions_ (50\*365) and _~107GBS_
(75/1024GB\*0,08s\*18250 submissions) per year.

- 18250 requests via the API Gateway are billed with $0.0219 ($1.20 per million)
- 107 GBS via Lambda are billed at $0.00178 ($0.00001667 per GBS)
- 18250 emails via SES are billed with $0 (the first 62 000 each month are free)

This sums up to a _total of $0.02 per year_. I don't think there is any other
managed solution that can match these costs. But feel free to prove me wrong
in the comments.

## Lambda Function

First, we create a new lambda. Navigate to **Lambda** on the AWS Cloud web
interface. Make sure your region is set correctly (at the top bar on the
right side). Click on _Create function_, add your desired function name and
select NodeJS as runtime, and click on _Create function_ again (at the bottom).

After the creation succeeded, you should now be in the integrated code editor
with some default code:

```javascript
exports.handler = async event => {
  // TODO implement
  const response = {
    statusCode: 200,
    body: JSON.stringify('Hello from Lambda!')
  }
  return response
}
```

As you can see here, a lambda function is exported by `exports.handler` and is
an asynchronous function with a single argument `event`.

Now let's paste in our code to process the form submission:

```javascript
const AWS = require('aws-sdk') // Import the aws sdk
const ses = new AWS.SES({ region: 'eu-central-1' }) // Create an SES client bound to eu-central-1

const RECEIVER = 'info@code-specialist.com' // The recipient
const SENDER = 'no-reply@code-specialist.com' // The sender (Must be configured with SES)

const response = {
  // The response we're going to send to the requester
  statusCode: 200,
  body: JSON.stringify('Success')
}

exports.handler = async function (event) {
  // The actual lambda
  console.log('Received event:', event) // To log the event, make sure not to violate applicable data protection directives!
  const message = await decodeAndTransformContent(event.body) // Decode and transform the form submission
  await sendEmail(message) // Send the email
  return response // Return the response
}

async function decodeAndTransformContent (eventBody) {
  const buffer = Buffer.from(eventBody, 'base64') // Create a buffer
  const content = buffer.toString('ascii') // Decode the base64 encoded form
  const tuples = content.split('&') // "a=b&c=d" => ["a=b", "c=d"]
  const kv_pairs = tuples.map(pairs => pairs.split('=')) // ["a=b", "c=d"] => [["a", "b"], ["c", "d"]]
  const formatted = kv_pairs.map(pairs => `<b>${pairs[0]}</b>: ${pairs[1]}`) // [["a", "b"], ["c", "d"]] => ["<b>a</b>: c", ...]
  return formatted.join('<br/>') // ["<b>a</b>: c", ...] => "<b>a</b>: b <br/>..."
}

async function sendEmail (message) {
  const params = {
    Destination: {
      ToAddresses: [RECEIVER] // A list of recipients
    },
    Message: {
      Body: {
        Html: {
          Data: message // The actual content
        }
      },
      Subject: {
        Data: 'Contact Form Submission' // Your subject
      }
    },
    Source: SENDER // The sender of the mail (Must be configured with SES)
  }
  return ses.sendEmail(params).promise() // Return the sendEmail promise
}
```

All of this code should be self-explanatory. If not, the comments should clarify
what's happening. The serverless function will take any given form event and create a HTML
message body for all the key-value pairs provided.

### Configure the Policy

When you created the lambda, a basic policy has been created automatically to
execute the lambda. We now have to extend this policy, so it also allows us to
send emails via SES.

Navigate to the **IAM** service and then to _Policies_. You should
find something named similar to
`AWSLambdaBasicExecutionRole-5749fdbf-a74e-49a6-a18e-e8dc2d5e7c98`. Click on it
and then press _Edit policy_. By default, this will open a visual editor.
Click on the _JSON_ tab instead.

You should now see the active policy statements in a JSON format:

```JSON
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "logs:CreateLogGroup",
            "Resource": "arn:aws:logs:eu-central-1:1234567891011:*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "logs:CreateLogStream",
                "logs:PutLogEvents"
            ],
            "Resource": [
                "arn:aws:logs:eu-central-1:1234567891011:log-group:/aws/lambda/formFunction:*"
            ]
        }
    ]
}
```

Add another statement:

```JSON
...
    {
        "Effect": "Allow",
        "Action": [
            "ses:SendEmail",
            "ses:SendRawEmail"
        ],
        "Resource": "*"
    }
...
```

Finally, click on _Review policy_ and afterward on _Save changes_.

### Create an API Gateway

Last but not least, we need to create an API Gateway to expose the Lambda we
defined via a `POST` action. To do so, navigate to the **API Gateway** service.

Click on **Create API** and select **HTTP API**. You can now click on **Add
integration** and select your Lambda. Next, choose your API's name and click on
_Next_. You should now see an UI to configure your routes Select the method
`POST` for the lambda and choose a resource path for it. The resource path will
be the relative address of your endpoint. Leave everything else as it is and
navigate via _Next_ until you can click on _Create_.

You should now see an **Invoke URL** like
`https://code-specialistxyz.execute-api.eu-central-1.amazonaws.com`, which is the
base URL of your API. To call your Lambda you can now execute a post to
`https://code-specialistxyz.execute-api.eu-central-1.amazonaws.com/contactForm`
assuming your resource path is `contactForm`.

## Testing the function

To test your endpoint, you could use this minimal HTML5 snippet:

```html
<!DOCTYPE html>
<html>
  <head>
    <meta charset="utf-8" />
    <title>Test Form</title>
  </head>
  <body>
    
    <form
      action="https://code-specialistxyz.execute-api.eu-central-1.amazonaws.com/contactForm"
      method="post"
    >
      <span>Name</span>
      <input name="name" /><br />
      <span>Email</span>
      <input name="email" /><br />
      <span>Message</span>
      <input name="message" /><br />
      <button type="submit">Submit</button>
    </form>
  </body>
</html>
```

And that's basically it. You're ready to go! 🚀

If anything didn't work as expected or you're in need of an explanation
somewhere, don't hesitate to leave us a comment 😊

Posts for the cloud Category

Self Signed SSL Certificate in NextJS

Kubernetes Cloud Landscapes at Scale with GitOps and Argo CD

Availability in Service-Level Agreements (SLA)

Form Endpoint to send Emails with AWS Lambda and AWS SES