Recap of KubeCon + CloudNativeCon North America 2018

I was fortunate to attend KubeCon + CloudNativeCon North America 2018. Here are some thoughts as it concludes.

This was my first KubeCon. I am a newcomer to the Kubernetes (k8s) ecosystem and still navigating the project and its community. I learned a lot and I want to thank everyone who made this convention possible, from the organizers to the speakers to the sponsors to the staff at Washington State Convention Center in Seattle.

My perspective on k8s is that of an outsider. It's a very exciting project and has a lot of productive and innovative activity and energy around it. Many people and companies are spending their precious time and money in improving the entire ecosystem. There are a lot of competing projects solving similar problems. It's hard to figure out how they all fit together and how long they will last. In short, it's a great opportunity to roll up your sleeves and get involved.

I have another perspective on k8s and that is my day job's. My team is working to migrate from ECS to k8s. I planned my entire convention around the needs of my team today as I understand them. There were talks aimed at people at all the different stages of adoption, which I greatly appreciated. I tried to understand what it would take for my team to move away from ECS while also keeping an eye on where others are who have already made the migration from their legacy systems.

k8s is changing fast. Every release brings new changes. There are a lot of teams contributing to this fast rate of change. The project is being pulled in various different directions to meet all these needs but it's doing a good job of balancing all those needs. But expect to have the proverbial rug pulled out from under your feet.

The easiest way to get started with k8s is to use a managed service. For example, Cloud PKS, EKS, AKS, GKE, etc. There is a lot to unpack in starting with k8s and you don't want to be swept away by the flood of information. Let others manage the control plane so you can focus on migrating your workloads. Don't worry, there's a lot of stuff to learn even in this scenario so your fear of missing out (FOMO) should remain in check.

You should stick with currently popular stacks. There are better chances of finding expertise, documentation, and community support with a popular stack. Do a lot of homework on each piece and try it out in a lab environment. If you have a team of more than one person, divvy up areas of "expertise". Don't let yourself or others be overwhelmed by the sheer enormity of things that need to be learned to effectively use and operate k8s.

Engage with project communities. Go to meetups, join forums, triage bugs, write documentation, send code changes; anything that helps the community and gives you an opportunity to be engaged. Try out projects in incubation and provide feedback. Real engagement requires a lot of effort but the payoff can be great.

Most tools being talked about were written in Go and maybe Rust or Python. This ignited my FOMO of not using Go in my everyday work. As I have written previously (My First Experience with Go), Go is great but I can't find regular opportunities to work with it. Nevertheless, it has the right momentum behind it that learning and using it is and will continue to be a valuable skill.

CI/CD will become increasingly important as DevOps, SRE, k8s, and other practices converge. There are new ways to run CI/CD infrastructure and to create more powerful workflows. Here again we are faced with many choices, from open source and free solution to paid and closed source ones. I would recommend to extract yourself away from depending on a single tool here. Explore as many tools as it makes sense to you. Deploy workloads to these tools that are optimized for them, even if you have to work with lots of tools. I know it's difficult to learn everything at once but if you can target a specific problem with a single tool then that's a good thing in itself; right tool for the job.

Observability was another hot thing at KubeCon. It's much more than monitoring and can be very difficult to tie down to a single definition. My take away was that it's a combination of monitoring metrics, collecting logs, and tracing requests through your applications. The end result should be to help you diagnose and remediate on-going issues and hopefully to predict recurrences of known issues.

Security is always important but the container and k8s ecosystem is not always secure. There are efforts underway to integrate secure practices into projects and workflows which is needed and admirable. Nevertheless, things might not be as locked down as we would expect from a mature project. Be prepared to look at security and patch some holes through current practices.

Another hot commodity was GitOps. It's the practice of putting all operations related code and configurations in git. Any changes to be made are done through changes in git. This gives us audit trails, timelines of changes, reviewing changes, etc. But it doesn't necessarily have to be in git. The idea is that all source is versioned in some source control.

My team could keep using ECS until the k8s ecosystem has matured. But I think that the right time to migrate workloads to k8s is now. It's better to be here "early" as all the building blocks are being put in place. k8s is very big in size now and it will only become bigger and more complicated as it evolves to meet usual and edge cases. It will become even more cumbersome to grok the longer you wait.

k8s is solving problems we all have. If we don't adopt it now, we will still have to solve these problems. Rather than writing bespoke solutions, why not use what others are building and even more people are using? Why not engage with the community and build with them?

We will not always like the solutions from the community. We may disagree with decisions, direction, and implementation. But there is a solution available and as long as its viable, why not use it? Later, when everyone has learned more about the problem and the solution, changes can be made accordingly. Don't hinder your progress by letting trivial and temporary disagreements get in the way. Use what's available today while building what you want to build.

I talked to a lot of people at the vendor showroom. Most of them had great swag and I collected as much as I could. I would hope that next time instead of giving out swag to attendees, we could all pledge to donate to local charities that would benefit more from the spending.

The attendee fee was pretty steep. If it were not for my employer paying for me, I could not afford to attend. There are others, less fortunate than me, who still couldn't afford to attend. I would hope that sponsors would donate even more to the program to get more diverse and underprivileged people to attend.

Holding these conferences in North America and Europe only is also a disservice to those who are unable to attend because of geopolitical issues. I would hope that smaller and more local conferences can spring up and that vendors and sponsors give them due respect by sending subject matter experts and project leaders there. If attendees can't show up at a conference, maybe the conference should show up at the attendees' doorstep.

In conclusion, I think k8s has a great future. Whatever we might find missing or wrong today will be fixed soon, either by the community or with your contributions. Get on board as soon as possible if you think you will have to get on board at some point. KubeCon was the perfect place to be this week. I learned a lot by talking to people or listening to their experiences. We need more engagement in the industry but not limited to conferences.