Viktor Farcic of Upbound

Thank you for tuning in to today’s episode of the Breaking Changes podcast. I’m your host and chief evangelist for Postman, Kin Lane. With Breaking Changes we explore topics from the world of APIs, but through the lens of business and engineering leadership. Joining me today we have Viktor Farcic, developer advocate at Upbound. Viktor is one of those people I just thrive talking to, and normally I do a brainstorming and planning session with each guest, but with Viktor we just dove in and hit record. Here you go. Let’s start simple, let’s start with the basics: who are you, what do you do?

So I’m Viktor Farcic, I’m a developer advocate, officially at least, at Upbound, and unofficially I do random things, and then some of those things turn out to be something, and most of them go to trash.

Yeah, and I’m interested in how Latroy, who’s my partner in crime for the show, came across you, because I tried hiring you a while back and was unsuccessful, not from anything on your end but on my end, and so I was happy to see your face come up in the queue of folks that I was going to talk to. So glad we could make this work. So what are you working on these days? Besides just random things, what’s top of mind for you, what are you focusing on?

So the closest explanation of the main focus would be how to build or pick tools, let’s say, not necessarily build yourself, that will help operators enable developers to be self-sufficient. And in this concept, when I say operator, I mean whomever is not working for the end user, and when I say developer, I mean not just Python-focused people, because those terms are complicated, everybody’s a developer, everybody writes some code, so it could be misleading. But let’s see, how to enable people to shift left operations.

So is this just DevOps? How does it differ from what we’ve been experiencing living as DevOps?

Oh man. I think that DevOps is a brilliant idea, not necessarily novel, but very, very helpful, a good idea that got completely abused. Most DevOps people are engineers, when I hear DevOps engineer I want to freak out a bit. In a more practical sense, most DevOps groups or people are just doing the same thing as before, but now they’re renamed to DevOps. In some company that’s a platform team, in some other company that’s operations, there are companies where DevOps people are people who were previously managing Jenkins pipelines, things like that. I think that there is a huge misunderstanding what DevOps is. In my head, DevOps is very simple, it’s about being able to have full control of an application, and that means not only that you write your code and you write your tests and you have a manager, and we’ve wrapped those three into what we call agile, again in practice not necessarily in theory, but that we also need to be able to deploy our applications, and maybe manage our clusters and do whatever else needs to be done, like observing what’s going on with our applications, without moving those tasks to separate isolated teams living in silos. It’s about removing silos, it’s about being self-sufficient. So just, I’m a developer, just give me an AWS account without any limitations, that’s all I need.

You probably, I’m guessing that you know what is a subnet and what is a VPC and what is internet gateway and so on and so forth. Majority of people do not know those things, and it doesn’t even make sense to know those things, because it takes hell of a time to figure those things out. And I think that this is a big misunderstanding, AWS is not giving you the end services. You cannot go to AWS and say I want an EKS cluster, you need to say I want an EKS cluster with a node group, with internet gateway, with subnets, with VPCs, with the 50 different things, and then you get something meaningful. AWS is a set of building blocks that people need to assemble in a certain way, and how they will assemble those building blocks depends on their organizational needs, and then you get something meaningful. I’m now throwing random numbers, but 95 percent of engineers do not really know AWS enough to just say, here’s the account. What you just said would be valid if you said here’s a Heroku account, yes, here’s an AWS account, no. Just like Kubernetes, there is no concept of application in Kubernetes, how am I as a developer going to say I have a backend application that should be exposed to internet and is stateful, okay, I cannot say that. I mean obviously we can run those types of applications, but there is no such concept in Kubernetes, just like in AWS there is no concept of a Kubernetes cluster by itself.

So Heroku was a good example, I would say, because what I hear you’re saying is building blocks plus guardrails plus some education, training, and resources so that I can learn. But Heroku didn’t allow me to grow and learn and expand, it was guardrails and then that was it.

Yes, because the story is that if you want to make something simple, that simple needs to be opinionated. All the highly opinionated tools are simple enough that anybody, literally anybody, without being specialized in those tools, can pick them up. The problem and the big question here is who creates opinions, because if those opinions are created by a vendor like Heroku, they need to serve everybody’s needs, and by serving everybody’s needs, they’re serving nobody’s needs. Now if you’re a small company and you say I’m starting today, you can say I’m starting today, I have nothing behind me, I have no legacy, I have no prior investment, I’m going to do things Heroku-ly, and then one day you might hit the ceiling and say this is not good enough for me anymore, but you can get a long way with Heroku if you’re starting today. But most companies are not starting today, I’m sure your company has already things existing in some form or another, my company is, everybody’s company. And that means that I have two options, either I adopt everything I have to a vendor’s opinionated way of doing things, which is an option, or I need to adapt a solution to me. Usually the latter is more likely to happen, less investment.

And that means that we are really looking into how can we make a Heroku-like experience that will be doing what we need it to do, not what somebody thinks it needs to do. So I think that we are really missing, and I feel that that’s one of the focuses of the industry right now, we are missing tools that will enable us to create our own Herokus. Your company’s Heroku, my company’s Heroku, somebody else’s company’s Heroku, everybody wants Heroku, I’m using it figuratively, a Heroku-like experience. The question is only how do we build it, or do we just buy something off the shelf, and I don’t think that off the shelf works for bigger organizations.

Yeah, I want Heroku for healthcare, I want it industry based, too, I want specific needs, I want Heroku for Kubernetes, because I’m not going to go into Kubernetes, I know too much to even start down that road and it scares the hell out of me, so give me Heroku for Kubernetes.

Oh yeah, that’s also one of the things that, either I’m terribly wrong or I feel people misunderstood, Kubernetes was never supposed to be used directly. I see Kubernetes like, let’s say, hypervisors. Most people use virtual machines today, and I bet that the vast majority of us do not understand how hypervisors work, you do not care. Hypervisors are extremely important technology that over time was made invisible. It powers half of the world, hypervisors are behind almost everything we do, but hardly any of us are seeing them, because that’s a building block type of technology that is extremely important but it matured enough that it became invisible. Similarly, if you go back to, I don’t know, like 30 years in time, you were probably compiling your own Linux, and you were making your own distribution because there were no distributions, but today you want an operating system, you get Ubuntu, you do not care about really Linux, you do not care about the kernel, you’re not assembling the kernel yourself, the kernel itself is not very useful for the majority of people. What is very useful is a distribution of that kernel, which could be CentOS, RHEL, Ubuntu, anything. If I change the word from Linux to Unix, kind of macOS as well. We need the same thing for Kubernetes, we need people, they get confused when I start the sentence, when they ask me, hey, what do you predict will be happening in the future, and I’m saying Kubernetes will disappear, it will be there, you will not see it.

We have to abstract it away. With these guardrails and these suites of tools that we equip our developers with, so that they’re able to be successful and not fail and not be so miserable having to learn the entire world of Kubernetes. So who’s in charge, if I’m business leadership, because this podcast is targeting business and technical leadership, who in my organization is in charge of investing in this type of tooling? But it’s not just tooling, it’s kind of world building, you have to identify the size and shape and scope of the world that you want to build, the tools that you equip, and then it seems like it has to match up with HR in some way and who you hire and put into those, because you don’t want to put people into Heroku worlds that are too big for that world, you want people who thrive and are successful in that world. So who’s in charge of building these Herokus for the enterprise?

I think that half of organizations should be there. Almost everybody on the right side of, you know, traditionally the right side of the lifecycle of applications, that means operations without any doubt, security, let’s say. It’s the same story, I could make exactly the same argument for security as what I was making before for Kubernetes operations and stuff like that. You want to shift left, you want to use your tools that only you understand and convert them into something that is useful to others, to people who are not specialized in, let’s say, security. So the question is really how do I contribute my knowledge into that company platform. It cannot be one group of people, because that platform is to provide everything: this is how we manage our infrastructure, this is how we define our applications, this is how we deploy our applications, this is how we do things so that it is secure. So it’s really figuring out how to take the tools that specialized people use and convert them, or create completely new abstractions on top of those tools, that will enable, I’m about to use the word dummies, that’s not the right word, but people who are not specialized in those areas, use them.

So I’m pretty sure that, ideally, you as a developer should have complete freedom, complete 100 percent freedom within the things that matter to you. I should have full freedom to say whether my application is backend, frontend, stateful, stateless, this is the host, which is it accessible, and so on and so forth, I should define those things, complete freedom. But then there are things that are not about freedom, there are things that I don’t understand, that I don’t care about, it’s just, like driving a car. I want to have complete freedom to choose where I go with my car, when I turn left, when I turn right, but I have no intention of assembling the car myself, you just need to make sure that the one that you’re selling me, the one that you’re giving me, is giving me all the possibilities that I deem to be important for me. If you need to drive, that could be a stick or no stick, automatic or stick, it’s my choice, it’s not yours, but if you need to go off-road, if you need four-wheel drive, if you need to drive in snow, if you need a truck to haul things, all of those things need to be there. You need to figure out what are my needs, that’s the essence of everything, everybody has a customer, and you need to figure out how you can sell me something, and when I say that I don’t mean business-wise outside of my company or users of our products or services, but within your company.

And so is this just the Ops thing that I see popping up everywhere, because basically every call or show I’ve been doing with Breaking Changes, it’s DevOps, and then there’s SecOps, and then I had a DataOps conversation with someone, and then MLOps and ModelOps, and then yesterday we did one that was a cloud transformation specialist and they were talking about FinOps, so managing your budget, your Amazon spend, and dialing that in. So is this all just Ops and trying to create these structures that exist that help us manage this end-to-end?

Yeah, there is, we’re still maybe missing a term that would group all those things together, because my first reaction when I hear now DevSecOps, FinOps, and stuff like that, is, okay, that’s very useful to you, again, that’s your silo. And that’s very important, each of us specializes in something, and we need to have ever better and better ways to do whatever we need to do, but it’s very easy to lose the end goal, or to forget about the end goal, and the end goal is to enable developers to be more proficient. And if by having 57 new terms that start with dev and ops and something in the middle we are going to accomplish that goal, great, but I’m afraid that we’re again going into circles, seeing removal of silos and then almost immediately after that recreation of those same silos. I really don’t want to open a Jira ticket to anybody to do anything that is related to my work. Now split people any way you want, but the end goal is that I never ever open a Jira ticket to request something as a developer.

Yeah, I should just be able to do it, I should be able to set up the database, I should be able to set up the compute, whatever I need. A good example is AWS, I dare anybody to show me an email that they sent to AWS saying I need a VM or any other email requesting something. AWS or Google, they’re actually very good examples of that, you can do anything you need to do, I mean not anything that could be done, but within their area of expertise, anything, without ever contacting a person. They’re making operations, let’s say, and I’m using that term very loosely, very self-sufficient, you can do anything you need to do to manage your workloads in cloud, brilliant. I want the same, I want all of those people using services like AWS to do the same thing for everybody else in my company.

It’s kind of like the old Jeff Bezos myth that is mostly, but you still hear a lot about, how he said if you want to order compute from your IT department, you’ve got to do it through a service, if you want something from marketing you should do it through a service. And I used to make jokes to people that, well, I’ll just abstract away the Jira API and not let you know that it’s the Jira API, and you can make any requests to the Jira API and it’ll open up a ticket, it’s the worst idea possible, I would never do this. I was just joking that people abuse Jira and Jira becomes this bottleneck. But the point I’m trying to make is, if your entire topology is an API, is a service, and you have the right identity and access management layer layered over the top, anything new, any new third-party SaaS, anything, should be abstracted away as part of that, and you should be able to provision anything company-wide through a service.

Right, and now we’re getting to the real deal. Everything that we were speaking so far, I think boils down to, different groups of people with different expertise, they have different services, I do not care about those, that’s your thing. What I do care about is that they all are converging into a single API that can be used by everybody in a company. Now whether we put UI or CLI or Visual Studio Code on top of that API, that’s to me already a simple thing, I do not care about that, those can be even auto-generated. What we really need is an API, every company needs an API that will enable everybody to perform whichever tasks they want, whether that’s creating a virtual machine, whether that’s creating a cluster, defining the state of an application, or anything else, whatever we need to do goes through a single API, very simple, I mean very hard to accomplish, but it’s really a very simple idea.

What they don’t want is, sorry, go ahead. What they don’t want is for every group of people providing different services, Ops, security, this and that, to give me their own unique API for something, because then we are getting into the game that I will never learn those things. If I need to figure out a Puppet something for this, and Terraform something for that, and junkie something for that, sorry, I will not, again, support those tools, because they’re part of what you do, I don’t, just like you do not understand the Go compilers because that’s not your job. So when I talk about those types of platforms, I’m really talking about hiding all those complexities behind a simple tailor-made API, and behind that API a control plane that will make sure that, you know, you request this or you define the state of that, it goes to the API, there is a control plane of whichever technology you want, that’s a secondary thing, that is making things happen. Now whether that control plane will create a Jira ticket, and then that Jira ticket will be converted into five other Jira tickets, and then they will execute shell scripts, I don’t care. What I do care is that I get the response reasonably fast saying, okay, it will be done in a relatively brief period of time.

What’s behind it, yes, it can be powered by Excel for all I care, it’s Mechanical Turk, it’s a human, we’re just outsourcing that to humans somewhere in the world and they open up the Jira tickets. I mean, like when you shop on amazon.com, you do not really care what’s behind it, you just care that the service you’re getting, you click a button, it goes to shopping cart, you purchase something, it already knows your bank account and whatever, and within 24 hours it’s at your doorstep. Now whether it came from China or India or from two streets below you is completely irrelevant.

Yeah, and that abstracting away, this is when I say API first I get a lot of pushback from a lot of people, because, like DevOps, it’s an abused term, an abused phrase, to the point where it’s almost meaningless to a lot of folks, but I try to push on everybody across the organization to do things in an API-first way. And most people associate it with, well, before we build a web app or a mobile app we should build an API and do it properly, and that’s the 2008 version of it in my mind, but mine’s the Amazon, what we just talked about, all your infrastructure of APIs, your Kubernetes, everything has APIs, your network, you talked about your VPC, I should be able to set up my networks in an automated way. But I also try to get business folk, I have groups who are doing educational resources and trainings and workshops, and they’re reviewing software for training materials, and I said, are you doing it in an API-first way, and they’re like, well, we’re not going to build an API, and I’m like, no, before you sign that three-year contract, do they have an API, does that CMS or that learning management system have an API, because I want to abstract away this decision you made, because, no offense, you’re going to be gone in three years and no one’s going to know why you made that decision to buy that software, and as long as I have it abstracted away with a simple interface that Viktor wants, because Viktor never knew, didn’t care, wasn’t involved in the buying of this software, but it’s abstracted away, and Viktor can still get the educational resources he needs for his workshops.

Exactly, as long as that is simple for Viktor, because Viktor cannot comprehend complicated things.

Absolutely, yeah, and then on top of that, automation opens up whole new worlds for automation to be able to do stuff, but abstracting away things, whether they’re internal infrastructure, external services or infrastructure, and creating that enterprise stack that is going to enable us, I think, because then I don’t even see left or right, it’s any direction that you want to go, it just opens up a whole new world with a lot less limitations.

Oh yeah. The only thing I would add to that is I think we need to start distinguishing those top layer APIs that are actually supposed to be used by everybody, and the majority of everybody does not care for many of the details that you do, and the APIs below that, what I mentioned before, VPCs, nobody cares about them, please do not force me to go through that. When we are talking about that top layer API, the universal API, we need to simplify things, and simplification needs to happen on the API level, because if it doesn’t happen there, then it’s not going to happen in UIs or CLIs or IDEs or anywhere else.

Well, how do we deal with all the opinions? As you said, this has to be opinionated to get us here, but even I struggle with the API layer, because it’s got to be GraphQL, no, it’s got to be REST, no, it’s got to be hypermedia, it’s got to be Kafka, no, HTTP is not going to do what we need, we need gRPC and HTTP/2. So how do you address all those opinions and abstract away the opinions and the things that tend to come with the opinions?

So in the majority of cases, most companies already have very strong opinions, to clarify. So you will hardly go to a bigger bank or insurance or car manufacturer or whatever that they don’t have very strong opinions how their clusters are set up, how their applications work, everybody’s already very highly opinionated. The problem is that they rarely kept those APIs that actually abstract those opinions, that actually provide the communication bridge between which parts of those opinions should be public, and when I say public I mean accessible to everybody in a company, and which should not. They are very opinionated about 57,000 different things that need to happen about your cluster, but what the majority of people, when they open a Jira ticket for you, what they really say is that I want the cluster in US and it should be small. Or maybe actually those Jira tickets, forms or fields in Jira tickets, would give you a clue, like, okay, so when people request something from me, what is the form that they’re filling in and which fields they’re putting dots in, because it’s a mandatory field so you need to put something but you do not know what that something is. So kind of you remove all those fake fields and say, this is what matters, this is what people care about, it’s as simple as that. So opinions are there, what is missing really is finding out what people really want, because we rarely treat other people in our companies as customers, more like people that bother us.

Yes, and it’s that, I’m doing a lot of work right now on APIs as a product, how do you train that next generation of product managers to develop APIs and do it in a rapid, iterative way, but not in a way that reflects just our technical desires, actually has that feedback loop in place with the customers and real-world customers and stakeholders who actually are going to give the feedback that’s needed to make sure that it’s not just a service or an API, it’s a product, it actually solves a problem, brings a certain solution. And I was talking with one of the top insurance companies last week, and they said, well, we’ve been doing the API thing, we launched a portal in 2015 and we published a bunch of APIs, and it was an IT-led initiative, and they were good, and we had some hackathons and people built some interesting things, but really they’re not products, they don’t solve any business need, they didn’t have any monetary aspect in mind, they were just kind of play things, technical play things, that we jumped on a trend and needed to do. But we started getting more business stakeholders early on in the process, we started opening up wider, modernizing other legacy stuff, wrapping them as services, and made our internal catalog, and then started equipping people to go external with these new and create new products, but they were built on legacy infrastructure, built in this new API way, but they had business intent, business value, we took away the fear of going external and opening things up with partners, so that we could get more business stakeholders and more feedback, and they posted like 10 billion in annual earnings last year, it was insane, and this is why they’re able to do it, because they have that feedback loop, they treated them as products.

Exactly, it must be a product. A counter story to that one is, actually maybe five days ago I was at a conference, I spoke with a guy who came with a question, said, look, I just spent a lot of time building this and that for developers, and they do not want to use it, can you help me figure out how to convince them to use it? And I was like, no, it’s not about you convincing, if that is serving their need they would be using it. So the problem is not that you’re not really convincing, the problem is that you’re not serving their needs. And that’s what products are about, every single successful product, I’m not talking about our industry but in general, every single successful product is based on a very simple idea, we are solving somebody’s problems, somebody’s needs, and because we’re doing that, they’re happily using our products or whatever the product is. Very simple, it’s a product.

And history is full of lots of products that didn’t meet a need, they just don’t exist anymore and you never hear about them. They go away.

Yeah, it’s just that when those products are on the real market, it kind of becomes a bit easier, because that product is not attracting enough revenue, it’s not really successful in the market, therefore it goes away. Now when we talk about internal products, since they’re not really following the same market logic, in a way they tend to keep existing forever, because we built this, therefore everybody must be using it.

Right, well, we can control the market, we can mandate, hey, everyone use this, so we artificially create more.

Exactly, you must use this, and then you turn your back on those people, and then if you leave the recording device, you will perceive that they really, really hate you.

So do you think microservices and everything that’s happened with that, do you think we should be treating these types of services as products more, and changing the way we do things internally?

Yeah, so I wouldn’t necessarily say I’m a huge fan of microservices, I don’t think that microservices solve all the problems in the world, and I really hate Taliban type of behavior, kind of like everybody must be using Kubernetes, everybody must be using microservices, so on and so forth. But what I do like about microservices, and my description of microservices tends to be different from the description of other people, microservices is what you can develop in a team that is less than 10 people and have full control of that something. And it needs to be relatively small by nature, simply because you cannot have a huge monster developed by, let’s say, eight people that includes testers, managers, and operations and everything. So I like the idea of each team being able to work uninterrupted, which I believe is the essence of everything I said so far. The reason why I want all those services from other teams is so that I, the other seven, eight people in my team, we can just go as fast as we can without being stopped by, oh, now it needs to go to this department, like security audit, and whenever you say security audit to people they really get depressed, not because they don’t want their software to be secured, but because, hey, that means that our project is going to get delayed now, because we are going to get a list of the things that we should have done three months ago but we didn’t because we have no idea what those things are.

So with this freedom, you give your teams agency and freedom to do as they need, comes with accountability though too, because if you have services that others depend on, you have to be accountable to those dependencies on you as well, so it’s a two-way street, it’s not just getting out of your way so you can do what you want, you’ve got to be held accountable as well.

Yeah, you have full ownership of it, that means that, hey, if it stops working in the middle of the night, Saturday night, it’s your responsibility to fix it right now. Now sometimes things fail because we have a bigger problem than problems related to one application, the whole system, the whole data center might be down, so I’m excluding those cases, that’s kind of dealt with separately. But my application, my product, my benefits and my responsibility as well. And this is also in your cost, how much your Amazon bill, among other things, I should have my own budget, and I should be incentivized actually to save money, and the only way I can be incentivized is if it’s actually my budget, not your budget. What is the incentive for me to make a more efficient application that actually requires less memory and CPU if I’m not in any form or way involved in how that application runs, if that’s your job?

Yeah, agreed. Wow, I’m glad we just jumped right into this conversation, I can tell we could go on forever, but our data shows that people stopped tuning in around 40, 45 minutes. But I would love to bring you in, I’m glad Latroy connected us again, because I would love to bring you in to be opinionated on some of the other conversations I’ve been bringing up. So I think I’m going to schedule some time to bring you back to have another “what’s with all these ops, everything being ops” conversation and have you help me poke some holes on some things, because you got lots of opinions and I love it. What I always try to end on, on a lighter note, what’s keeping you alive and happy and interested these days beyond technology, anything in your life that makes you happy?

My daughter. So it’s either my daughter or technology, I’m one of the weird ones that my hobbies are what happens to pay my bills at the same time, so yeah, to be honest, I have no interest beyond technology apart from the family.

Yeah, I relate to that, I can relate to that, I have one daughter, and my life has been doing APIs and doing what I do, and I worry sometimes because I don’t have any hobbies, or I’m not artistic, or I’m not creative, and my daughter, the other day, she had to download R for a statistics class, so she’s in university now, and I started having anxiety, I guess, about her having to deal with the technology journey that I’ve been on, but I’m hoping she’s going to be strong enough to handle it.

So I have a theory that the vast majority of people, I’m not now talking about our industry but in general, hate their jobs, and the main reason why people have hobbies is because they need something fulfilling after the nightmare of working at something they don’t like. Many of us are lucky, we actually get paid for doing what other people would consider a hobby.

Yeah, no, I like that, I agree with that, because I love what I do, I live and breathe what I do, and I don’t feel bad for doing it. I mean, I do burn out from time to time and work too hard and don’t balance things, but I like that a lot. Well, I’m going to say goodbye here, but don’t leave, I want to get a goodbye from you for the show. So this has been great, I really enjoyed sitting down with you, I’m glad you made time, I’m glad Latroy connected us. Thanks for joining me for Breaking Changes today.

Likewise, thank you for carrying me.

Thanks again to Viktor for stopping by. For more on Viktor you can find him on LinkedIn, and you can learn more about Upbound at upbound.io. You can subscribe to the Breaking Changes podcast at postman.com/events/breaking-changes. I’m your host Kin Lane, and until next time, cheers.