Klotho - final thoughts
Tags: aws, klotho, awscommunitybuilders
Published: 2022-04-17 21:47:46

---
title: Klotho - final thoughts
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
---

After some work with Klotho I have my opinion about the tool. I have to say, **I like Klotho**. It presented very powerful capabilities.

# What I love

I was impressed to see that after adding less than 10 lines into the code, I was actually able to create full infrastructure with policies, connectivity, storages and microservices. This is really something and it was worth to see Klotho in action.

# What I like

* The tool itself :)
* Simple installation process
* Clear CLI tool
* Diagrams created during compilation
* The least-privilege permissions created by compilation

These are additional values. What I really like about the core of Klotho:

* How easy I can instrument code to receive well constructed architecture
* Possibility to focus on non-functional requirements (i.e. latency, fault tolerance, etc)
* In default approach Klotho is responsible for resource types selection, therefore it is truly cloud-agnostic from the implementation standpoint
* Very nicely done build process for Dockerfiles
* Issues can be interactively send to Klotho. I suppose in the future Klotho will put it behind purchase plans (that is what I would do), but the functionality is awesome.

# What I'd like to improve

I am very well aware that Klotho is not officially released tool yet. So, my comments here will be obsolete soon, I am sure of it.

* Documentation. At this day the documentation is rather symbolic.
* Some issues in the functionalitites (I mentioned the directory where compiled project is, etc)
* Serverless Lambda with Docker is an issue for me. I'd like to see that Klotho creates Lambda not only with Docker runtime, but NodeJS, Go, Python (you name it) too. 
* Hardcoded data in some places (compiled project name, AWS Regions, for example)
* Somehow I feel that directories structure and content is a little messy. I believe it is the side effect of 'work in progress' on the tool.
* Tagging. At this moment it is missing. Tags management should be treated seriously, as it is powerful way to manage and control resources.
* Klotho CLI should work with IAM Roles. Let's suppose I use AWS CodePipeline. The best approach will be to grant access through Roles, not through user with credentials.

# Things to be aware of

* Klotho is quite hungry. It needs memory, it needs disk space. Of course, in my case it was related to Docker and NodeJS, nevertheless it might be important to take care about it.

# What might by hard for users

* Complexity. By using Klotho, you become an architect and DevOps of the solution. It might be difficult to manage.
* It is additional framework to take care of and the developers must be familiar with IaC (no matter what it will be)

# Questions which I have, but didn't answered during this short test process

I didn't check everything yet. So, I have some questions, and I will answer them in the future for sure :)

* What about profiles in AWS configuration files?
* What about Observability?
* What about dynamic configuration of environments?
* What about networking?

# Summary

As I said, I really like Klotho. I am not a developer, and the full power of it can be explored be developers. However I see a big potential in this tool. 

Is it a game changer? Well, not really. I mean, for many teams, companies, projects it will be. But we have to remember one thing - Klotho is a tool, which uses some assumptions, maybe templates to achieve the goal. So, it is possible that some scenarios will be hard to cover with it. It is fine, it is the way like it has to be.

Klotho is good answer for those who are looking for the toolset which can be used by limited team. I mean, where not all functions are present. DevOps, Architect, etc. It is common nowadays (which makes me very unhappy, honestly). 

It is very good answer for these projects, where `code-first` approach can be extended to infrastructure too. Yes, I know, code-first is related mainly to Domain Driven Design and databases, but who said it cannot be extended?

And finally, it is an option for those, who want to follow `infrafree` approach, but we will probably don't like each other ;)

It doesn't need to be a game changer. It is good and interesting enough to use some time and explore its functionalitites.