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.

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.

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 (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.

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!