Navigating the Cloud Native Ecosystem with Harness Evangelist Ravi Lachhman

Navigating the Cloud Native Ecosystem with Harness Evangelist Ravi Lachhman

The conversation covers:


  • An overview of Ravi’s role as an evangelist — an often misunderstood, but important technology enabler.
  • Balancing organizational versus individual needs when making decisions.
  • Some of the core motivations that are driving cloud native migrations today.
  • Why Ravi believes it in empowering engineers to make business decisions.
  • Some of the top misconceptions about cloud native. Ravi also provides his own definition of cloud native.
  • How cloud native architectures are forcing developers to “shift left.”


Links


Transcript


Emily: Hi everyone. I’m Emily Omier, your host, and my day job is helping companies position themselves in the cloud-native ecosystem so that their product’s value is obvious to end-users. I started this podcast because organizations embark on the cloud naive journey for business reasons, but in general, the industry doesn’t talk about them. Instead, we talk a lot about technical reasons. I’m hoping that with this podcast, we focus more on the business goals and business motivations that lead organizations to adopt cloud-native and Kubernetes. I hope you’ll join me.



Welcome to The Business of Cloud Native, I am your host Emily Omier. And today I'm chatting with Ravi Lachhman. Ravi, I want to always start out with, first of all, saying thank you—



Ravi: Sure, excited to be here.



Emily: —and second of all, I like to have you introduce yourself, in your own words. What do you do? Where do you work?



Ravi: Yes, sure. I'm an evangelist for Harness. So, what an evangelist does, I focus on the ecosystem, and I always like the joke, I marry people with software because when people think of evangelists, they think of a televangelist. Or at least that’s what I told my mother and she believes me still. I focus on the ecosystem Harness plays in. And so, Harness is a continuous delivery as a service company. So, what that means, all of the confidence-building steps that you need to get software into production, such as approvals, test orchestration, Harness, how to do that with lots of convention, and as a service.



Emily: So, when you start your day, walk me through what you're actually doing on a typical day?



Ravi: a typical day—dude, I wish there was a typical day because we wear so many hats as a start-up here, but kind of a typical day for me and a typical day for my team, I ended up reading a lot. I probably read about two hours a day, at least during the business day. Now, for some people that might not be a lot, but for me, that's a lot. So, I'll usually catch up with a lot of technology news and news in general. They kind of see how certain things are playing out.



So, a big fan of The New Stack big fan of InfoQ. I also like reading Hacker News for more emotional reading. The big orange angry site, I call Hacker News. And then really just interacting with the community and teams at large. So, I'm the person I used to make fun of, you know, quote-unquote, “thought leader.” I used to not understand what they do, then I became one that was like, “Oh, boy.” [laughs].



And so just providing guidance for some of our field teams, some of the marketing teams around the cloud-native ecosystem, what I'm seeing, what I'm hearing, my opinion on it. And that's pretty much it. And I get to do fun stuff like this, talking on podcasts, always excited to talk to folks and talk to the public. And then kind of just a mix of, say, making some sort of demos, or writing scaffolding code, just exploring new technologies. I'm pretty fortunate in my day to day activities.



Emily: And tell me a little bit more about marrying people with software. Are you the matchmaker? Are you the priest, what role?



Ravi: I can play all parts of the marrying lifecycle. Sometimes I'm the groom, sometimes I’m the priest. But I'm really helping folks make technical decisions. So, it’s go a joke because I get the opportunity to take a look at a wide swath of technology. And so just helping folks make technical decisions. Oh, is this new technology hot? Does this technology make sense? Does this project fatality? What do you think? I just play, kind of, masters of ceremony on folks who are making technology decisions.



Emily: What are some common decisions that you help people with, and common questions that they have?



Ravi: Lot of times it comes around common questions about technology. It's always finding rationale. Why are you leveraging a certain piece of technology? The ‘why’ question is always important. Let's say that you're a forward-thinking engineer or a forward-thinking technology leader.



They also read a lot, and so if they come across, let's say a new hot technology, or if they're on Twitter, seeing, yeah, this particular project’s getting a lot of retweets, or they go in GitHub and see oh, this project has little stars, or forks. What does that mean? So, part of my role when talking to people is actually to kind of help slow that roll down, saying, “Hey, what’s the business rationale behind you making a change? Why do you actually want to go about leveraging a certain, let's say, technology?”



I’m just taking more of a generic approach, saying, “Hey, what’s the shiny penny today might not be the shiny penny tomorrow.” And also just providing some sort of guidance like, “Hey, let's take a look at project vitality. Let's take a look at some other metrics that projects have, like defect close ratio—you know, how often it's updates happening, what's your security posture?” And so just walking through a more, I would say the non-fun tasks or non-functional tasks, and also looking about how to operationalize something like, “Hey, given you want to make sure you're maintaining innovation, and making sure that you're maintaining business controls, what are some best operational practices?” You know, want to go for gold, or don't boil the ocean, it’s helping people make decisive decisions.



Emily: What do you see as sort of the common threads that connect to the conversations that you have?



Ravi: Yeah, so I think a lot of the common threads are usually like people say, “Oh, we have to have it. We're going to fall behind if you don't use XYZ technology.” And when you really start getting to talking to them, it's like, let’s try to line up some sort of technical debt or business problem that you have, and how about are you going to solve these particular technical challenges? It's something that, of the space I play into, which is ironic, it's the double-edged sword, I call it ‘chasing conference tech.’ So, sometimes people see a really hot project, if my team implements this, I can go speak at a conference about a certain piece of technology.



And it's like, eh, is that a really r...

Jaksot(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 Kesä 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 Touko 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 Touko 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 Touko 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 Touko 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 Touko 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 Huhti 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 Huhti 202435min

Suosittua kategoriassa Liike-elämä ja talous

sijotuskasti
mimmit-sijoittaa
psykopodiaa-podcast
puheenaihe
rss-rahapodi
ostan-asuntoja-podcast
pomojen-suusta
rss-startup-ministerio
rss-lahtijat
rss-rahamania
rahapuhetta
rss-neuvottelija-sami-miettinen
kasvun-kipuja
rss-h-asselmoilanen
rss-turvacast
taloudellinen-mielenrauha
leadcast
syo-nuku-saasta
muutosakatemia-coaching-podcast
lakicast