Klotho - Exploring compiled project
Tags: aws, klotho, awscommunitybuilders
Published: 2022-04-17 21:47:30

---
title: Klotho - Exploring compiled project
series: Review of Klotho (Alpha Early Access)
published: true
description: Review of Klotho, the tool to simplify management of application's infrastructure
tags: #AWS #klotho #awscommunitybuilders
cover_image: https://www.pawelpiwosz.net/assets/klotho/cover1.png
---

It is worth to mention here, that the project is complied using Pulumi. It is obvious, but I believe mentioning it is important, as Klotho claims on their webpage a few othe IaC tools, like Terraform or CDK. So, looks like it is time for me to learn a little about this tool.

However, Terraform and CDK are not available in Early Access.

Pulumi allows to "inject" infrastructure into code, it is similar to AWS CDK. Another words, we do not have separated IaC mechanisms, everything is in application code. Here I must mention (again), I am not very familiar with this approach, however I can point a few pros and cons (too) of this solution. I will not do it here, as the topic of this series is not about CDK or SDK :)

# Project structure

Project is compiled in directory defined in `--out-dir` parameter. In my case it is `compiledAWS`.

![Compiled directory structure](https://www.pawelpiwosz.net/assets/klotho/klotho06.png)

Let's try to quickly understand what is there. There are directories, where Klotho separated the microservices. I will look inside later. `klothofirstrun.json` and `klothofirstrun.png` represent the diagram (which I presented in previous episode). File names use the project's name, what is quite nice.

`Pulumi.yaml` contains main 'meta' information like name, description.

`Pulumi.klothofirstrun.yaml` contains configuration which will be used during deployment. Region, namespace and encryption salt. I have an improvement idea here. `us-east-1` is set as default region. Klotho didn't check what region is my real default (in aws config files, for example), or didn't ask which region I want to use. I can change it in the file, of course, but it is not the point. 

I am also worried a little, if Klotho works with profiles. We will see, I'll check it later.

`package.json` is standard NodeJS file and contains dependencies related to Pulumi and AWS.

`optimizer_metrics.json` is empty at this moment.

`index.ts` is the main file of the application's infrastructure configuration and `deploylib.ts` contains actual implementation of infra. Another idea here. I catched a few places with hardcoded data in `index.ts`. Like region (what might be critical), S3 bucket names (at least, this is how it looks by reading the code only). I am really worried at this moment about default region. I'll do some experimentations though, to confirm or reject my thoughts. But not in this series.

![part of index.ts](https://www.pawelpiwosz.net/assets/klotho/klotho07.png)

`deploylib.ts` although is using Pulumi SDK, is not like application code with IaC SDK. It is more like SDK code file with some application related elements.  I do not say it is bad, I just noticed that. This file contains the actual configuration of the infrastructure.

Ok, let's go into one of the directories. I selected `userapi`.

What I see immediately after `ls` command (well, I knew it already, I checked files in main directory earlier) is that Klotho created Dockerimage for me. So, the approach is to run Docker runtime on Lambda. I see it as a problem here. NodeJS is the fastest runtime for Lambda functions, if I am not mistaken, and Docker runtime... is not quite fast. Ok, it is slow. So, I consider this approach as not the best.  Anyway, I'll try to "push" Klotho to change the approach later, I am not expecting I'll be successful, but... We'll see :D

Dockerfile itself is very well built. First of all, it is multistage Dockerfile, based on Alpine and it is very well parametrized. I like it very much. It is an example of good Dockerfile :)

Dockerfile uses `CMD` and `ENTRYPOINT`. both files are well designed. `CMD` uses [aws-lambda-ric](https://www.npmjs.com/package/aws-lambda-ric) (which is AWS Lambda NodeJS Runtime Interface Client) and implements Lambda runtime API. `ENTRYPOINT` points to the `cloudcc_runtime` directory through `handler.js` function. I like the composition here.

![Structure of userapi directory](https://www.pawelpiwosz.net/assets/klotho/klotho08.png)

There is one thing, however, which I'd like to change. I see some mess here. I am currently in userapi directory, so I should have it as a 'boundary' for the code. But I see all code here. I am not sure if this is neccesary and I do not go that deep in my analysis.

`cloudcc_runtime` contains code with injected Pulumi.

Some of the code is multiplied between directories. I believe this is needed step (please remember, I am not developer, I have more assumptions than knowledge :) ), but makes the whole project more complex. But hey! It shouldn't be any problem! Remember, I talk now about compiled project! Not about the code where developers actually code! So from development perspective, it is not big deal.

I gave a thought about scheduled Lambda function. To remind you, one function in this application is scheduled to be executed every 5 minutes. So, I have `cc_kvbatchprocessor` directory for this function, but there is no event defined inside this directory. So, I was wondering, if it could be better to have it there, as it is related part. But I don't have any judgements here.

Ok! It is time to deploy the app!