Key Factors to Consider During Containerization with Travis Jeppson

Key Factors to Consider During Containerization with Travis Jeppson

Some of the highlights of the show include

  • How containerization enabled Nav to spread roughly 250 virtual machines across multiple environments, while drastically reducing infrastructure spend
  • Travis’s thoughts on buying cloud native software tools versus building them, and what engineers should consider during this process
  • The difficulty of finding security solutions that work inside of a cloud-native ecosystem
  • Why companies should expect to encounter unique challenges when migrating to Kubernetes
  • Why companies need to understand their end goal, and determine an overall objective before beginning a migration
  • Travis’s must-have engineering tool, and why he can’t live without it


Links


Transcript


Announcer: Welcome to The Business of Cloud Native Podcast where we explore how end users talk and think about the transition to Kubernetes and cloud-native architectures.



Emily: Welcome to The Business of Cloud Native. I’m Emily Omier, your host. And today I’m here with Travis Jeppson. Travis is currently at Kasten, but he’s also going to talk about his time as a director of engineering at Nav.



Travis: At Nav, my role shifted quite a bit while I was there. I started as a software developer, writing Ruby back end applications for them, and then shifted into—actually within a month of being there, they shifted me over to the operational side because I had previous experience working with containerization, and also in infrastructure. So, they quickly moved me over into that realm and from there, I worked there for about a year until they told me, go spin up a team and get things moving. Help us move to containerization. Help us move to a more modern infrastructure and stuff. And so, about a year after that I became a director of engineering to where I had our ops team that had spun up, and then I also acquired both our QA team and our IT team that was there. And then, about a year after that, I ended up acquiring a little bit more than that. So, I ended up with a fair amount of our front end and some of our backend teams as well, and where they moved me into the senior director position. So, a day in the life, towards the end of when I was at Nav was a lot of working with the teams, helping them to do a lot of architectural perspective, and changes, and outlook to where we were trying to get as far as the company is concerned. We were building a product that we could address both first-party customers where they would log in to the Nav website directly, as well as working with partners so that we could issue out Nav functionality to those partners that they could incorporate to their pages as well. And so, we worked very hard to try to segment those two pieces together so that what we were building could be dispersed between both first-party customers and our third-party customers. And so, towards the end of my time there, it ended up being a lot of working within all of engineering to help facilitate those purposes. Then, just about six months ago, I ended up shifting my role over to a company called Kasten. And, Kasten is strictly working within the Kubernetes ecosystem. So, we do data management for Kubernetes based applications, and I am the site lead in Utah for Kasten, and so my day in and day out, a lot is, it's, kind of, all over the place. Sometimes it's working with engineering to help figure out some things going on there, sometimes it's working with brokers to help find office space for it. And sometimes it's dealing with insurance. It ended up being quite dynamic. But overall, I'd say most of my time is really spent more on the engineering side, just from the perspective of having worked at Nav and having been a consumer of a lot of these technologies, I think that they really appreciate my insights that I'm able to give there. So, I end up working, a lot, with the engineers to help facilitate what we're doing.



Emily: Sounds like you end up serving as a bridge from having been an end-user. But do you think that there is common miscommunications that happen, or what do those conversations sound like? Why is that experience valuable?



Travis: Yeah, so I don't know if it's as much as a miscommunication as much as what are customers looking for? And what are they trying to achieve? And why are they purchasing different software solutions? And what makes sense for them, more than anything. And I think that, having been a consumer of those products, I was more or less on the front lines there. When I was building our operational team at Nav, that was basically what I was doing is trying to figure out what things are we going to spend time on? And what things are we going to build ourselves, or what things do we need to just go find a solution for and bring them in-house? And the funny thing is when I was doing that for Nav is actually when I was introduced to Kasten and to the CEO here. And so, that ended up changing the way my career went. But overall, I think what Kasten—what those conversations really end up becoming is what are customers trying to do, and where are they trying to go?



Emily: Yeah, and in fact, that is exactly what I want to talk about more on this podcast. So, tell me a little bit about what your experience at Nav was. What were you looking for? What did you want to prioritize? What was the company hoping to get out of moving to containers?



Travis: So, I would say maybe the piece that really facilitated a lot of the progress in that sense was starting to understand our infrastructure spend. And then, to couple with that was also trying to become more agile. More agile in the sense of being able to push on demand, where previous to that we were pushing—you know, when we push our code, we did it on a bi-weekly basis—well, every other week, and it was always very cumbersome. If we have pictures of us in the early days of Nav, where there would be 10 engineers around someone’s desk, and they were the one person that was pushing the code into production, just waiting for the other shoe to fall, or waiting for something to happen. And so, when I started doing operational things for Nav, it started addressing those two things. What can we do to help control our infrastructure, and to understand it a little bit better? And how can we also create more of a dynamic infrastructure? Like, Nav is very much a US-based company. And so, the traffic that we're getting onto our website was regional very, very much. And so, there would be periods where it would be very busy, and then there'd be periods where it wasn’t. And the way that our infrastructure was designed, and a lot of times the way that they are designed, especially with virtual machines, is that you're building for capacity. You're building to be able to handle that load, and that has to stay there all the time, regardless of whether that capacity is being used or not. And so, that was one of the biggest questions, and that bill was—we were completely in the clouds. We were completely in AWS, but that bill continued to get more and more expensive every month. To the point of where it warranted the executive team to come down and say, “This needs to be fixed. This is going at an outrageous pace, and we need to be able to figure out how to control this.” And so, that's when they came to me and said, “Okay, get a team spun up, and let's figure out how to control this.” And so, I would say that those wer...

Avsnitt(267)

Open Source Internal Startups with Saurav Pathak

Open Source Internal Startups with Saurav Pathak

This week on The Business of Open Source I spoke with Saurav Pathak, chief product officier at Bagisto, about a very different kind of business relationship with open source — and open source software incubated in a larger company. There were tons of interesting nuggets in this episode, but some things I wanted to call out are:For open source projects, the tech stack that the project is built with can in fact be a differentiating feature. This is unique to open source (and has come up before, both in my consulting work and in podcast interviews). Users might want to choose a project because it’s written in the language they are familiar with, even if the functionality is exactly the same as a competing projectThe difference in needs between the merchants (who just want to get their ecommerce store up and running) and developers building ecommerce platforms, who was worried about being able to build extensions How an open source company like Bagisto fits into the larger commercial strategy for the parent company. Build a community of developers versus building a community of merchants, and why both are important for a project like BagistoHow Saurav manages the tension between adding features that people want and not building an overly bloated product, including how to manage this tension when someone wants to contribute a feature that the core team may or may not want. It’s always interesting to me to see different models for open source companies, and Bagisto certainly is a different model. Especially after last week’s episode with Tanmai Gopal, which had a much more classic story.

5 Juni 202438min

Improving Your Value Prop Exponentially with Tanmai Gopal

Improving Your Value Prop Exponentially with Tanmai Gopal

This week on The Business of Open Source I spoke with Tanmai Gopal, co-founder of Hasura. We talked about how Hasura grew out of Tanmai’s previous company, which was a consulting company. I like to call out examples of really novel open source businesses, but in fact the thing that stuck with me from the conversation with Tanmai was that Hasura is going the ‘classic’ route… and it’s working. What does the ‘classic’ route look like to me? It’s an open source project that targets individual developers and a commercial product that targets teams and teams of teams. It’s having additional network security features in the commercial options. It’s using the open source project as a growth engine and getting leads from companies that depend on it. It’s also using the open source project as a way to get feedback on the product roadmap. Here were some of the takeaways from our conversation: It’s a lot easier to sell a product if your customers see it as mission-critical. One of Hasura’s first inbound leads was from a Fortune 100 company who said they’d be unable to ship any software for two weeks if Hasura went down — and so they wanted to make sure the team behind Hasura was serious and also wanted to pay them to make sure they didn’t go down. For Hasura, the first clear difference between open source project and commercial product was that the open source project is for individual developers but the commercial product is aimed at the team level.Even for the cloud hosted edition, the product with ‘developer-level’ focus is free. In fact, if you go to the Hasura CE product page, the CTA asks you to use for free on the cloud. Tanmai said this is an intentional choice because they want to reduce friction for people to test it out, and the fastest way to get up and running will always be to use the cloud version, not the open source. We talked a lot about the control plane versus the data plane — all the editions have the same functionality at the data plane level. But the control plane, where people are collaborating — that is commercial only. The open source project can be a great way to stay close to your users / customers and use their feedback to constantly refine your product roadmap. In fact, this can be a main advantage of being open source, because it is the only way you stay close to your users and get their feedback — otherwise you would often only talk to the buyer, who is likely an exec with a big budget but not using the technology on a daily basis. This doesn’t mean open source doesn’t create liabilities for Hasura — it does, and those liabilities have to be managed. And Tanmai is frank about the fact that creating enough value on top of the open source project without crippling the growth engine is a tough balancing act. Pay attention to what your best customers are doing! That has informed some really important product decisions for Hasura — and it took them way to long to figure out the unique way their happiest customers were getting more value out of Hasura than other users. Definitely check out the full episode for more insights from Tanmai!

29 Maj 202445min

Using Open Source for Trust, not Growth, with Reshma Khilnani

Using Open Source for Trust, not Growth, with Reshma Khilnani

This week on The Business of Open Source I spoke with Reshma Khilnani, CEO and founder of Medplum. Medplum is an open source electronic health record development platform, and one of the things I loved about this conversation is that Reshma is so focused on the healthcare industry — a level of focus that I find relatively rare in open source companies. And not only that, when I asked her if she thought the company’s focus was too narrow, she responded that actually she often worries that it’s too broad. Another thing I really liked about this episode is that open source, for Medplum, is about trust and transparency, not growth. Medplum’s customers, Reshma said, just don’t mess around with free software that doesn’t come with compliance certificates and some kind of support guarantees. It’s a great episode to come on the heels of the episode with Adam Jacob, who talked about the difference between code, software and a product — that is a distinction that Medplum has clearly nailed. Other takeaways if you’re running an open source company: Reshma is clearly really passionate not just about developing software, but about building software for the healthcare industry. She can also clearly articulate why her customers are not well served by the standard, off the shelf development platforms that can be used by any industry. This industry-specific expertise is really powerful, and quite frankly something I don’t encounter very often. Even though there are different legal regimes in different countries, the underlying needs are pretty similar, so even for something as specific as healthcare companies it’s not particularly challenging to provide a solution that meets the needs of customers around the worldMedplum is Reshma’s third company, but her first open source company. She talked about how one of the key differences between building an open source company and a her previous companies that that the company has to pay incredible attention to the implementation details that at any other company no one would care about. Yes, you’re building a product company… but that doesn’t mean you should never sell professional services. Reshma says that one mistake she made was being too rigid about not selling any professional services at all, and ultimately they ended up offering packages of services to help customers get their implementations running. One last bit of info: Reshma compared the conversation around open source startups now with “internet startups’ in 2013. Will all startups be open source startups in 10 years? I guess we’ll see.

22 Maj 202439min

The Difference between Code and Product with Adam Jacob

The Difference between Code and Product with Adam Jacob

This week on The Business of Open Source, I spoke with Adam Jacob, founder and CEO of System Initiative and formerly the CTO and co-founder at Chef. We had a wide-ranging conversation that at times veered into the philosophical (what is the meaning for ‘strategy’?) but also has plenty of concrete, practical insights. We talked about:The difference between being the CTO and being the CEO of a startup, even if you’re a founder in both cases (and why Adam wanted to try out the CEO role this time)How Chef started out open source primarily because Adam and his co-founder really believed in open source values How they figured out a business model for Chef, but that it really felt like they were just making it up was they went along — and how he suspects that’s what most people doGetting disrupted four times, and trying out many different business models along the wayWe also talked a lot about total addressable markets, serviceable available market and serviceable obtainable market in the context of open source companies. Three key takeaways: The software is not the product. A product is the entire experience of using the software, including how it is installed, how the team is onboarded, what compliance certifications you have, what happens if you have a problem, etc. As a vendor of open source software, you need to focus on creating and selling a whole product and take the focus away from the code. You can have 100% open source code and still sell a product, because they want to have a complete experience with support and compliance paperwork etc — and because they value buying those things from the same people who are writing the code. The way to calculate TAM is to multiply the number of people who want to buy a product by the average selling price of the product. When you phrase it this way, it becomes obvious that the TAM for any open source software is zero, because the average selling price is zero. If you enjoy this podcast, please share with other founders and leadership in open source companies! And if you like the idea of open source lawyer trading cards, reach out to Adam and he’ll start a physical product company next :).

15 Maj 202447min

A Buyer's View of Open Source Companies with Mark Boost

A Buyer's View of Open Source Companies with Mark Boost

This week on The Business of Open Source, I had a very different sort of guest — Mark Boost, the CEO and founder of Civo. We talked not only about Mark’s history as an entrepreneur, but also Civo’s recent acquisition of KubeFirst. This topic caught my eye because it’s not often I get an offer to talk with an acquirer of open source companies, and I wanted to take him up on it. (Though if you missed it, I also talked to Thomas di Giacomo about this topic, and it was fabulous). The that is different about this case is that Suse is fundamentally an open source company, but Civo is not, and this was the first time that Civo had acquired an open source company. We talked about:How the relationship started long before anyone was thinking about an acquisitionWhat the 1 + 1 = 3 equation looked like in this particular caseHow it makes sense for an infrastructure company to acquire a complementary software company What it means to hire a pre-revenue open source companyIt’s a relatively new acquisition, so we did a pre-mortem on it together, and Mark talked about what could go wrong — a super interesting process. Lastly, we talked about Civo’s open source projects and what business value the company gets out of it’s relationship with open source in generalCome join me at Open Source Founders Summit if you want more conversations about building open source companies!

8 Maj 202428min

Trying All the Open Source Business Models with Brian Fox

Trying All the Open Source Business Models with Brian Fox

This week on The Business of Open Source, I spoke with Brian Fox, co-founder and CTO of Sonatype. In addition to having a really interesting discussion about the usual topic of how to build a business around open source software, we also had a good conversation about security — it was hard to avoid, because we recorded this right after the xz backdoor discovery, and software supply chain security is kind of Brian’s thing. Business-wise, though, we also covered some really cool topics. Including: The tension between an open source project that’s “too good” and yet the need for the sales team to close dealsIn some ways, the fully commercial, closed-source products in Sonatype’s product line are more straightforward… but there are challenges that go along with a pure closed-source approach, too, especially for a DevTool company. Choosing your relationship with open source depending on who your target user / target buyer isPivoting to a top-down sales motion because the bottoms-up motion just didn’t work; and how that means the features that sell aren’t always the features that get usedWhat Sonatype gets out of it’s relationship with Apache Maven and open source NexusHow do we solve real problems, and how do we solve them for real? Keeping in mind that no one buys what they need; they only buy what they want. Check out the full episode, and come to Open Source Founders Summit if you want more opportunities to talk about about business and open source.

1 Maj 202445min

Aligning with User + Customer Needs with Rod Johnson

Aligning with User + Customer Needs with Rod Johnson

This week on The Business of Open Source I had Rod Johnson, founder/CEO of Spring Source and creator of the Spring Framework (as well as board member of many other open source companies) on to talk about Spring, monetizing open source and what’s changed in the open source ecosystem since 2008. Key takeaways:Consulting was burning the entire team out, and that threatened the health not just of the consulting business, but of the open source project as wellAn amazing salesperson can often sell anything, but that doesn’t mean that you’ll be able scale, because your entire sales team is not likely to be incredibly brilliant Spring Source ended up not monetizing Spring at all — but rather worked on monetizing with products that were complementary to Spring. “We monetized Spring by not monetizing Spring, by using it to open the door” The moment that the company really started to see success as a product company was when the team stopped thinking about what they wanted to build and instead focused on what customers where telling them that they wanted.The risk of having a bunch of very good engineers on your team is that they’re excited about solving hard technical problems — but your customers might want something that is not very technically challenging or interesting. A major part of the job of a company leader is to talk to your team and get them on board with your plans The environment around monetizing open source projects has changed — there are things that worked in 2008 that wouldn’t work today, and things that didn’t work then that would be fine nowIf you love (insert your favorite open source project here), it has to have a sustainable economic modelIt’s really critical to have a rationale behind what functionality goes in your product and what goes into your open source projectAt the end we talked briefly about Open Source Founders Summit, a conference for leaders in open source businesses happening this May 27th and 28th in Paris.

24 Apr 202446min

Taking a hard look at what community means and if every OSS company needs one with Deepak Prabhakara

Taking a hard look at what community means and if every OSS company needs one with Deepak Prabhakara

This week on The Business of Open Source, I spoke with BoxyHQ co-founder and CEO Deepak Prabhakara. We talked about a number of things, from BoxyHQ’s relationship with its open source project, called SAML Jackson to how to build a growth flywheel and how that flywheel does and does not depend on a community. Is BoxyHQ a security company? Does it matter either way? Starting the open source project at the same time as the company, and why they did it that wayThe relationship between the user community and the customer communityBoxyHQ as the anti-platform — instead of trying to build a platform, which is the default goal for a lot of companies I speak with — they are explicitly trying to build a more a la carte experience for usersThe challenges of community building around a project that isn’t sexy and how to build community that isn’t project-focused, but rather that’s focused around a problem spaceMaking the mistake of assuming your startup is completely unique and unlike any others! We talked about much more as well, and it’s definitely an episode you should check out.

17 Apr 202435min

Populärt inom Business & ekonomi

badfluence
framgangspodden
varvet
rss-borsens-finest
svd-ledarredaktionen
avanzapodden
lastbilspodden
rss-dagen-med-di
borsmorgon
rss-svart-marknad
fill-or-kill
affarsvarlden
uppgang-och-fall
rss-kort-lang-analyspodden-fran-di
tabberaset
rss-inga-dumma-fragor-om-pengar
rss-en-rik-historia
rss-badfluence
rikatillsammans-om-privatekonomi-rikedom-i-livet
kapitalet-en-podd-om-ekonomi