Viktor Farcic: When I'm at DevExperience, I feel like I'm at home, surrounded by friends

When you meet amazing people and awesome professionals like Viktor Farcic, you keep them close to you and you are just grateful that they consider you their friends. Viktor Farcic is coming for the 4th time at DevExperience and he is now more than a friend. He is family. Each year the tickets to his workshop are sold out first and more and more people are coming to the conference to meet him in person and to learn from his experience. Until the 4th Gathering, we've asked Viktor some important questions about the industry and you should really read his answers and share them in your community!

So enjoy our blog interview with Viktor Farcic and, of course, do not forget to register on www.devexperience.ro!

DevExperience: Each year we have a different concept, different speakers, different tracks and surprises. The only constant is our passion for what we do and... you. It is the fourth year in a row when you are speaking at DevExperience, and we feel like you are part of the family. How do you feel about coming each year to DevExperience and what can you tell us about the evolution from the first year until now?

Viktor Farcic: DevExperience is evolving. Year after year, the organization is better, talks are improving, and the attendees are more and more engaged. Such an evolution is not specific to DevExperience but can be observed in many other conferences. What is special about DevExperience is the sense of community maintained year over year. While the evolution of other conferences leads to increased number of sponsored talks and overall commercialization of the conference, I feel that DevExperience keeps maintaining the spirit and the principles it had from the first edition. The main reason I keep coming back is that sense of community. When I'm there, I feel like I'm at home, surrounded by friends.

DevExperience: It looks like the big companies like Facebook, Netflix, Amazon, etc are moving at an incredible pace while the rest of 95% are stagnating. What do the others need to do to reach continuous delivery and 100+ deployments per day?

Viktor Farcic: It is questionable whether an average company can ever reach the greatness of Netflix, Amazon, Google, and similar companies. No matter how much we improve, they are progressing even faster. The gap is becoming bigger, not smaller. But, that does not mean that we should give up. That will surely result in death. We will be destroyed by competition if we let down our guard.

The only way forward is to be better and faster. To do that, we need to forget what we know. We need to dismantle our corporate structures, we need to disavow our culture, and we need to get rid of our processes. We, effectively, need to start over. We need to stop doing what we're doing and start from scratch. The most effective way to do that is by creating a startup within our company. By creating an entity that is not hindered by existing (and outdated) processes, we can embrace those created by companies that proved to know better than us how to develop and deliver software.

The critical thing to note is that the change of technology is the easiest part. Changing ourselves is what prevents us from improving.

DevExperience: Why do you think Kubernetes is so successful? 4-5 years ago there were probably very few people that heard of it, while now the ecosystem is huge. What just happened in such a small period?

Viktor Farcic: The answer is simple. Everyone agreed that Kubernetes is the API standard for managing both infrastructure and applications. By everyone, I mean every software vendor. One probably cannot find a software company that does not work on their next generation to be Kubernetes-native. Whichever applications you use in your system (e.g., Jenkins X, Prometheus, Redis, etc.) you know that the focus is now on Kubernetes.

I do not remember that something like that ever happened before. This is the first time that everyone agreed on some sort of a standard. As a result, everyone has vested interest in seeing Kubernetes move forward and many companies are spending a significant amount of their engineering effort in contributions to the project.

As an example, our (CloudBees) current generation of software is entirely focused on Kubernetes, so we have an interest in making sure that it continues growing and that it is stable. That interest is reflected through contributions to the project and, as a result, it grows. The adoption of Kubernetes is a reflection of that effort.

DevExperience: If you were now the CTO of a well-established company, would you use a cloud offering for your Kubernetes platform like EKS, AKS, GKE or try building yourself with kubeadm or kops or kubicorn still on a cloud platform?

Viktor Farcic: There is no doubt in my mind that I would go with a public cloud. Why would I waste my time with something that is not my business? If my goal is to deliver applications to my users, then I should put all my attention to that goal, and let others manage things that I need, but are not part of my business.

Infrastructure is one of those non-core things. Every minute someone spends on infrastructure-related tasks is a minute not spent on producing value to my users. That value is for most of us development and delivery of new features. That logic does not apply only to infrastructure. The same can be said, for example, for databases. Do I have to run databases reliably? Yes! Should I spend my time making sure they're running or let someone else do it for me knowing that someone probably knows better than me how to run it? The answer is in "someone else", unless running databases is my core business.

The only case when I would not go with public cloud is if infrastructure or services are my business. If that's what I'm selling to my users, then I have to treat that as my core business and take full control.

DevExperience: For a company adopting now Kubernetes, what do you think their first steps should be? What should they look after when launching their first Kubernetes cluster live?

Viktor Farcic: Do not launch Kubernetes cluster yourself, unless you have to. Let Google, AWS, Azure, or any other cloud provider with managed Kubernetes offering do that for you. Concentrate on learning how to operate applications running inside your cluster, not on running the cluster itself.

DevExperience: Would you keep stateful applications (like a MySQL or Mongo database) inside a cluster? Maybe use an operator for it?

Viktor Farcic: I would run everything (including stateful applications) inside a Kubernetes cluster. But that would be my end game. Some types of applications benefit a lot from running inside Kubernetes, others benefit less, while some see only moderate benefits. Start with stateless applications. Among them, pick those that are designed in the 21st century (e.g., scalable, small, fault tolerant, etc.). Use them to extract as much benefit from using Kubernetes as possible. Then start moving back in time, all the way until you reach those applications designed many years ago (e.g., big non-scalable monoliths that cannot replica data and sit in some basement collecting dust).

DevExperience: While working with the companies that adopted DevOps for quite some time, what are they still struggling with? What are the next silos and handovers that need to be eliminated?

Viktor Farcic: Tiny percentage of companies adopted DevOps. Many are saying that they are "DevOps certified", but most failed to embrace DevOps truly. You can easily distinguish "fakers" with two simple questions. "Do you have DevOps engineers?" "Do you have DevOps department?". If the answer to either of the two questions is "yes", that company did not yet even understand what DevOps is. Instead, it's "faking" it just as many "faked" agile, big data, and many other trends. Most of the companies did not yet do the first "real" step. Most do not understand that DevOps is about building empathy by creating self-sufficient teams that are in full control of an application, from requirements to running and monitoring their applications in production. Most are still not aware that their silos are producing misery and fostering finger-pointing culture.

DevExperience: We know that you like Go now and we can see that huge projects are built with it like docker, terraform or Kubernetes. But why should a backend developer start learning it, why java or .net core is not enough?

DevExperience: Instead of answering that question directly, I'll respond with yet another question. Think of the application you've been working for years now. It is likely application designed a long time ago. Such design was likely based on ideas and practices that were valid back then, but are mostly obsolete today. You're doing your best to keep improving that application by constantly refactoring it and making it more in line with the current tendencies. And yet, you cannot shake the feeling that application will never be young again. No matter how much refactoring you do, it will always contain things based on principles from the past that are not valid anymore.

Now, imagine that you start from scratch. You and the people around you know how the old application works. You know what works well, and what doesn't. If you start from a clean slate, it is almost inevitable that your new app will be better than the new one, simply because you'll use your past experience and combine it with today's needs. The result will almost surely be something much better.

I believe that the same is true for Go. It was created by people with a profound understanding of how Java, C, and a few other languages work. On top of that, it was based on the acknowledgment that what we need today is much different than what we needed when those languages were created.

Simply put, Go is a language designed to help us tackle today's problems, while Java, C, .Net, and other older languages were designed to solve problems we had years ago. No matter how much you're trying to improve those languages, their core principles are today obsolete. Similar changes are happening all the time. Go will be replaced by some other language. It will become obsolete over time, just as everything else does. But, that day is not today. Go is the best language we have for building performant, scalable, and distributed systems.

DevExperience: Tell us a little more about your talk at this edition of DevExperience, but also about your workshop from this year. Who should register and what will they learn there?

Viktor Farcic: My talk is about things we do with Kubernetes after we master basics. It's about scaling, monitoring, alerting, logging, and similar subjects that are often overlooked or, more often, things that we do not do properly because we are too used to the old processes and too attached to the tools we used in the past. Nevertheless, I believe that those subjects bring to light the true power of Kubernetes.

The workshop, on the other hand, is about continuous delivery (CD). A lot changed in 2018 and 2019 and the chances are that the audience will not recognize most (if any) of the tools we're using today. If there is any advice I would give to those coming, it's that they need to forget everything they know about CD and keep an open mind. We'll move to serverless, GitOps, GitChat, terminal-based CLI-first type of tools, and much more.

Pretty attractive and amazing, right? Well, all you have to do is register for the conference and for the workshop and join us for the 4th Gathering of the IT Evangelists!