What I Learned at KubeCon NA with Monokle

A few days have gone by after Kubecon NA in Detroit and a lot of things have happened during it and after. I spent most of my time in the Monokle booth talking to users, and I learned a lot in the process.

‍

## Changes in a web page can derail your SEO

We changed the web page from monokle.kubeshop.io to monokle.io, and our SEO in Google has gone down like crazy. I’ve been told that it will go back to normal in three weeks, once Google discovers that all the content from the webpage and blog has moved to the new URL and reindex all of that.

I really wasn’t expecting such a hit when there is a redirect from the old pages to the new ones, but it does seem to be the case. Let’s see if we can get quickly back to normal.

## Kubernetes is hard and there are not so many experts out there

We had many meaningful conversations about requirements and how to improve the experience for Monokle users, and we were surprised by the fact that many of the attendees to Kubecon were hard experts, but they were looking for a way of making their teams work better with it.

There was a number that we heard a lot: I have 10x more developers that do not understand K8s than I have experts. So we are looking for ways of making those productive.

I believe many people are taking a shortcut: “we can make your team more productive by creating an abstraction layer on top of Kubernetes that will make their work easy”, but actually that only works when things are going well because you still have a team or non-experts when they need to dig deeper on the problems you're facing to fix your application when is down.

The other approach is to create a platform, so developers don’t need to think too much: they get guardrails and a service catalog, and they are free to use it. There are great solutions with this approach, but I still feel it is really hard to maintain a catalog that balances appropriately the need for new things and the need for those things to be secure.

Our approach (Monokle) is different: we are working with K8s artifacts and making them easier to use in three ways:

* Using templates and snippets, and adding documentation in place so we reduce the cognitive workload

* Validating in place in real-time, so you know if you are making a mistake with your schema, or you are not following a best practice of policy, and you can learn why and fix it on the spot

* Keeping the matter in focus. Yes, we provide forms, but you can have the original YAML file in place at the same time because we are not trying to hide what you actually are doing, but reducing the mistakes you make when doing it

## We don’t know more than you do, so we research more

We got so much feedback in a few days and we learned so much about what we were trying to do that it is clear that we need to keep our respect high and act accordingly.

Yes, we got confirmation about many of the things we were trying to do. There is a need for a lot of the features we have, and there is a need for more to make it really really good for your work, but also we learned that there are assumptions we were making that were wrong (like the fact that everybody knows K8s if they are working on the space, that proved to be wrong).

It is sooo good to talk to real users, face to face (and masks), and get the conversation going.

Don’t you think that your meetings were missing something more than what you expected?

I’ve interviewed a lot of people since I joined Kubeshop, and the feedback was great, but the conversation was always straight to the point. There was even a moment, after months of isolation due to the pandemic, when I felt I was losing the capability to do small talk. On video, all conversations seem to be straight to business. Sounds productive, but it is really not so.

There is a ton of good information in the context, and we take it for granted over video conference. Yes, I have this problem, but I am also working with a team that has different issues. No, I don’t need that, but I know five people that do. Oh, I see what you have done, and that reminds me of something I was discussing with a friend the other day.

We want that conversation, and as humans, we thrill on it. Going straight to the point is good when you are dealing with machines.

## Engineers need to know what is going on in the cluster, but not everybody needs full cluster management capabilities

In our conversations we found a couple of different personas, the seasoned Gitops / DevOps / platform engineer that would be so comfortable using the command line that any tool, and the developers that need basic information about the state of their deployment.

We know is hard to fulfill the requirements of the first group (and we are working on a CLI for validations that will do exactly that), but we discovered we already have a lot of the features required by the second one (like terminal and log access, cluster inventory management, comparisons, etc).

We will be doubling down on our efforts to get value out of the things we do with clusters and adding some additional functionality to better help with it.

## What’s next?

KubeCon North America may be over, but there’s still so much work to do. We need to follow up with many users that had amazing ideas on what we need to do next, and we have a lot of partnership opportunities that we need to materialise into something useful for all.

There is so many things I would love to be doing that prioritization is going to be hard.

Next stop: launching Monokle 2.0 and prepare for KubeCon Europe!

You can learn more about our work in Monokle by going to [https://monokle.io](https://monokle.io) and you can try the cloud version at [https://app.monokle.com.](https://app.monokle.com.) Monokle is an open source application, so you can find us at[ http://github.com/kubeshop/monokle/](http://github.com/kubeshop/monokle/) and on our [Discord channel](https://discord.com/invite/6zupCZFQbe).

‍