It took longer than I want to admit to have a simple Koltin application build this morning. The build.gradle.kts needed a bit of tweaking to get a simple 3 class application with a single test to properly build.
I just discovered this application for k8s and there is a lot to like. It allows me to look at a k8s cluster in a whole new way. It is so easy to see everything that is running and all the resources that have been created.
This is quite the upgrade from the command line to see things quickly. I am not abandoning the cli but I am certainly going to look here when I need to troubleshoot because I have a better view of everything that is on the cluster.
They want you to look at this software as the k8s IDE. I will have to explore a bit more to see how it can me another IDE for my use cases.
It took me a couple of days of testing to realize my mistake with a network policy that I had.
What I wanted was to allow communication to a pod on a certain port for other pods in the same namespace. If the communication was coming from outside the namespace I was opening another port to let those happen.
The challenge I faced and that took me a while to fix was not as much with the network policy but with the fact that the namespace specification did not include a proper label. The network policy can only match on a label at this time and I was trying to get it to match on the name of the namespace.
The solution was to add a label to the namespace and then match with it.
I also learned to use the “kubectl describe netpol/nameofit” a lot to properly understand what k8s was understanding from the yaml I was submitting. I made typoes that did not prevent the network policy to be accepted but an extra dash on a line make a whole world of difference.
I have been deploying containers and creating applications on Kubernetes for the better part of the last couple of years. I should have written a lot more about the journey because there is so much to learn (by doing quite a few mistakes).
I should have learned by now that any of these great new ways of doing things that will simplify the delivery of applications is a journey where you are going to re-learn how to do what you have always been doing. The same “problems” exist in creating an application no matter the framework or language.
The new tool is going to address pain points from the last best framework ever and it will be very attractive to use the new one. The fun is in solving all the other problems that still exist and have not necessarily been addressed as well as the pain points that attracted you to it.
I had to re-learn so much about networking with Kubernetes because your micro-services all need to communicate with each other.
I had to learn a lot about Kafka because it is our messaging queue. Please don’t tell them that is what it is. It is so much more.
I had to learn about service mesh and got to the points of many memes about this one.
We had to learn so much about so many different applications and infrastructure pieces that the promise of delivering faster is not as true as we would have liked. Don’t get me wrong, I love learning but I hate over-promising and finding myself in a bad position.
The journey is far from done and I have an awesome team that is helping me and I hope that I am helping them along the way as well.
I have heard of serverless from so many vendors by now that it feels more about marketing than anything else. I have a bad gut reaction when I feel that there is more marketing than substance about any technology.
I decided to look at Now from Zeit just out of curiosity and I think that I should look at it a bit more since it looks quite easy.
On the Zeit site, you can see the free offering that they have and it allows you to get your feet wet and be more curious about what you can do.
The Now CLI also looks like a very simple way to perform everything you need.
I also like the immutability approach that they have that allows you to move quickly from one deployed version to another.
It is definitely worth more time to see what I could do with this platform.
This presentation has a series of coding habits that can cause problems if applied blindly:
I have seen many of these bad habits and I have quite often used them because they are my habits as well. I am unsure how we can lose these habits easily because some are embedded in the team and getting the entire team to change is not easy.
I like that he explains the fact that some of these start small and grow to be a problem. You have to be very attentive and make sure you don’t start on the wrong path.