Episode 90: Shipa's Bruno Andrade on the Future of Kubernetes

Brian Dawson: Thank you for joining us again for another episode of DevOps Radio. Today, I’m actually excited that we’re kind of continuing what has been a reasonably recent trend of speaking to technical folks who are also CEOs and founders. So we get to discuss the gamut of that founder experience, that business view on things, but couched in a technical lens for people that are coming together to solve technical problems. 

Today with us we have Bruno Andrade, CEO and Founder of Shipa. Hello, Bruno. How are you doing?

Bruno Andrade: Good. How are you, Brian?

Brian Dawson: I’m doing fantastic. I am really interested in learning more. I think as we’ve said, I want to learn about why your company and about your company, but there’s a particular position – and actually, let’s just start with this – that you hold on Kubernetes, which I’m really excited to dig into, and that is that Kubernetes will disappear and developers won’t care. That’s pretty controversial, so I’m going to challenge on that.

But before I do, can you start by giving our listeners a brief intro into what you’re doing today and how did you arrive here? What is your career background? What was your path to CEO and Founder of Shipa?

Bruno Andrade: Of course. Thanks for having me today. Today, I’m one of the founding members or founder of Shipa, where we focus on the implementing and application management framework on top of your cloud native infrastructure. 

Being a COO in an early-stage startup, basically, you were doing a bit of product, a bit of engineering, a bit of marketing, and everything together. At the time, when we used to have offices, I used to say that I hold a Costco card. So that’s kind of my main position in the company, making sure we still have snacks, we still have some stuff to drink and coffee. So that’s my main role. 

As a background and how I landed here, I’m a computer engineer, and I had an opportunity to work on product development across middleware, financial services around a BI and analytics type of product. But at the end of the day, I spent a lot of my time doing sysadmin stuff. Before we had the fancy and cool names of platform engineers or DevOps and SREs, before that whole kind of cool naming convention came up over the last few years, I was a sysadmin, so implementing systems, helping applications get deployed and help those get maintained. 

It was interesting to see how everything changed from physical servers into VMs and then into cloud. Then cloud was not fast enough and now it’s getting to containers, and then moving to the whole microservices and cloud native, and seeing the opportunity around managing and implementing those apps at scale is what got me here at Shipa. 

Before that, I had roles at large tech companies developing products. I had another startup before this one, and now my second startup. 

Brian Dawson: So out that, there’s a lot of stuff, but the most important thing that comes up there is what is your and your team’s favorite item from Costco?

Bruno Andrade: [Laughs] coffee. Coffee, and Red Bull maybe coming in second there, but coffee for sure, yeah. 

Brian Dawson: All right. I thought it might have been the hot dog, the pizza or the rotisserie chicken. But no, seriously, that is interesting. 

Now, let’s actually get into that controversial statement. We all know and, at the risk of sounding redundant to our audience, we go through technology cycles, and there are times when there are technologies that are rightfully kind of the dominant hot thing, and they actually change the way that we work, the way that we develop, the way that we deliver. 

An example has been the progression across SCMs into what we now have, kind of a hosted Git as a social coding platform. Another one, after a battle between Docker and Mesos, et cetera, is as we’ve embraced cloud and we’ve had to figure out how to get there and get there efficiently, Kubernetes is the hot, empowering technology of the moment. 

For me, who I work at a vendor, it’s hard for me to find a customer that is not trying to figure out a Kubernetes strategy. It’s hard for me to go to a community where there’s not conversation of Kubernetes. Yet you, Bruno, say – and I got this from a talk, so maybe I’m wrong in attributing it to you – that Kubernetes is going to disappear and developers aren’t going to care. What’s up with that?

Bruno Andrade: I know a lot of people don’t really like when I come up with that talk. They find it controversial. People get really defensive, I’ll say, because that’s where they’re trying to go from a broader and broader capability and that’s how they’re being important in their organization, using that technology and, “That’s my expertise and I’m well-positioned within my organization.” 

But the reason why I see that is exactly because of what you said. You see technologies come and go and you see those cycles. A very, very simple example is you have Linux. You have a kernel there, but who cares. Who cares if we’re running CentOS or Ubuntu? You don’t really care as a developer today, but I’m sure if you just go back and kind of rewind things years ago, you would really care. Now it’s Linux. I’m the sysadmin and I’m a certified Red Hat. You had all that stuff, right. 

The same thing with VMs. VMs, they came along. They changed the market. We started talking about how to automate the environment and so on. But at the end of the day today as a developer, who cares if we’re running VMs and how you spin up your VM? You don’t really care. 

If you push it a little bit even further, if you are an organization that you’re implementing Kubernetes in all your apps, at the end of the day, you are serving customers. You’re getting your applications out there. And for your customers that are consuming, when you open up your cell phone and open up your apps, you don’t really care if it’s using Kubernetes or not, right. 

Bruno Andrade: I think today Kubernetes is a hot topic. It’s a great technology, but I think Kubernetes will point us in the right way. Then slowly it will fade away because the complexity will start going away and people will focus on the right spot. I think it’s the application at the end of the end, because that’s what you serve to your users and customers. In a way, Kubernetes will just become a commodity. It doesn’t really matter where it’s coming from. I’m just consuming the services. 

Brian Dawson: Yeah. I’ll dig in on that a bit from my perspective, kind of some interesting correlations I do think you bring up. In an early-stage cycle, it makes sense that oftentimes we as technical folks or technical practitioners, especially as individual engineers, we get caught up in the technology as the end as opposed to the means to the end. It’s almost like someone that chisels statues really celebrating the chisel as opposed to, really, the chisel is there to generate an outcome. 

Brian Dawson: So I think that is an important thing that all of us, both as technical leaders, practitioners, and people associated think about. It also just gives me an opportunity. I’m getting a little older, Bruno. So I’m now in that where everything is nostalgic. I’m not going to force you to start to talk with me about registers and pointers in C.

But I did have a chance, actually. I worked on the PlayStation in the early days, and one of the key benefits that the PlayStation has is that it brought together previously complex 3D transformations on a chip as well as kind of bespoke chips. The actual designer of that chip was very much focused on that.

Each iteration, what we do is we give a chip set. We give some fairly fundamental or rudimentary instructions. We then watch a cycle to see how people use it. Then we abstract that against higher level and higher order instructions and build it into the chip, right, and that’s how we progress.

So what I’m hearing from you is what we’ll see with Kubernetes, Kubernetes may still be there. It’s got a hold. I expect it will probably live for a while, but we’re going to arrive at a point, to your point, where we don’t care. It happens to be an underlying means to an end.

Yeah, I can absolutely appreciate that slant on that. So is there a specific impact that this predicted shift of yours will have on a developer? 

Bruno Andrade: I think the biggest one is productivity. Again, if your focus is delivering the app or delivering the PlayStation to your users for consumption, the developers need to focus on getting that application out there and deliver updates fast and so on. I mean Kubernetes will be back there, just like you have Linux. If you still want to go to the kernel and kind of turn the knobs a little bit and get to where you need, it will be there, but nobody really cares about it anymore. 

From a developer perspective, if you’re deploying maybe five services, that’s no big deal. But we’re talking to organizations and they are looking at the point of 200, 300, 500 services over the next year. Then when you get your developers, basically pull that down into knowing what is an ingress. Are we using Istio, or are we using Envoy together, or are we using Nginx? How do we figure out an ingress rule? How do we do Canary? So your developers are getting pulled down to that and learning how to deal with that, and they spend time on it. 

So the less time they can spend on the infrastructure, kind of getting to know Kubernetes – I’m not saying you shouldn’t learn. Learning is powerful and you definitely should understand how your code runs on everything, just for the sake of being a better developer. But that will allow us, as technology evolves and Kubernetes takes a back seat, your application becomes the primary member or the focus in your organization. So I think productivity is the main thing the developers are going to get out of it.

Brian Dawson: Shifting from the developer, if we look at thing in this way, how should the organizations, i.e., the leadership, the architect, possibly even product managers, shift the way they view Kubernetes in light of what you’ve just discussed? Is there different way, either your cohorts, your clients, your customers are looking at Kubernetes or that they should? 

Bruno Andrade: One of the things that we talk a lot about with customers and even internally here at Shipa, we feel that there is a big lack of a workflow today. There are a lot of talks about DevOps and there are a lot of talks about cloud native and bringing Kubernetes and so on, but Kubernetes is just one of the tools that you can use to achieve what you need. 

Kubernetes is definitely not going to solve all your problems. It’s not going to address all of your requirements. But what you need is a workflow and a process. What do you want to deliver? What type of application, and what type of security and controls around it do you want to deliver? 

These are the teams that I want to deliver this. These are the types of integrations I need with external services. This is the type of security I need. So define the workflow based on their application needs and bring them together. Because those topics, people talk a lot about security, but security tends to be just a container security scan, a vulnerability scan, but if you look at it, it’s such a wide kind of workflow around network policies and who does what and so on. So put that workflow together based on your application needs. 

Then, with that, you can choose Kubernetes for specific parts of your application and maybe Monolith. I know people are not going to like that, but maybe Monolith is the right answer for some of your services.

Bruno Andrade: But drive it based on your application needs. I’m an engineer. I love sitting down and dealing with cool, brand new tech and testing stuff. But how much time do you actually spend on that rather than what it actually needs to deliver? 

Brian Dawson: There’s a lot that’s interesting there. Going back to our earlier point, I run into this a lot, kind of facilitating transformations, deciding on tools’ problems. Look, I live in the Jenkins universe, where oftentimes we place a lot of stock or a lot of value in the deep understanding of a given technology, which I think you’re saying, to your point has value. But look, at the end of the day, for most of us, we’re working in the context of what we’ll call a business outcome, and we also have to be thinking about what is the best and fastest way to get to that outcome, not caught up in the fact that I could tweak the bits, so to say. Fair?

Bruno Andrade: That is very fair. I saw that happening quite a lot, even before Shipa or my previous startup. I’m a computer engineer and I have a sysadmin background as well, but I had a chance to step out of kind of delivering products and implementing products and I stepped into consulting. I spent three or four years maybe doing consulting. We all have a dark side. That was mine.

But that was awesome because I stepped out of the computer. Then I started learning how other organizations are doing. What were the points of inefficiencies that they were going through when implementing methodologies and technologies and addressing their application needs? So seeing all of that and the lack of workflow, and the pull and focus towards what they need to deliver rather than a specific technology. There’s just so much more that you can improve from a developer and a DevOps perspective as well.

Brian Dawson: Awesome. Before I shift to wanting to talk about this concept of dev Kubernetes experience and full stack, et cetera, I realize I’m going to go to a one-on-one question, because I said upfront our audience knows what Kubernetes is. Everybody knows. We actually have a range of listeners. 

Could you tell me briefly what is Kubernetes and what is good about it, its value? We’re talking about where it doesn’t apply or how to kind of de-emphasize on Kubernetes. But real quick, from your perspective, what is Kubernetes and how are people using it well or what problems are they solving?

Bruno Andrade: At least from my perspective, Kubernetes is a great scheduler for deploying and managing your containers and your microservices across a distributed infrastructure, period. I think, from my perspective, that’s where Kubernetes is great. I’ve seen some of the similar technologies coming from the past, but now, people are trying to build a lot on top of Kubernetes.

Kubernetes, I think I’ve heard multiple times people saying Kubernetes is a platform for you to build platforms. But not always. Again, that goes back to what you need. Do you just need to run your microservices in a distributed fashion, but it’s still organized? You still have control over it. Then Kubernetes is great for it. 

Now, if you are going to go into Kubernetes as a platform for building platforms, then the question for you is: is your organization’s main goal to build a platform? Do you want to build a team around building platform so you can deliver your microservices? 

If yes, maybe Kubernetes is not the right answer for you. Do you want to spend one to two years in a journey to build a platform, just to make Kubernetes work for you? So I think those are the points that you have to evaluate. Is Kubernetes great here or not?

Brian Dawson: That’s actually an awesome way to look at it. Another question, while we go on this kind one-on-one on Kubernetes: what is the correlation, both between Kubernetes and what you’ve talked about with abstraction and enabling developers to focus? How does all this relate to the DevOps movement? Since this is DevOps Radio, I guess I should ask that. How is this an enabler of DevOps? Is there a correlation? What are your thoughts there? 

Bruno Andrade: I think there is and it goes back to the workflow. Kubernetes is a tool. DevOps is not a tool. DevOps is a methodology on how you basically execute things to get your annual meet. So how do you now take Kubernetes into that workflow that helps you get to the end goal?

I think that’s what organizations – there’s a lot of talks on DevOps, and a lot of us in DevOps, this space, are folks that came from that sysadmin background and they’re accepting into it. But I think now, the folks that you get that are smart and leveraging the right tools for the right methodology that they need to deliver, I think that’s where you excel, and that’s how I see the core relation between Kubernetes and DevOps today. 

Brian Dawson: I think, to give my opinion because I’m never a shy one, I won’t get into the details of Kubernetes because you covered it, but it can help connect the left-hand side of an organization and the right-hand side of the organization, dev and ops, to better establish shared ownership and enable you to achieve velocity in pursuit of delivery and quality software rapidly, reliably, and repeatedly. 

Someone recently had tweeted a funny job description, where the company was requesting 12 years plus – sorry – 12-plus years of experiencing Kubernetes. This sounds to speak to the misfocus we’ve talked about. Do you have an opinion on instead of looking for – I mean practically more years of Kubernetes – actually, more years of Kubernetes experience than the project itself existed? 

I’m forgetting the name now, but we can go back to the precursor that Google might have existed then, and there’s probably about five people that you can hire with that experience and work. But what capabilities should companies be looking for instead?

Bruno Andrade: I think you’re referring maybe to Borg. 

Brian Dawson: Yes, Borg.

Bruno Andrade: I don't know. I did see that tweet actually running around, and maybe that’s just a future job opening. Maybe the guys are applying for five years ahead or six years ahead, but you do see that happening. 

It goes back to teams – there are – [audio garbles] – when it comes to that, right. This is HR’s job when talking to – in large organizations I mean – talking to the team that is hired and basically, “Tell me everything that you need.” When you’re hiring, a lot of people focus a lot more on the cool technologies and everything that they might need in the future rather than, “Here are the things that we really need someone to be really good at to deliver.”

So there’s a lot of miscommunication between the hiring team as well as the HR person that is driving this type of initiative or the hiring. So you see discrepancies happening here and there, but I would say there is no right capability to have on the job requirements for developers or the right capabilities are the capabilities that are going to help your organization to move in the right direction and deliver fast. And that may be Jenkins or that may be Shipa or that may be Kubernetes, or maybe that is VM or maybe that is Java. So you really have to take a step back and look from an organizational perspective. What is going to help me actually to drive the delivery faster and in a higher quality? So those should be the requirements that should drive your job requirements, I would say. 

Brian Dawson: That’s interesting to dig into as a person that is building and has built companies. It is really interesting as I am no longer interviewing for engineering jobs, but at some point, it really started to get discouraging as an extension of this. It is like, “Must have two years,” of a very specific language, two years of that very specific language, and a requirement or skills list ended up being a list of like 20 very specific technologies, languages or tools, sometimes which didn’t even fit in the same bucket. Like there’s no way on a career path that someone would have had this mix of things. 

It gets me to think. We talked earlier about we’re in a very rapidly evolving market. Frankly, we can hire for what we think we need for our particular product today, which is fair. You can drop somebody in. They bring that expertise that can help the rest of the team. But there’s a good likelihood that with our technology cycles that’s not going to be relevant in two or three years, or you’re going to change the direction of your product. 

So kind of putting your founder hat on, your COO/founder guy with the Costco card hat as well, what’s the balance? Do you hire for fungibility? If so, how do you suss that out? Also, for our engineers on the call, do you develop a wider range of flexible skills or should you hyper-focus on a specific [skill]? 

Bruno Andrade: I think there are opportunities for both. I agree with you. The market changes really fast and the technology that we use changes really fast. But if you are in the microservices space, kind of distributed computing or maybe this is how you deliver an application, maybe instead of focusing just entirely on, “I need someone who is an expert on Kubernetes,” bring someone who is really good at distributed computing. Bring someone who is really good at microservices.

That person, even if he is not as good on Kubernetes because he spent his last year or his last few years doing Docker Swarm or Mesosphere, for example, and he’s just jumping into the Kubernetes bandwagon, that person will know how to transition from what he knows into Kubernetes. And if we change from Kubernetes to something else, which I’m sure we will in a few years, that person will be able to morph into that role. I think bringing the capabilities, focusing on the capabilities rather than a specific technology helps a lot in that sense. 

Now, there are technical lead roles in our organization as well that I need a very good person to know Golang tied to Kubernetes and deliver this type of architecture, and that person will help lead the overall strategy and the deliverable of that application. So I think there are opportunities for both. Again, you have to see the capacity of your team, what you need to deliver, the speed, and where you’re going from an organization and kind of roadmap perspective. 

Brian Dawson: Fantastic. I have run into a number of developers, and we talked a bit about this at the frontend of the call, where I’ll go meet a young lady and she’ll tell me, “I’m a full stack developer,” very proudly and maybe accurate, where he or she says, “I’m a full stack developer.” Where does that fit into this world of Kubernetes? 

Again, we talked a bit about it, so I’m cheating. But what is your take on a full stack developer, and where or when that’s relevant in relation to Kubernetes? 

Bruno Andrade: We do have full stack developers in our team today. I think they are great. But my thought behind it is that there’s always one skill or one type of thing that, even if you are full stack and understand how applications get deployed, how your code is actually run, and how everything is calling the database and how the databases are running, and you can understand the infrastructure underlying, but I’m sure that most of the time that person is much better in one or two of these things rather than the whole stack. 

I think these people, they are great when having kind of the overall architecture visibility, and being great at delivering what they need to deliver when they are specific to the job because they can see how that interacts with all the other components in the infrastructure. So that’s why. 

Full stacks are great, but always try to master something really, really well. Don’t be the jack of all trades and master of none. Master something and learn the other things around it. That’s how you’re going to make a lot of impact in your team or organization.

Brian Dawson: It seems as well that Kubernetes almost came to fruition, I’d say, for want of a better word, in either in the DevOps or even, more specifically, the developer community in a lot of ways. You had mentioned the fact that it kind of blurred the lines between what are traditional roles, like where you say you may be full stack, coming from the ops side, the sysadmin side, or you may be full stack coming from the dev side, but what Kubernetes did is kind of blurred those lines. Can you talk a bit about that conversation we had around that earlier? 

Bruno Andrade: Yeah. I think at the end of the day, Kubernetes made us all YAML engineers. That’s what we’re producing a lot of during the day. But Kubernetes did blur the line because we’re now pulling the developers down to the infrastructure layer level. At the same time, we as sysadmins, we also have to go up to the code to understand how this is actually running, and why is my pod CrashLoopBackOff. Why is this thing not running? 

I think that’s where an opportunity for Kubernetes to disappear will bring a lot of impact and productivity across both DevOps and the developers. One of the examples I use to do it is, hey, I can learn how to make pizza. I do that because I eat a lot and I love pizza. 

Brian Dawson: Me too. 

Bruno Andrade: So if you’re just bringing maybe your family at home, a family of four, and you’re making pizza, you’re bringing the components. You’re putting this together. You spend the whole afternoon making the dough, putting everything together, baking and kneading. You can do that a little bit, like once a month or twice a month for a family of four. 

But now, bring ten people. Bring 50 people. Bring 100 people. If you try to keep doing this, you’re never going to achieve what you need. You’re going to be just stuck in the kitchen, trying to get your stuff done, rather than talking to your friends and learning how they are doing and what they actually need. 

I think that’s where Kubernetes – you’re going to need to let go of Kubernetes and use Kubernetes for what it is good for, but focus more and define the roles really well. Developers are focused on the application code, and DevOps are focused on delivering controls and guardrails around it, and everybody is going to win on that relationship. 

Brian Dawson: Fantastic analogy. I think it also speaks to scale, and the application of a technology like Kubernetes – I’m hearing what you’re saying – needs to be treated differently as you scale. Really, that is, like you say, defining the problem space, the constraints. What org are we in? How is our team structured? Are we a five-person dev team, with the guy with Costco card being our ops guy? If so – right. And you need to work around those requirements. 

So all of this that we couch this in kind of speaks to the future and that’s that we’ve got to shift. We have to evolve, not stay just couched in a technology, but at some point abstract it, rise above it. 

You know what I also have to share, Bruno? While this will air in 2021, you are officially the last of our 2020 DevOps Radio guests, which is pretty cool. I’ll let you know we’ve had an awesome year. We’ve had a range of really impressive guests, and that’s not me patting my back.

We also have Kiley Nichols and Harper Schmidt, which are part of the team, in identifying, bringing guests on and getting them ready. We’ll talk a bit about Harper before we sign off. But they built a great set of guests for 2020, of which you get to kind of be the cherry on the top. 

So you’re going to be the one that is tasked with what are predictions for 2021. How is software development going to change? What is going to change in terms of tools and processes in 2021?

Bruno Andrade: I think 2021, the one thing that I keep saying is that 2021, the way I see things changing and moving toward is being a workflow-oriented type of delivery, across both the DevOps side as well as the developer side, and focusing more on that workflow capability and what you actually leverage as part of that workflow to get to where you need to go in 2021. In 2020, we spent a lot of time learning what cloud native really is. Kubernetes has come a long way. Development has come a long way.

Now, microservices is not a new concept to us, but a lot of us who are using it were developing microservices and delivering. Now that we know the base and the structure, now how do we put this together? How do we put development together with DevOps, security, controls? How do we put that in a structured way that now we can deliver a lot more value faster? That’s where I personally believe 2021 is going to go. 

Brian Dawson: Would you characterize that as a bit of 2021 is when DevOps kind of becomes real? We actually facilitate an action of DevOps workflow? Is that –?

Bruno Andrade: I believe so, and we define well the roles within that workflow. What are the roles and the focus for the developers, for your DevOps? One question that always comes is – and you see a lot of mismatch still on that one – who manages the app after? So defining those roles and that workflow I think is 2021. 

Brian Dawson: Awesome. Thank you for sharing that prediction. Now is the time that we go into kind of a standard closing section. The next question is going to be what is a DevOoops, Dev O-O-O-P-S, not DevOps, but DevOoops, smack, oh, asterisk, asterisk, asterisk. What that is, is a software development challenge that you have faced in your career. Maybe it’s a mistake that you made that turned out to be a learning moment for you, that you can share with our audience as a learning moment. And the juicier and more embarrassing, the better. 

Bruno Andrade: I think for me, it’s basically going a few years back maybe, learning how to use Git. 

Brian Dawson: Yeah.

Bruno Andrade: I think everybody screwed up at some point with Git. For me, it was no different. Basically, using Git with submodules, which is painful. We had a series of kind of batch scripts and we were trying to implement some primitive concept of CI/CD without really knowing how to do it exactly.

Basically, trying to push this and merge this thing just got me into so many merge conflicts and get this thing basically to roll back. That was a mess, a mess that I got the team [into]. I also deleted branches by mistake.

I did part of it, actually, around kind of learning my way, the basics of Git to start, especially coming from that time with SDN and so on. Getting used to Git was a bit different for me. 

Brian Dawson: Now that you look back – first, I’ll get some really – I’ve heard people confirm this, but not many people say it out loud or publicly. The cognitive shift from a central version control system, like CVS or Subversion, to DVCS, i.e., Git, it was a little tough. I remember many nights going, “I just don’t get this. I don’t want to tell people that this is confusing the heck out of me.” Then you tie trying to automate the process around it. 

Is there anything that looking back you learned that would have enabled you to approach it with less risk? 

Bruno Andrade: I think proper branching and merging can get you into the appropriate input, basically, for your DevOps pipeline. So you can probably do some continuous integration and test and deploy your changes. So proper planning around branching and merging models can solve a lot of conflicts, I would say.

Brian Dawson: Yeah. I’ll underscore that recommendations, because I think when I got tied around the axle with Git, I was coming from a time – so I was consulting around Subversion. We’d spent a lot of time. We’d first start _____. Before we set up anything or set up a repo, let’s hit the whiteboard and let’s kind of define what your branching/merging model looks like. How do you approach it?

But then when I started toying with Git, it was like I was just going to jump in and make it work and try to build a process. So the process. Thank you. Great tip. If I go back in time, I’ll do better myself. 

The other is what is a book, podcast or resource that you recommend to the DevOps Radio audience, like that thing that they must go out and read, the person they must follow? What would you recommend? 

Bruno Andrade: I think if we’re being specific around DevOps itself, one book that I read this year and I loved it was The Unicorn Project from Gene Kim. It basically lays out kind of the – I think four or five steps around DevOps, around simplicity, focus, safety, improvement of the daily work. It tells it in a story that is just so compelling, and it’s just so easy for you to understand it and see yourself in the role that plays in the book. I think that was great. 

Now, if I take my DevOps hat off and I put on my founder role, then I’m reading things around Gap Selling, finding product market fit and so on. So that’s where I spend some of my time reading as well. 

Brian Dawson: Again, you’re the last guest of 2020. We still have a little bit of time left. So I’m going to squeeze you a little bit. Any specific titles? What is one book, either now or in the past, that you can think of from a title standpoint that people should look at, i.e., from that founder view or from that business view?

Bruno Andrade: From the business view, I think Gap Selling, or from a founder view, Gap Selling is really interesting because, as a founder, your end goal is always going to be taking your product to market, finding the right people and solving the right problem. I think that’s one that I really liked reading and going through, because that helps within that process. From a DevOps, I would stick to The Unicorn Project for sure. 

Brian Dawson: Awesome. Thank you for those. Since it’s 2020 and I’m breaking rules a bit, I will throw in a comment and then another book. It is not nearly as exciting as yours or some other guests, but my comment is even if you’re spending your time kind of alone on a keyboard submitting pool requests, reviewing pool requests, and you’re not directly driving the business, I would recommend those founder-oriented books, like Bruno highlighted, as things that can open up your eyes and give you context to what you’re doing everywhere. 

So one is whether you’re going to found a company or not, I recommend you invest a little bit of time in understanding how people sell software, how people plan what’s going to be developed. 

Then that leads me to, again, cheating and squeezing in my recommendation, and that’s take a look at the Product-Led Growth. I believe it’s Product-Led Growth Handbook. Unfortunately, I don’t have it in front of me. I think the title may just be Product-Led Growth. 

This really, as we talk Kubernetes, cloud native, as we talk SaaS and we move into a new world of software delivery, I think it really helps for all software development and delivery stakeholders to understand this new model of product-led growth. 

Bruno Andrade: I agree. I completely agree. What I take from what you’re saying, the key is learn how to solve problems. Don’t learn the technology because technology changes. 

Technology is going to come back. I was talking with another family member at Shipa. A lot of people don’t agree, but I spent a lot of time on WebSphere, a product called WebSphere, an application server. I see that a lot like Kubernetes. The difference is that now instead of a developer pushing the app directly, at that time we used to get the EAR or JAR file and we’d deploy that thing, but it was there. 

So technology comes in cycles and that technology will change. The same thing we had with Solaris, the zones in Solaris and all that stuff, and then containers, LXD, Docker and so on. So technology is just repeating. 

The smartest person is not the one that can create a new technology, but that can see what is coming in the future and can adapt what we’re used to, to that new reality. So you focus on the problem. I think if you learn how to execute and focus on the problem, I think that’s the biggest win you can have as a developer or a DevOps. 

Brian Dawson: Bruno, thank you. I think that was extremely wise and helpful. Those are excellent final thoughts.

Then, Bruno, thank you so much for your time. I wish you, along with our guests, a fantastic 2021. Bruno, please, with Shipa as well as with your focus on technology and DevOps, please next year help carry us into the future, so we can do things not only faster, but do things better and smarter. 

Bruno Andrade: Thank you for having me. I really appreciate the time and hearing your thoughts as well. That was definitely great. 

Brian Dawson: Awesome. All right, on to the New Year. Bye-bye.