246 avsnitt • Längd: 30 min • Veckovis: Onsdag
Whether you’re a founder of an open source startup, an open source maintainer or just an open source enthusiast, join host Emily Omier as she talks to the people who work at the intersection of open source and business, from startup founders to leaders of open source giants and all the people who help open source startups grow.
The podcast The Business of Open Source is created by Emily Omier. The podcast and the artwork on this page are embedded on this page using the public podcast feed (RSS).
This week on The Business of Open Source, I spoke with John O’Nolan, the co-founder of ghost.org. Before further ado, John is going to be one of speakers at Open Source Founders Summit 2025, so if you’d like a chance to dive deeper into any of the subjects we talked about on the podcast with him, in person, you should join us in May.
There’s a lot of interesting tidbits to pull out from this conversation. First of all, I think it’s interesting that Ghost came about because Wordpress was moving away from its roots as a pure publishing tool and becoming a website builder. John, who was very involved in the Wordpress community at the time, wondered what it would look like if Wordpress went back to its roots and focused on publishing and only publishing. It’s a lesson for founders that sometimes focusing on the small niches left behind as incumbents expand can be huge opportunity. —> It’s worth noting that we recorded this podcast last fall when the drama between Wordpress and WPEngine was exceptionally hot.
Ghost is organized as a non-profit, and John also talked about why he made that decision from the beginning. It came down to wanting to make a good salary at a company he had started, but without the goal of becoming fabulously wealthy as a result.
We also talked about whether or not a venture-backed company can be ‘responsible’ with respect to their community; and what types of companies tend to be able to manage the tensions between the community needs and the fiduciary duty that you have if you take outside funding.
We also talked about the difference in the market between the product and the project, how Ghost manages to expand in spite of not having a dedicated marketing team.
We also talked about the difference between building a sustainable business and building a business that gets hockey stick very quickly as well as some of the tension between technology decisions and business decisions.
If you want to talk more about these issues — and want to talk directly with John — you should come to Open Source Founders Summit May 19th and 20th, 2025. Get your tickets here.
In the last episode of The Business of Open Source recorded at KubeCon Salt Lake City, I spoke with Omri Gazitt, co-founder and CEO of Aserto.
Aserto has two open source project that it maintains, one of which it donated to the CNCF. In this episode, we talked about the decision to donate a project to the CNCF — both what the process entailed and what is in for Aserto in having a project at the CNCF.
But of course Aserto also has another project, Topaz, which it has not donated to the CNCF. We also talked about why Topaz wasn’t donated to the CNCF.
A couple things to pull out of this conversation:
We talked about the panel I moderated at CloudNative StartupFest at KubeCon. If you missed it, here’s the link to see the replay. We also talked about Adam Jacob’s talk at the same event, which you can see here.
If you’re building a company around an open source project and aren’t sure how to manage the relationship between the project and product, you might want to work with me or come to Open Source Founders Summit this May.
This special episode recorded live at KubeCon Salt Lake City last November is with Martin Mao, CEO and co-founder at Chronosphere.
We talked about how M3 was foundational to the early history of Chronosphere, and how the ability to leverage M3, which Martin and his co-founder had written while they were still working at Uber. One of the most important aspects of this story is that since M3 is the foundation Chronosphere is built on, the fact that it was developed over four years at Uber while they were still on Uber’s payroll meant that when they decided to build a company it allowed them to get to market dramatically faster than would have been possible otherwise.
Chronosphere’s core platform is a proprietary SaaS product, but still has a significant relationship with two other projects: Perses, which was developed at Chronosphere and donated to the CNCF in 2024; and FluentBit, a CNCF graduated project that was originally developed by Calyptia and became part of Chronosphere when it acquired Calyptia.
We talked about:
If you’re building a company around an open source project and aren’t sure how to manage the relationship between the project and product, you might want to work with me or come to Open Source Founders Summit this May.
Happy new year everyone! There was a short break for Christmas + New Years the past two weeks, but this week I’m back with a fabulous episode with Wei Lien Dang, General Partner at Unusual Ventures and formerly co-founder of StackRox. I recorded this episode on-site at KubeCon Salt Lake City back in November 2024.
This episode is particularly fabulous because Wei was willing to give some founder real talk. This is easier once you’ve sold your company, and especially easier when the ‘outcome’ of your company’s trajectory looks like an unmitigated success. And that is precisely why you hear so few founders willing and able to be honest about what the company’s trajectory really looked like — and all the times when things did not look like a chart going up and to the right.
Wei has also written an open source field guide, which is absolutely worth reading and is available here.
We talked a lot about product-market fit, how hard it is to find and how important it is. From the risks from just going to your network for feedback to the difference between general, high-level feedback and a very specific idea of how and why your product is used, Wei talked about both recognizing that you have a product-market fit problem and how to fix it. We also talked about empathy as a founder, recovering from building the wrong product, and managing the hearts and minds of your team.
Are you struggling with product-market fit, or feel like you have project-market fit but can’t translate it into commercial success? You might want to work with me, and / or come to Open Source Founders Summit to chat with other open source founders.
This week on The Business of Open Source, I have a special episode recorded on-site at KubeCon NA this fall, with Ramiro Berrelleza, the CEO of Okteto.
We kicked off the conversation with a discussion about branding. Okteto is the name of the company, the name of the project and the name of the product. We started this conversation because it had been a big part of conversations I had with other founders at KubeCon. Most interesting to me was that while Ramiro explained how that decision was made, he said he was 50% happy with it, 50% not. Which is about the same as what I hear from founders who have made the opposite decision — so maybe there is just no ideal way to approach branding.
Some other things we discussed:
Ramiro and I are on the same wavelength about a couple of things; I particularly appreciated his distinction between users and customers.
We ended the conversation with a discussion of the benefits of open source companies — the opportunities that come from being open source that you can’t get any other way.
Having trouble taking full advantage of your open source project? You might want to work with me, and / or come to Open Source Founders Summit to chat with other open source founders.
This week on the Business of Open Source, I have an episode recorded on-site at KubeCon SLC last month with Cole Kennedy, co-founder of TestifySec. We kicked off the conversation with a discussion about software development practices in the US Department of Defense and the US government at large — and the challenges involved with deploying quickly and frequently when you have to keep things both compliant and security.
Here are some of the take aways from the conversation:
Advertisement time! Are you struggling to figure out how your investment in open source translates to revenue? Do you want to figure how to increase the percentage of users who even know the commercial product exists? You might want to work with me.
And if you are a founder of an open source company, consider coming to Open Source Founders Summit, the only conference dedicated to building financially successful and sustainable open source companies. Attendance is restricted to founders and leadership in open source companies. Check it out here.
Who pays for the future of infrastructure? In this special episode, I spoke to Bobby DeSimone, founder and CEO of Pomerium, about how he feels like infrastructure and security both have to be open source — but then, what does that mean about the future of the financial support for infrastructure and security?
We talked about:
If managing product-project tension is something you’re struggling with, reach out, you might want to work with me.
And if you want more conversations about the unique aspects of open source businesses, you should come to Open Source Founders Summit this May. Join the mailing list to find out as soon as tickets are available.
This week on The Business of Open Source, I spoke with Mark Fussell, CEO and co-founder of Diagrid and co-creator of Dapr, in a special episode recorded on-site at KubeCon NA in Salt Lake City.
We kicked off with a discussion of what’s different about running an open source company versus a proprietary software company, and Mark said that a big part of it is that you have to nurture the community.
But what does that actually mean? I pushed back, and happily Mark was able to go into more specifics about what he means. We also talked about:
###
Are you struggling to figure out how your investment in open source translates to revenue? Do you want to figure how to increase the percentage of users who even know the commercial product exists? You might want to work with me.
In this last special episode of The Business of Open Source recorded at All Things Open, I spoke with Elias Voelker, VP North America for CheckMK. We talked a lot about product strategy; when CheckMK decided that they needed a clear strategy for deciding which feature goes in the open source project and which goes in the commercial version. Elias finished up the conversation by circling back on this issue: As an open source company, if you don't have a big enough difference between the value customers get from project and what they get from the commercial relationship... you won't survive.
Since Elias works in sales, we also talked about sales for open source companies. He said one of the most important questions in the context of open source is “why now?” Since many customers have been using the open source project successfully for years, this question is really important for uncovering what’s changed and why they are ready to buy at the moment.
We also talked about some cultural differences between selling in North America and selling in Germany, since while Elias is German (as is CheckMK), he leads sales in North America and therefore has some advice for European companies moving into the North American market.
###
If you’re struggling to figure out your product strategy as an open source company, you might want to consider working with me. I help open source companies figure out how to differentiated themselves in the market, how to differentiate the product from the project and how to take advantage of the opportunities specific to being to a open source company.
This week on The Business of Open Source, I have the first episode I recorded on-site at KubeCon Salt Lake City (and the only full-length episode), with Solomon Hykes, CEO and co-founder of Dagger, and co-founder of Docker.
One thing Solomon mentions briefly but that is very important is that there are limits to what can be learned from Docker’s story, simply because the situation was so unique. Docker experienced explosive growth, at least some of which was due to having the right technology at the right time. This kind of explosive growth is very rare, though, and it brought it’s own set of challenges. The point being that while most companies will struggle to get enough adoption, Docker struggled to monetize effectively but got so many chances to try again just because it had a massive community.
###
It was fascinating to hear Solomon talk about the lack of intellectual honesty around who pays for the development and maintenance of a lot of open source projects, because that precise topic was the focus of two panels I moderated at KubeCon, one during the main conference and one during CloudNative StartupFest.
If you’re struggling to articulate how your product and project are different from each other (and others in the ecosystem) and why someone should pay you, you might want to work with me. Reach out!
In this special episode of The Business of Open Source, I spoke with Nithya Ruff, director of Amazon’s Open Source Program Office (often referred to as an OSPO). We started out talking a little about what exactly an OSPO is and what they do in companies — something I’m guess not everyone understands.
It boils down to managing the company’s open source strategy — something that is relevant to pretty much any company that writes software of any kind. There are a lot of components to an open source strategy, and there are different ‘models’ for an open source strategy, depending not just on the company’s size, but also whether or not open source is core to what the company sells. Nithya previously led the OSPO at Comcast, and talked a bit about the difference between running an OSPO for the a company like Comcast and a place like AWS, because their products are different.
And why do open source strategies matter for startups? Even if you’re not an open source company, if you can’t prove you’re in compliance with open source licenses for projects you depend on, or if there are security concerns related to your open source use, it can sabotage acquisitions.
By the way, helping startups figure out their open source strategy is what I do as a consultant. If you’re figuring out how to balance your open source project and your product strategy, and how to manage the risks and opportunities associated with open source projects, you might want to work with me.
In this special episode recorded at All Things Open, I talk with Peter Farkas, CEO and co-founder of FerretDB. We talked about about MongoDB and the license change fiasco and why Peter wanted to build an open source company and never considered building a non-open source company.
The biggest 🤯 in this episode was about enforcing what it means to be open source; in particular, FerretDB positions itself as a truly open source alternative to MongoDB, and has received threatening letters from MongoDB as a result. How do you enforce it when a company claims to be open source but does not use an OSI-approved license? How well do the average users actually understand the license implications, and if a big company says they have an open source license even though it’s source-available, not open source, how much will people understand the difference?
If you want another perspective on the enforcement of advertising around open source licenses, listen to the episode I recorded with Stefano Maffulli, also at All Things Open.
This week’s full-length episode is with Bhaskar, founder of YottaDB. This episode was recorded on-site at All Things Open last week, and we covered a wide range of topics. Including:
I’m working with YottaDB right now on how to differentiate themselves in the crowded database market — and we talk about that process a bit right now. If you’re having trouble standing out in a crowded market, you might want to work with me.
This special episode of The Business of Open Source with Tatiana Krupenya, CEO of DBeaver, was recorded on site at All Things Open 2024.
It’s a short conversation, so we addressed one main question: What is the difference between running an open source company versus as proprietary software company? Tatiana says the difference is big — and it’s complicated.
The bottom line: Your OSS can be your main competitor, and your customers have to really see the value in your commercial offering if you want to make sales.
##
If you aren't sure how to talk to your potential customers are about why they should use your commercial offering, you might want to work with me.
This week on The Business of Open Source, I spoke with Stefano Maffulli, Executive Director of the Open Source Initiative, about the definition of open source and… the definition of open source AI. We recorded this episode on-site at All Things Open, so there’s a little bit of background noise.
We talked about why OSI felt like it needed to develop a definition of open source AI, how “open source” is enforced, and the thought process behind the definition that the OSI ultimately published.
We talked about open data quite a bit — different kinds of data, what kind of information and data is important to researchers and professionals in the AI space, and if there’s a way to include AI models that are trained on proprietary data in the definition of open source AI.
If you are interested in open source AI, definitely check out this behind-the-scenes discussion of how, and why, this definition was published — and what the future likely holds for defining open source AI.
This week on The Business of Open Source, I spoke with Anais Concepcion and Paul Fitzpatrick , the co-CEO of Grist Labs and CTO of Grist Labs. We talked about managing growth of users versus growth of revenue, moving to an open source approach for technical, not technical, reasons, and open-source related product management questions for open source companies.
Some really interesting themes we talked about:
Are you struggling with price anchors fixed around zero dollars, or can’t figure out how to manage the push and pull of developing open source and building a business? You might want to work with me.
This week on The Business of Open Source, I spoke with Eric Holscher, co-founder of Read the Docs. We had a really far-ranging conversation that included talking about why documentation is often so bad, why documentation should be a priority, but also Eric’s experience building Read the Docs and Write the Docs. This episode was interesting because it’s both about building an open source company and also about the importance documentation for software projects in general and open source projects.
Some things we covered included:
Are you the founder of an open source company and struggling with figuring out how to manage the relationship between the project and product? You might want to work with me.
Enjoy the show? Help it reach more people by leaving a review and sharing with your friends.
Today on The Business of Open Source, I spoke with Chris Holmes, co-founder and CEO of Greymatter. Greymatter is deeply involved in the open source ecosystem and maintains the Go Envoy Control Plane, but Chris is adamant that it is not an open source company. We had a great discussion about why that is, what it means for the company and the conversations he ends up having around open source with his customers and partner companies.
Some particularly interesting points that came up:
Struggling with how to get your product strategy right, and find the right balance between your open source project and your commercial offering? Not sure how your user audience and customer market relate to each other? You might want to work with me.
This week on the Business of Open Source, I spoke with David Höck, co-founder of Vendure. We talked about switching licenses from MIT to GPL, the ways that Vendure is different from it’s competitors and how architectural decisions can be a powerful differentiator for an open source company.
Favorite quote: “You need to build your product together with your clients.”
Some specifics we talked about that you should pay attention to:
If you’re the founder of an open source company struggling with your product strategy — uncertain how to differentiate between project or product or how to differentiate the entire company in the ecosystem; don’t know what your project is supposed to do for your business; aren’t clear on the target market for your project or product — you might want to work with me. Find out more here.
This week on The Business of Open Source, I talked with Allard Buijze, the CTO and founder at AxonIQ. We talked a lot about the importance of open source for getting feedback on your product and validating your idea — or not.
One of the things we talked about was how the beginning of AxonIQ was tied to the same consultancy that developed Spring Source; Rod Johnson, the founder and CEO of Spring Source was on the podcast a couple months ago and you can listen to that episode here.
We talked about:
***
Are you leading an open source company and struggling with product strategy? I will help you improve the quality of your conversations, so people understand your product sooner, remain more engaged in the conversation and understand the relationship between your product and project. Learn more here.
This week on The Business of Open Source, I spoke with Robert Hodges, CEO of Altinity. This is a great example of an open source company that is built on top of an open source project, ClickHouse, that they did not create and still do not have direct control over. Altinity has created and maintains other open source projects in the ClickHouse ecosystem as well, but
So many things to unpack with this episode, but a couple I want to call attention to in particular.
Are you a leader of an open source company and you’re struggling to prioritize your product roadmap in a way that reinforces your differentiated value… reach out. I help companies figure out the differentiated value of their product and product, where to put the line between the two, and how to use that information to prioritize your roadmap, build a sales narrative and communicate with your market.
This week on The Business of Open Source, I spoke with Jesse Williams and Brad Micklea, co-founders of Jozu and each with a long history of experience in various open source companies behind them. Even though Jozu is young, there was a lot to learn from these two and their experience in both open source and non-open source businesses. We talked about open source and not open source from CodeEnvy, Red Hat, AWS and Docker.
“It’s very hard to get a sustainable open source project if you don’t have a company behind it paying those developers to work on it.”
Some things we talked about:
We wrapped up the conversation talking about how difficult it is to figure out which features to prioritize — and that this is a really hard decision for any startup. This is a big part of my shift to focusing on product strategy in my consulting. If you’re an open source startup struggling with product prioritization and strategy, check out my product strategy offering.
This week on The Business of Open Source, I spoke with Jimmy Zelinskie, co-founder and CPO of Authzed, which is behind SpiceDB.
We kicked off the discussion with a really interesting discussion about whether or not SpiceDB is a database and whether or not Authzed is a database company. At first they didn’t see it that way, but as soon as they started leaning in on describing the product as a database, the more successful they were at getting people in their community to quickly understand what they did and how to use it. But it wasn’t just important for adoption: Once the team realized they were a database company, the business model they should follow seemed obvious, and they could make product decisions without stepping on anyone’s toes.
Some topics we covered:
If you’re the founder of an open source company — or you know anyone who is — and you don’t have a good framework for making product decisions or struggle to communicate internally and externally what the difference between project and product is, I can help you figure that out. Here’s more information.
This week on the Business of Open Source I had Galeal Zino, CEO and founder of NetFoundry, which creates OpenZiti.
One of the most interesting things about the this conversation was the conversation about how to balance whether you’re promoting the product or the project. I talk to a lot of founders who assume that because you have both, you have to promote both. The same goes for SaaS and onprem options — some people think that just because you offer both, you have to build a go to market function for both. This topic came up in the conversation with Joe Duffy as well — in their case, it was the opposite, though. Pulumi started with both open source and commercial product, but put all the emphasis on the open source project for the first two years.
Some of the interesting takeaways from this episode:
Thank you for listening!
PS: I’m changing my consulting offerings slightly, to focus on product strategy instead of positioning. And I’m looking for beta clients while I figure out exactly what the offering looks like. So if you’re an open source company and you’re looking for a clear product vision, a better understanding of how your product + project are differentiated and how to build that into your roadmap, reach out.
Pretix founder and CEO Raphael Michel has a completely different philosophy about what he is building compared to the big players in the event / ticketing platform space. We had a great conversation this week about Pretix, how Pretix is positioned compared to big players, and who care about the fact that Pretix is an open source company.
Some takeaways:
Notice how clear Raphael was about Pretix’s positioning, and how it was different from the big players in the event space. Are you that clear on how your software is different from competitors? Do you have a clear point of view, like Raphael, that sets you apart from the rest of the eocsystem? If not, you might want to work with me.
This week on the The Business of Open Source, I spoke with Ashraf Samhouri, the CEO and co-founder of Activepieces.
Activepieces didn’t start as an open source company — and we started out the conversation by talking about why it was important to take an open source route because Activepieces is building an ecosystem.
Some other highlights from the episode:
If you’re the founder of an open source company and you’re struggling with your open source strategy, with your positioning of your product or project in the ecosystem or with communicating that value of your product and project, reach out — that’s what I help companies with.
This week on The Business of Open Source, I spoke with Per Ploug Krogslund, who is currently senior director of developer programs at Docker, and who previously had a number of experiences at the intersection of open source and business. He founded and ran an open source company, Umbraco, for many years, and also led the Open Source Program Office at Spotify.
We had a wide-ranging conversation about open source businesses. Some of the topics we covered:
What should you take away from this conversation?
If you’re listening and want help on your open source strategy, finding the right balance between open source and income streams and figuring out what those income streams should be, reach out to see if it might be a good fit for us to work together.
This week on The Business of Open Source, I talked with Tom Wilkie, CTO at Grafana Labs. We talked about how he had a 10-month run building a startup before ultimately joining Grafana in an acquisition — why he thought that was the right move at the time and how it’s developed since then. But Tom has also had a long career in open source businesses, and we had plenty to talk about.
My favorite quote: “I’ve always seen open source as a privilege of successful businesses, so I want to be a successful business.”
At Kausal, Tom’s first startup, the focus was on financial sustainability from the beginning, and they had $100k in revenue in 10 months before the acquisition by Grafana. At Grafana Labs, everything is done with an eye on revenue — yes, there are tons of open source projects and tons of investment in those projects, but it has to be tied to revenue.
Some other things we talked about:
Thanks for listening! I’m Emily Omier, a consultant who works with company on open source strategy related to positioning and product management. If you’re struggling with your strategy around open source — whether you’re unsure how to differentiate in the ecosystem or not sure what to open source — I can help. Learn more here.
This week on The Business of Open Source I spoke with Mike Milinkovich, executive director at the Eclipse Foundation. We had a wide-ranging conversation about the role of open source foundations in the open source ecosystem, especially as related to open source businesses.
The existence of open source foundations, and how companies decide to engage (or not) with them, is one of the aspects of open source businesses that is truly unique. Perhaps one of the key things to keep in mind from this conversation is that a foundation’s priority is project sustainability — and that is not always aligned with the goal of increasing profits for a company. On the other hand, there are a lot of advantages to contributing a project to a foundation. But founders should be aware of both the advantages and the constraints that working with a foundation entails.
Here are some of the things that stood out from our conversation:
Listen to the entire episode for even more insights!
This week on The Business of Open Source, I spoke with Vinoth Chandar, the founder and CEO of Onehouse and the creator of Apache Hudi. We took a pretty deep dive into the relationship between Onehouse and Hudi, a topic that for me is at the heart of building a company on top of an open source project. In fact, whether or not Onehouse is an ‘open source company’ could be debatable; Hudi is an Apache project — it’s not owned by Onehouse in anyway — and Onehouse is not a ‘managed Hudi’ or ‘enterprise Hudi.’ Onehouse solves a problem that is fundamentally not the same problem that Hudi solves.
Here’s some other take aways from my conversation with Vinoth:
Check out the full episode for more wisdom from Vinoth!
This week on The Business of Open Source, I spoke with Joe Duffy, co-founder and CEO of Pulumi.
We kicked off the conversation by talking about why Pulumi is open source in the first place — a mix of Joe’s long-standing interest in open source and a feeling like a developer tool like Pulumi just has to be open source in order to be taken seriously. But there was another reason, too: Pulumi’s founders weren’t just in it to build a company, they wanted to transform their industry and build a lasting community, and felt like open source was the best way to do that.
Lots of good take aways in this episode, like:
Listen to the full episode, it has a huge amount of great insights!
This week on The Business of Open Source, I spoke with Tyler Jewell — for the second time, now. Last time I spoke with Tyler, he was an investor at Dell Technologies Capital, he’s since taken over as CEO of Lightbend.
We talked about a lot, but there was a definite theme to our conversation: License changes. Lightbend had been running an open core model, with the open core using a permissive Apache license. The company’s open source project, Akka, is massively popular. Lightben had about $13 million in ARR. But it was spending over $20 million per year, mostly of on R&D and then GTM. And they had a churn problem; and the churn problem was that customers would stop buying Lightbend’s product, but they would stay with Akka, because it was good enough.
Why did this happen? The added proprietary features weren’t valuable enough for companies to pay for, especially in the face of budget cuts. And because the community was quite mature, it often started to duplicate these capabilities. And then the company faced a near-death experience in 2021. At the same time, usage of Akka was only growing, while the company was facing potential bankruptcy. Investors saw the potential and didn’t want to give up on the company, but it was clear to the board of directors that something needed to change — and that the thing that wasn’t working was the business model.
So they changed it.
There’s a couple things I hope people can take away from this.
This summary doesn’t do it full justice, though, so check out the full episode!!
This week on The Business of Open Source I have an episode I recorded on site at AI-Dev in Paris with Justin Cormack, CTO of Docker. We finally get around to talking about AI at the very end of the episode, but otherwise we talked business and open source and how Docker manages both. Here’s some of the take aways from the episode:
We also talked AI and open source, given the event we were at.
This week on The Business of Open Source, I spoke with Karthik Ranganathan, founder and co-CEO of Yugabyte. This is the second time Karthik has been on the podcast, but since three years had passed I thought it’d be a good idea to catch up and see what’s changed at Yugabyte and how his perspective on the open source commercial ecosystem has changed.
Some really cool topics came up in this conversation. For example:
And much more!
This week on The Business of Open Source, I spoke with André Eriksson, founder and CEO at Encore. We talked about how open source develops trust, something I also discussed in the episode I recorded with Reshma Khilnani. For Encore, it’s subtly different, though. In the case of Medplum, open source is a differentiator in a market that’s used to black boxes, for Encore, open source is tablestakes in a market that won’t adopt a completely proprietary software.
We talked about:
Check out the full episode for some serious insights into what’s working and what’s a struggle at Encore.
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:
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.
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:
Definitely check out the full episode for more insights from Tanmai!
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:
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.
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:
Three key takeaways:
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 :).
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:
Come join me at Open Source Founders Summit if you want more conversations about building open source companies!
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:
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.
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:
At 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.
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.
We talked about much more as well, and it’s definitely an episode you should check out.
In the second episode that I recorded on-site at KubeCon EU in Paris, I spoke with Alex Olivier, CPO and co-founder of Cerbos. This was not a general discussion: It was focused on the process that Cerbos went through to figure out pricing.
Here’s what we talked about:
Check out the full episode for more details!
And join us at Open Source Founders Summit for more discussions about the specifics of pricing for open source companies.
This week, I had a dilemma: should I prioritize the episode where I spoke with one of the MariaDB co-founders, in which we discuss setting up a foundation as a way to ensure that the project continues to be open source in the future, no matter what (relevant given the Redis announcement); or should I prioritize the conversation with one of the founders of Sonatype, one of the oldest companies in the software supply chain security space, in which we talk about the xz debacle.
I went with Patrick Backman, general partner at OpenOcean and co-founder of MariaDB, because it’s a little more in my lane. (The conversation with Brian Fox will have to wait for next week!).
One of the main things we discussed was the relationship between the MariaDB foundation and the MariaDB company. Including:
MariaDB was founded by the founders (and some key employees) at MySQL; we also discussed the lessons learned at MySQL that the team then applied at MariaDB. And we talked about customer acquisition, one of the things that Patrick thinks the team had learned at MySQL and therefore had pretty well figured it out at MariaDB.
Patrick’s co-founder Monty Widenius is one of the speakers at Open Source Founders Summit — if you want to go into more details on with the lessons from MySQL and MariaDB, as well as lessons from being an investor at OpenOcean, join us in Paris May 27th and 28th at Open source Founders Summit.
This week on The Business of Open Source, I have an episode recorded on site at KubeCon EU in Paris with William Morgan, CEO of Buoyant. We had a fabulous conversation, which touched on some touchy subjects, including Buoyant’s slightly changing relationship with Linkerd. But we talked about:
Check out the full episode!
This week on The Business of Open Source I talked to Heather Meeker, General Partner of OSS Capital and author of From Project to Profit, How to Build a Business around your Open Source Project. We talked about some things that I entirely agree with, and then there were some points I challenged Heather on — all in all, it was fabulous conversation.
Here’s what we covered:
Check out the episode, and check out more about Heather Meeker here:
This week on The Business of Open Source I spoke with Pranay Prateek, co-founder of SigNoz. Pranay talked about why open source is important to SigNoz's business, why it's super important to deliver value quickly, even for an observability product, and why founders shouldn't think of open source just as a distribution model.
We also covered:
And much more!
And if you’re interested in more discussions of open source businesses, make sure to join us at Open Source Founders Summit this May.
In this special episode to promote Open Source Founders Summit, I went deep with Thomas di Giacomo about how open source companies can position themselves as attractive acquisition targets for strategic buyers.
If you are the founder of an open source company and you have the idea of being acquired even in the back of your mind, this is a must-listen episode. Whether or not you plan to join us May 27th and 28th in Paris, though of course we hope you do join us.
By the way, at OSFS Thomas is going to lead a workshop on the topic of being an acquisition target for open source companies. It will be interactive, which means you can ASK QUESTIONS.
In this podcast episode, he talked about:
And tons more…
If you want the chance to ask Thomas about strategic acquisitions for OSS companies — as well as to talk about sales strategies, lead generation and more — join us at OSFS 24 in Paris this May 27th and 28th. —> Get your invite here.
PS the audio was a little quiet, but so if you’re having trouble hearing turn up the volume, it’s worth it.
This week on The Business of Open Source, I spoke with Zach Wasserman, co-founder and CTO of Fleet. This was a fabulous episode for many reasons, but then again I never do crappy episodes, right?
The first thing I wanted to call your attention to is that Zach talked about how he’s building an open core business because building an open source business is what he wants to do. When his previous company turned away from open source, Zach left to do consulting around OSquery and Fleet (the project). I always like to talk about how companies / founders need a solid reason for building an open source company… and “this is the kind of company I want to build” is a very good reason. (“Everyone else is doing it” on the other hand, is not a good reason). Everyone puts constraints around the type of company the want to build, and as long as you are intentionally about the decisions, there is nothing wrong about this, business-wise.
Second, we talked about the tension that exists between making a great project and still leaving room for a commercial product that people will pay for, and Zach talked through how Fleet uses a buyer-based open core strategy to decide which functionality to put in the enterprise version or in the open core.
We also talked about:
Lastly, Fleet happens to be a former client of mine. You can check out what Mike, Zach’s co-founder, said about working with me here.
And if you’re interested in more conversations like this… but in person!!! you should come to Open Source Founders Summit May 27th and 28th in Paris.
Slightly different The Business of Open Source episode today! I spoke with Patrick McFadin and Mick Semb Wever about the relationship between Apache Cassandra and DataStax — how it was at the beginning and how the relationship has evolved over the years.
We talked about:
— How there was a dynamic around Cassandra where many of the many of the contributors ended up being sucked into the DataStax orbit, simply because it allowed those contributors to work on on Cassandra full-time
— How there can be tensions between different stakeholders simply because everyone involved ultimately has their own interests at heart, and those interests are not always aligned.
— How it is actually hard to really have open discussions about new features, and how often there can be a new feature dropped in a project that clearly had been developed behind closed doors for some time, and sometimes that created tension in the community
— Some open source projects are just too complex to be hobby projects — Cassandra is so complex that you won’t become a code contributor unless you’re working full-time on Cassandra, because that’s the level of skill you need to keep up.
— How the relationship between a company and a project often changes as the technology matures.
— The importance of addressing tensions between company and community head-on, as adults, when they occur — as well as why you need to remember to treat people as humans and remember that they have good days, bad days, goals and interests.
In this episode of the Open Source Founders Podcast, I talked with Frank Karlitschek, CEO and founder of Nextcloud. Frank is going to be talking specifically about lead generation at Open Source Founders Summit, but in this episode we took a slightly wider view and talked about go to market, for open source companies in general and specifically for Frank’s experience at Nextcloud.
A couple other things to pull out as takeaways.
First of all, Frank talks about how he originally planned to target big companies who wanted to keep their data private — but as it turned out, most big companies don’t really care deeply about keeping their data private. On the other hand, the public sector and universities really do care, and those have ended up being a huge part of Nextcloud’s customers.
Frank also talked about the rather obvious differences in needs between home users and big organizations. Nextcloud has some customers with millions of users — their needs are different from a home user. And as far as home users go, Frank says these users are obviously never going to pay Nextcloud anything. On the other hand, they have built mechanisms into the software to nudge open source instances with over 1,000 users to get in touch to talk about a commercial relationship.
He also talked specifically about the importance of really talking with your customers and your users — and incorporating their feedback into your product roadmap. For open source companies, you have so much more information and feedback than proprietary companies, and you should take advantage of that to inform your go to market strategy.
We also talked about how the millions of home users who will never pay Nextcloud are still extremely valuable to the company — and why Frank think it’s really wrong to think of pure open source users as just leads to be converted.
And much, much more.
If you’re the founder or leader at an open source company, and you want to be a part of more discussions like this, join us at Open Source Founders Summit May 27th and 28th in Paris!
This week on The Business of Open Source, I spoke with Percona CEO Ann Schlemmer. This episode was recorded on site at State of Open Con in London, outside in a van!
There’s a ton of great info in this episode, too. First of all, Ann talked about being a ‘suit’ in a geek’s world and her career trajectory that led her to lead Percona. She also set the stage around the constraints that Percona has chosen for itself: To be completely open source and only sell services, and to be completely bootstrapped. And what the ramifications of those decisions are for the business.
Here’s some concrete takeaways:
We also had a bit of a random conversation about controlling status in relationships — the book we talked is Impro: Improvisation and the Theatre. And talked about how founders who are ready to step down as CEO can find a replacement and manage the transition.
Ann’s links:
In this episode of The Business of Open Source, I talked with four-time entrepreneur Mike Schwartz, CEO and founder of Gluu as well as the host of Open Source Underdogs podcast, about his long career in entrepreneurship. Here’s some particularly interesting things to take out of this episode:
This episode was recorded on site at State of Open Con 24, outside in a media van!
As part of the preparation for Open Source Founders Summit, I’m interviewing both our speakers and our attendees for a special podcast that’s hyper focused on one thing. In this episode I spoke with Peter Zaitsev, founder of Percona, about sales. We talked about the specifics of sales as a bootstrapped company — which means sales are exceptionally critical from the beginning, and how sales changed as the company moved from a consulting model to a support model on the open source software that Percona creates.
Also, this episode was recorded on site at OpenUK’s State of Open Con!
Here’s the concrete takeaways from this episode:
If you want more opportunities to go in-depth on sales for open source companies — and to discuss sales and other aspects of business development with other founders, join us May 27th and 28th in Paris at Open Source Founders Summit.
Garima Kapoor, COO and co-founder of MinIO, joins me to share her journey from investor and advisor to co-founder of MinIO and the wealth of knowledge she’s amassed along the way.
In this episode, Garima explains how her experience in finance and belief in the power of open source helped MinIO to break into the data storage market. She also reviews the challenges she faced as a first-time founder and what others can learn from her mistakes and take away from some of their own. Since Garima started her journey with MinIO as CFO, she outlines that role for me and explains how she thinks a CFO should operate in an open source company. In reviewing mistakes she’s seen from other founders, Garima states some principles that create the “foundation for any open source business.” - “You should always be very honest to your community. You should always be very transparent to the community”
Highlights:
Links:
Garima
Today I’m joined by Federico Wengi, who is a Partner at SquareOne VC. In this conversation, Federico sheds light on the conversations he’s had with many companies who consider making the pivot from a closed-source business strategy to an open-source strategy. Federico explains why it’s so uncommon for businesses to make that pivot, and lays out the challenges businesses face when they consider taking on such a change. Federico also gives a great example of a company that did successfully complete the pivot to open source, and the choices they made that led to their success. Federico and I discuss why this is one pivot you can’t take back, and also why it won’t solve all your problems. Despite all that, Federico shares his optimism for the value of open source and the importance of at least considering this strategy when you need to make a change.
Highlights:
Links:
Federico
How can we get founders of open source companies together to share ideas, share strategies and tactics and build a community not just of open source practitioners, but of open source business owners? We create a conference/summit/retreat to bring them together to learn and to work on their businesses together. At least that is the bet that Remy Bertot and I are making
In this episode, I talked with Remy about Open Source Founders Summit, a summit they're organizing on May 27th and 28th, 2024 in Paris, France — we each shared our motivations for organizing the event, and talked about why we think it's important for people to come together in person.
You should listen to the episode, but if you don't want to, the bottom line is that we think there needs to be a space for all open source founders (not just the DevTools, not just the VC-backed) can come together to share business ideas — a place where business, not tech, is the focus.
Listen to the episode, and join us in May!
Ben Haynes, the Founder and CEO of Directus, created an open-source project while working at his own agency in 2004. In this episode, we explore how he went from maintaining an open-source project to building an open-source company with a solid product-led growth strategy, and how he’s achieved success in the enterprise segment even as a small organization. Ben expands on how he feels open-source is the best way to start a business, and also reveals why timing and transparency can be both your greatest assets and the areas where you have the most regrets if not done right. We also discuss the value of optimizing you product and business for working with government agencies as an open-source company.
Highlights:
Links:
Ben
Peer Richelsen is the Co-founder of Cal.com, an open-source calendar scheduling tool. This week, Peer and I discuss his personal experience with needing a customizable scheduling tool, the big leap from taking donations to running a profitable business, and the thought process behind seeking VC funding. Peer also talks about the major advantage of starting with only a paid version of the product in order to build a small community of super users. Lastly, I pick Peer’s brain about how he feels being constantly compared to non open-source scheduling products.
Highlights:
Links:
Peer
Birthe Lindenthal is the Co-founder and CMO of OpenProject, a web-based project management system. On this episode, Birthe and I discuss the inception of the company, how being open source directly benefits both the business and its customers, and why the connection to their community is so strong. Plus, Birthe talks about the motivation she feels when contributing to something larger than herself, including the joy of knowing NGOs use her product for free. We also discuss the unique challenges of marketing an open-source product.
Highlights:
Links:
Birthe
Didier Lopes, Co-founder and CEO of OpenBB, joins me to share the story of how OpenBB went from receiving 4000 GitHub stars in the first 24 hours of the project to a fully funded company launching new monetization initiatives.
Didier and I chat about his background, what led him to start OpenBB in his spare time, and his vision for the company's future. He shares the story of teaming up with his co-founder, why he loves working in the open source ecosystem, and how his team continues contributing to OpenBB's success.
Highlights:
Links:
Didier
Loris Degioanni is the CEO and Founder of Sysdig, an open-source company working to make cloud deployment more secure through the use of runtime insights. Loris and I sit down to discuss the bet Sysdig is making to position itself as a leader in cloud security, how Loris leverages the power of a useful tool to create a brand, and the framework he uses to decide what should be open source and what should be paid for. Loris also shares an in-depth history of his previous company, Wireshark, and his excitement for building open source projects that outlast their business and creators.
Highlights:
Links:
Loris
Bob van Luijt is the CEO and Founder of Weaviate, an open-source vector database company that helps contribute to the advancement of AI technology. Throughout this episode, Bob and I discuss the complexities of moving from an open-source project to building an open-source company, and the challenges that come with monetization strategies. Bob shares insightful anecdotes around why it’s important to be careful that you’re measuring the right things for the right reasons, and also emphasizes the importance of determining the best approach to profitability.
Highlights:
Links:
Bob
Ben Rometsch is the CEO and Founder of Flagsmith, an open-source feature flagging platform. In this conversation, we explore how he landed on the idea to develop an open-source feature flagging project and how that has snowballed into running a full-time SaaS company. Ben describes the challenges of creating a SaaS company from the ground up, especially when it comes to pricing and monetizing. We also discuss the importance of understanding and choosing the right licensing for your product.
Highlights:
Links:
Ben
Max Howell is the CEO of Tea, a revolutionary open-source project that is seeking to help open-source contributors get paid for their work through crypto. Throughout our conversation, Max explains how he’s created some prolific open-source projects but was still unable to monetize them to the point where open source could be his full-time job, and how that provided the inspiration for Tea. Max and I discuss the importance of re-framing open-source projects in business terms of value, and not simply referring to supporting projects as charity work, and Max also shares valuable insights into the world of open-source crypto development.
Highlights:
Links:
Max
Nicolas Höning is the Co-Founder and CEO of Seita, an open-source energy optimization and digitalization company. Nicolas took an unconventional path to founding an open-source startup, and throughout this episode he describes how creating a greener world through open-source software is more than a business endeavor for him - it’s a personal mission. Nicolas describes perfectly the challenges that open-source founders face, and is transparent on the decisions he’s still weighing when it comes to choosing an open-source product model and the benefits and challenges of being a boot-strapped startup. I was particularly interested to learn how his company’s project, V2G Liberty, helps individuals who are looking for a greener way to optimize the charging of their electric vehicles, and why Nicolas doesn’t market his other products to individual users.
Highlights:
Links:
Nicolas
Jono Bacon’s passion for building communities has been a driving force in a career taken him from Canonical to GitHub to founding the Community Leadership Core community accelerator. In this episode, Jono shares his definition of community, how a community can create a movement and the differences between the two. We also get a bit of insight into how he developed his passion for building communities and why he continues helping companies build and support theirs through the Community Leadership Core. When Jono speaks about communities he is involved with, he uses “we” instead of “I” to describe their achievements, so I had him dig into that a bit more as we explored the power dynamics that have a huge influence on the success of a community or movement.
Highlights:
Links:
Jono
Michael Cheng is an M&A Specialist who has had an extensive career that includes a former stint at Facebook as a Product Manager and his current role as a Lawyer. In this episode, Michael returns to the show to have an in-depth discussion around acquisitions. Michael shares his thoughts on why most acquisitions leave everyone involved feeling unsatisfied, and what he thinks should be done by both parties to mitigate the high failure rate of acquisitions. We also chat about the common grievances founders have after going through an acquisition, and the approach Michael recommends to mitigate those regrets. Michael also shares insights on why it’s harder on an open-source company to be successfully acquired if they are in between being a purely services-based or SaaS company.
Highlights:
Links:
Michael
Lars Kamp is the Co-Founder and CEO of Some Engineering, the makers of Resoto. In this episode, Lars describes what he’s learned from founding and working at multiple start-ups, as well as the main differentiators he’s experienced founding his first open-source startup. Lars describes his though process when it comes to selecting co-founders, and illustrates why it’s even more important to be discerning when selecting investors. Lars and I also discuss the advantages that open-source gives to founders who are focused on the distribution strategy for their product, and Lars reveals why he is a big proponent of having docs be a part of your product-led growth strategy. Throughout our conversation, Lars’ insights create a detailed picture of what second-time founders think about and how SaaS startup experience relates to open-source business strategy.
Highlights:
Links:
Lars
Amanda “Robby” Robson is a Partner at Cowboy Ventures and the co-host of the Open Source Startup Podcast. In this episode, Robby shares insights on what she’s looking for in open-source founders to potentially invest in, including the importance of being able to manage both your community and your paid model simultaneously. Robby and I also discuss the importance and pitfalls of choosing a monetization strategy, as well as the dangers of having too many monetization models too soon. Throughout our conversation, Robby highlights the specific challenges that open-source founders face, and how she’s seen successful founders either avoid or overcome them.
Highlights:
Links:
Robby
Daniel Izquierdo is the Co-Founder and CEO at Bitergia, an open-source company that provides software development data and analytics. In this episode, we connect at the Open Source Summit in Bilbao to discuss how he went from working in academia to co-founding an open-source company. Throughout our conversation, Daniel shares interesting anecdotes on the unique journey he’s taken to build Bitergia, including why they haven’t focused on growing fast so much as they have focused on growing in a way that supports their employees and customers. He also shares insights into how to measure an open-source community, and the knowledge gaps that he sees in people who can’t contextualize the data they’re getting on their community. Daniel also walks us through the other open-source business models Bitergia tried before discovering what worked for them.
Highlights:
Links:
Daniel
Leszek Manicki is the Engineering Manager at Wikimedia Germany. In this episode, we connect at the Open Source Summit in Bilbao to discuss what he has learned being a part of Wikimedia movement and how that inspired his talk at the summit, How Not To Make Open Source. Throughout our conversation, Leszek describes the challenges Wikimedia has experienced in trying to get more contributors to their projects while also having a high security standard and a complex architecture. He also describes what he has learned from these challenges, and gives recommendations for other organizations to consider as they look to get more contributors to their own projects. Leszek also shares his experience representing a non-profit organization that seeks to offer free knowledge at an event that features more commercialized open-source offerings, and how he hopes this will bring about a positive socio-economic change.
Highlights:
Links:
Leszek
Brian Proffitt is the Senior Manager of Community Outreach at Red Hat’s OSPO. In this episode, we connect at the Open Source Summit EU to discuss how Brian uses events to drive both lead generation and community-building efforts. Throughout our conversation, Brian describes how measuring the ROI of an event can be tricky and why it’s important to look at events as a long game strategy. We also discuss why events provide some of the most valuable feedback when testing your positioning and messaging, and what can be done to increase the odds that your events are successful and produce good outcomes.
Highlights:
Links:
Brian
Kim McMahon is the leader of Open Source Marketing & Community at Outshift by Cisco, which is Cisco’s emerging technologies and innovation unit. We recorded this episode at Open Source Summit EU, and talked about Kim’s strategies and tactics related to helping guide users to the correct edition of your product — ie, decide whether the open source option or a commercial option is best for them.
Kim talked about the tricky balance open-source companies must strike between embracing open-source principles and driving revenue as a business, Kim’s tactics for community building and why it’s so important to be clear on why you want to build a community and the outcomes you expect from your investment in community building.
Highlights:
Links:
Kim
Alexander Krüger is the Co-Founder and CEO of United Manufacturing Hub, an open-source company that develops software for the manufacturing industry. Throughout our conversation, Alexander describes the unusual path he took in going from a services-based consulting company to a product-led company. He also describes the opportunities and challenges of selling open-source software to an industry that has historically been slow to adopt new technology, as well as his choice to hone a go-to-market strategy before exploring fundraising.
Highlights:
Links:
Alexander
This week I’m chatting with Steven Renwick, CEO of Tilores. As you’ll hear in the episode, we connected when I mistook Tilores for an open-source company. Steven graciously agreed to come on the show to discuss why they decided against making the product open source — which is actually a conversation worth having, and one that open source founders should probably have more often.
There are a few options for companies building SaaS tools to solve problems for engineers and enterprises, from open source and open core all the way to completely closed source. In this episode, Steven and I discuss some of these options and why his company decided that going closed source would be the option that provided them the greatest opportunity for growth. Steven himself thought they would start the company as an open-source company, but upon further examination, realized they weren’t leaning in that direction for the right reasons. Listen to hear the journey from the beginning of their search for funding, to heading into the end of their second year in business as a closed-source company.
Highlights:
Links:
Steven
Philippe Humeau is the CEO and Co-Founder of CrowdSec, an open-source security company with a very unique business model that doesn’t fit the usual open source patterns. Philippe talked about how to focus on providing a fair exchange of value between maintainers / open source companies and users, and how to monetize a project that is providing value for free.
Philippe also talked about why he thinks open-source founders are under more pressure to get their business model right at the start, tips on making the right hiring decisions, and how to communicate with the community in an effective and transparent way. I also liked Philippe’s cynicism: why he views open source as primarily a pragmatic choice for his business, given the type of company he wanted to build.
Philippe also shares the logic behind his uncommon view that only making certain features available to paying customers isn’t a truly open-source business strategy.
Highlights:
Links:
Philippe
Samuel Stroschein is the CEO and Founder of inlang, an open-source company that is looking to not only make localization easy for developers, but also to help companies achieve revenue growth through localization.
I was particularly excited to talk to Samuel because, back in my way back past, I was a translator, so I’m always interested in solutions that exist to facilitate translation; but also because localizing software is a good example of the intersection between business problems and technical problems. Inlang also strikes me as a company that could see its primary market as developers, or could see its market as CMOs — because of the way localization is both a technical and business problem. And Samuel is clear about this: He says “What we're basically saying is if you want to make more money, you've got to localize.”
Lastly, another thing that stuck out to me about our conversation was that, as we talked about Inlang’s future monetization strategy, Samuel said he thinks that it will likely be around services — which I hadn’t heard from anyone before. His reason: That the software will ultimately become commoditized.
Listen in to learn why localization is such a challenge for developers, what impact it has on revenue growth, and how Samuel took inlang from an open-source project to an open-source company.
Highlights:
Links:
Samuel
Kevin Muller is the CEO and co-founder of Passbolt, a security-first, open-source password manager, and he joined me to talk about the risks of having too much time and money, the value of getting trashed on social media and why he values in-person interactions with the team.
There were a lot of interesting pieces to pick apart from this episode. First of all, Kevin talked about the importance of not commercializing too early. I think he's the only founder I've ever heard say something along those lines, but he makes a good argument. (Also, Tim Chen and I talked about the timing of commercialization last week, my takeaway is that no one feels like they commercialized at precisely the right moment). Second, we had a good discussion about how the different priorities of European versus American investors can push companies to make different decisions. The subtext that we didn't address directly is make sure you are aware that your investors priorities are going to influence how your company evolves, choose your investors with that in mind. (and check out the episode with Markus Düttmann if you want more on the EU vs US investment environment for open source startups). Lastly, password managers have been in the news, and not in a good way — and how to best react to a super embarrassing situation for a competitor is not always obvious. So we talked about how Passbolt has tried to steer the conversation about password management in light of recent high-profile hacks in the ecosystem.
Highlights:
Links:
Tim Chen is a Partner at Essence VC and also the Co-Host of the Open Source Startup Podcast. Through these channels, he has the opportunity to speak with a broad variety of open source startups. Throughout our conversation, we explore the patterns that Tim sees in the open source startup space. Tim talked about how too many founders take the decision to build an open source company too lightly and the path that he would take if he were to start a venture-backed open source startup tomorrow. We also discuss the different monetization models of open-source startups and the true business value of an open source project.
Highlights:
Links:
Tim
Franz Karlsberger is the CEO of Amazee.io, an open-source platform that seeks to make developers’ lives easier by abstracting their day-to-day workload. Throughout our conversation, we explore what it means to join an open-source start-up as an external CEO, and why Franz put so much emphasis on go-to-market strategy. Franz also walks through the importance of knowing what open-source business model your company will follow, and how to measure the success of an open-source project.
Listen in as Franz shares some of his most interesting mistakes, what he’d do differently if he could start over, and why Franz feels open-source is more than just a type of software, it’s a company ethos that affects everything down to the team culture.
Highlights:
Links:
Franz
It’s kind of a cliche, Vlad A. Ionescu, founder and CEO of Earthly, says, but his first attempts to build something really awesome focused on amazing technology. With hindsight, he doesn’t think it’s so surprising that those efforts weren’t successful. It’s not that passion doesn’t matter, but rather that he had to learn to build things that inspired passion from both the market and the builders. We also talked about:
I also really liked his ideas about cutting corners — that startups will always have to cut some corners, it’s just up to you to decide which ones to cut.
Highlights:
Links:
Vlad
Markus Düttmann, a former Principal at Nauta Capital, is steeped in the European open source scene. From his beginnings in theoretical physics, Düttmann’s hard pivot into venture capital funding granted him a spot in the developing tech world as a connoisseur of the culture and a champion for start-ups. He even contributed to Nauta Capital’s European Open Source Report detailing the state of the ecosystem as of October 2022.
On this episode of the Business of Open Source, listen to his insight into the European markets, the various business models generally used for open source start-ups, and what he looks for in an open source start-up.
Note: Markus has since left Nauta and is on paternity leave. He also asked me to add a follow-up to the episode: After thinking more about the biggest danger to open source companies, he thinks most of them will fail from problems like not building the right team, failure to find product market fit and/or failure to monetize. Hyperscalers are a danger, but probably won’t be what causes most startups to fail.
Highlights:
Links:
Markus
This week Shanea Leven, CEO and Co-Founder of CodeSee, joins me to chat about demystifying code bases and building an effective team.
In this episode of The Business of Open Source, Shanea and I discuss the origins of her company, CodeSee, how it morphed from a training course to a SaaS product, and how they contribute to open source even though CodeSee is not an open source company. Shanea also shares valuable insight into working closely with your spouse, the importance of communication and empathy in building an effective team, and how she’s evolved as a leader. Listen to hear all of her insight and advice, and find out how the CodeSee SaaS offering helps companies understand their code bases and make critical decisions faster.
Highlights:
Links:
Shanea
This week Heikki Nousiainen, CTO and Co-founder of Aiven, joins me to chat about building the business, his passion for open source and entrepreneurship, and his hopes for the future of open source in the public sector.
In this episode, Heikki and I explore the successes and challenges he and his three co-founders encountered in creating and maintaining their global open source data platform. We discuss how they choose technologies to support, the importance of customer demand, how founders can learn to work together, and when to “kill your darlings.”
Highlights:
Links:
Heikki
Michael Cheng, Chief Legal Officer at Aalyria Technologies, is a master at strategy and execution for open-source products and companies. From his humble beginning spearheading the open source team at Meta (formerly Facebook), Cheng has honed his knowledge about the interworking of open source and utilizes it to its fullest potential.
In this episode of The Business of Open Source, Cheng talks about his time as Meta's lead in open source as well as what it's like to be an individual working for a large company. He also explains what happens in mergers and acquisitions with open source projects and the legality of being a small fish in a large pond!
Highlights:
Links:
Michael
Are you struggling to find a co-founder? Having trouble navigating a relationship with your partners? These are all questions Tanis Jorge, CEO of The Co-founder's Hub, tackles daily in her work. A serial tech entrepreneur and a leading entrepreneur advisor, it is no wonder Jorge has founded and built many businesses, such as Trulioo and IQuiri Inc.
On this episode of The Business Of Open Source, I ask Jorge about finding the right co-founder, why legal frameworks are so important, and the hi's and lows of collaboration. We also discuss warning signs, life stages, and why everyone is a janitor!
Highlights:
Links:
Tanis
From college dropout to developer efficiency guru, Kyle Campbell knows his way around workflow integrations for software companies. He is a fierce proponent of efficient workflows and hopes to spread his experience to any company that can benefit from it.
In this episode of the Business of Open Source, Campbell discusses the origins of his Company CTO.ai, its revenue model, and why he created this AI companion for developers. He also talks about being a consultant, running a start up, and when it is time to shift gears to building a revenue-focused company.
Highlights:
Links:
Kyle
Matt Butcher is no stranger to the ways of ethical philosophy. With a Ph.D. in Religion and Computer Science, he enjoys philosophical conversations of ethical dilemmas. Butcher passionately debates wild theories and paradoxical situations against those not afraid to question reality in pursuit of knowledge.
In this episode of The Business of Open Source, Hear how Butcher discusses ethics in the open source world, the grey areas in being an ethical company, and the moral nature of work/life balance. Butcher also details how some of the greatest philosophical minds shaped his own view of ethics and the pursuit of "that middle road."
Highlights:
Links:
Matt
Dawn Foster, Director of Open Source Community Strategy at VMware, is a champion of community strategy and development. A doctor of Philosophy, Foster is well-versed in the understanding of collaboration and leverages her mountain of knowledge to fight for the health of maintainers in open-source projects.
In this episode of The Business of Open Source, Dawn Foster joins me from the Open Source Summit North America to tackle community strategy and contribution growth methods. Foster also touches on the differences between open contributions and what project leads should do to help grow their maintainers.
Highlights:
Links:
Dawn
Bart Farrell is a content creator and community leader in the public speaking world. Based in Spain, he has developed a massively popular platform through podcasting and consulting as a nontechnical person in a technical space.
In this episode, Farrell breaks down the ins and outs of public speaking. He also discusses the art form of speaking offline rather than online, what to expect when talking to an audience, and what it takes to deliver the gift of gab. Farrell also goes into his struggles in becoming a public speaker and his favorite influence on his craft—all this and more in this episode of The Business of Open Source.
Highlights:
Links:
Bart
Ivar Østhus, The CTO and creator of Unleashed, is a revolutionary in shipping feature management tools and rollouts for companies worldwide. Through hardships, Østhus came into his own in the open source world by relieving the pressure on developers bringing new creations to light in their projects.
On this episode of The Business of Open Source, Hear how Østhus discusses the inception of Unleashed and the struggles he overcame in the early stages. He also talks about being a European company in the tech industry and why he prefers to be called a "Creator" rather than a Founder.
Highlights:
Links:
Ivar
Josh Koenig, Chief Strategy Officer and Co-Founder of Pantheon, is a WebOps aficionado focused on creating first-class platforms and delivering results. Recognized as a Top 25 Software Products Executive by The Software Report, it is no wonder he is passionate about his ability to discuss and understand the developer experience while fostering relationships with users.
On this episode of the Business of Open Source, Koenig discusses the art of fostering opposing community relations and his ideals of the developer experience. He also talks about the niche that is WebOps and his journey of creating Pantheon.
Highlights:
Links:
Josh
Daniel Loreto, the founder of Jetpack.io, is a massive believer in transforming how engineers scale their backend for cloud-based platforms. Deeply rooted in the tech industry, Loretto takes great pride in building tools to large usage scales and utilizing them to attend to the needs of his users and community.
On this episode of the Business of Open Source, Hear about the inner workings of jetpack.io and its challenges in its history. Also, listen to Loreto's tips for success for a startup, his navigation of open source and proprietary coding, and why Loreto is not an open source purist.
Highlights:
"Fueling a culture of openness in innovation and research." That slogan is well known to Abigail Cabunoc Mayes, a leader in GitHub's open-source maintainer program. With a background in open science, Mayes felt right at home when jumping to open source and mentoring many developers at the Cloud-based Hosting service.
On this episode of The Business of Open Source, listen to Mayes speak on sustainability and resilience in building a platform for developers and what makes a robust and sustainable environment. Mayes also talks about financial stability and models in the open source world and what it truly means to break from a main backer and build on your own.
Highlights:
Links:
Abigail
Akriti Dokania, a heavyweight in the venture capital business, is a partner at Ridge Ventures. With a background in computer sciences and building a B2B company from the ground up, it is no wonder Dokania is an expert in the complexities of developing software and understanding the lifecycle of a start-up.
On this week's episodes of the Business of Open Source, Dokania shows her wealth of knowledge in investing in open source start-ups. She also explains what founders should look for in an investor and the struggles of monetization for an open source start-up. Lastly, Dokania gives the secrets to working towards a revenue model and scaling a start-up to a fully fleshed-out company.
Highlights:
Links:
Akriti
Stefan Avram, Co-Founder and Head of Growth at WunderGraph, is taking the open source world by storm. With his company specializing in full stack and workflows through API composition, it is no wonder he has fostered a vast community of developers around WunderGraph.
On today's episode, Avram delves into the story and creation of WunderGraph. He also recounts how he organized a massive discord community to foster healthy feedback for growth. Lastly, Avram speaks on the hardships of building a start-up company and what it takes to flourish—all this and more on this episode of The Business of Open Source.
Highlights:
Links:
Stefan
Emre Baran is a man on a mission to simplify authorization protocols for software developers. With his company Cerbos, Baran has put in years of dedication to easy authorization and helping build the authorization databases of over one hundred EU companies.
In this episode of The Business of Open Source, Emre Baran goes through the history of his company Cerbos. He also talks about telemetry challenges, monetization strategies, and the challenges that made him who he is today. Find out more in this episode!
Highlights:
Links:
Emre
Tyler Jewell is an enterprise technology investor and managing director of Dell Technologies Capital, with a hand in many open source companies. A returning guest to the podcast, Jewell shares with us his foresight and knowledge about the past and current history of the open source landscape.
Hear about the inner workings of Lightbend and how far Akka open source projects have evolved over the years. Also, listen to Jewell discuss business strategy for open source companies and the common mistakes of running open source. Jewell also shares a little about the resiliency of open source businesses in the economic market.
Highlights:
Links:
Tyler
From software engineer to leading developer products at Facebook, Ron Efroni was familiar with the challenges facing developers. His co-founder recognized the power of Nix to remove the boundaries of development, and together they started Flox to reduce the barriers to the adoption of Nix.
In our final episode from the State of Open Con in London, Ron Efroni, CEO and Co-founder of Flox, joins me to discuss the future of Flox and Nix, the amazing community that keeps Nix moving forward, and advice for his former self as well as anyone interested in building an open source company.
Highlights:
Links:
Ron
Sometimes it seems like our devices can read our minds. While that can occasionally be helpful, it can raise concerns about how much of our personal data is collected. Gael Duval, CEO of Murena, noticed this issue in 2017 and has been working on solutions ever since.
In this episode, Gael joins me at the State of Open Con in London to discuss the origins of Murena and how you can protect your data. He also shares lessons he’s learned as an entrepreneur and advice for aspiring founders in the open source space. Listen to hear his unique perspective as an open source B2C founder.
Highlights:
Links:
Gael
Peter Zaitzev, the founder of Percona, is an expert on open source strategy and database optimization. With his level of experience in the world of open source, Peter enjoys challenging himself and going against the grain in order to come out on top.
On this episode of The Business of Open Source, Peter breaks down his thought process on how he approaches open source for businesses as a consultant and dives into the inner workings of Percona from how they generate revenue to customer retention. We also discuss how anyone new to the space can get into open source and make a career out of it.
Highlights:
Links:
Peter
Frank Karlitschek has worked in the open source software space since the late 90s when he contributed to KDE. Since then, he’s managed multiple teams and start ups and used his influence to make the internet a better, more secure place.
In this episode, Frank joins me at The State of Open Con to share his passion for open source and improving the internet. We discuss his early involvement in open source and how he started his own company. He also shares advice for new founders and encouragement for anyone hoping to make a positive impact on the world.
Highlights:
Links:
Frank
Matt Barker, President and co-founder of Jetstack, has been involved in open source and Kubernetes since the early days of its development. With a long list of open source projects behind him, he decided to hone in on Jestack and with its success, share the knowledge he’s gained over the years as an OpenUK Entrepreneur in Residence.
In this episode of The Business of Open Source, Matt joins me from the State of Open Con and shares his initial vision for Jestack and reviews the projects that helped him get the company to where it is today. As Jestack is a fully bootstrapped company, Matt shares his perspective on how that impacts a founder’s decisions. We also discuss the importance of sharing your knowledge with the next generation of founders through mentorship as Matt does with OpenUK.
Highlights:
Links:
Matt
In the first of my series of interviews from the State of Open Con in London, I’m chatting with Rob Taylor, CEO of ChipFlow, about the intersection between open source software design and hardware design, bringing community into the hardware space, and how geopolitics could shape the future of open source.
In this episode, Rob shares his fascinating hardware and software design background, including his first job working on lighting desks for theaters. Then we delve into his other companies before discovering the impetus for starting ChipFlow, how and why they do what they do, and some plans for the future. We also chat briefly about monetization, touch on the impact geopolitics could have on tech, and share our favorite parts of conferences like the State of Open Con.
Highlights:
Links:
Rob
Josh Thurman, Co-founder and Head of DevRel at Uffizzi, joins me to chat about his journey from Navy Seal to tech startup Co-founder.
In this episode, Josh and I discuss his background as a Navy Seal, how he dove into tech and started Uffizzi, and the mistakes and failures he overcame along the way. We also dig into open source as a development model, creating vs. capturing value, and the importance of compatibility with software users are already implementing. Listen to find out what Josh considers his biggest failure, how he and Uffizzi overcame it, and how companies are using the product now.
Highlights:
Links:
Josh
Nikhil Nandagopal, Founder and CPO of Appsmith, joins me to chat about building trust, the importance of starting as an open source offering, and how the community continues to shape the future of Appsmith.
In this episode, Nikhil and I discuss the origins of Appsmith, building a business edition as well as a community one, and the challenges he and his team encountered along the way. We compare the community and business editions, discuss the importance of community and an educational, product-led approach to marketing, and even touch on the stigma of the “low code” label with which Appsmith has chosen to align. Listen to learn Nikhil’s views and insight on open source, community, education, developer relations, and more.
Highlights:
Links:
Nikhil
Adi Gelvan, Co-founder and CEO of Speedb, joins me to share his experience in moving Speedb from a closed source proprietary company to open source with an enterprise offering.
In this episode, Adi and I explore moving from a proprietary to an open source strategy. From pros and cons, pushback from team members, and mistakes along the way, listen to hear how Adi and his team handled those challenges and more.
Highlights:
Links:
Adi
Heather Meeker, General Partner at OSS Capital, joins me to discuss the legal elements of open source, including options for licensing and business structure.
In this episode, Heather and I explore the intersection of law and open source by reviewing licensing options, challenges, and common mistakes startups make early on. We also get into less common licensing and business models and what might be in store for the future of licensing in open source.
Highlights:
Links:
Heather
Sam Richard, Head of Growth at ngrok, joins me to talk about product-led growth in open source and ngrok’s history in open source.
In this episode, Sam and I discuss product-led growth - how it differs from a traditional sales model, what metrics founders can use to track their development, and how to find your activation metrics. We also review what kind of companies would benefit from a product-led approach, who might not, and how companies can avoid mistakes others have made in implementing the strategy.
Highlights:
Links:
Sam
Georg Link, Director of Sales at Bitergia, joins me to chat about how open source startups can use metrics to keep their communities healthy, why he approaches his role as an educator first, and how a company’s culture impacts the way they sell for open source.
In this episode, Georg and I discuss how he started the CHAOSS (Community Health Analysis Open Source Software) project to evaluate the health of open source communities and how to use metrics to gain that understanding. We also get some insight into Georg’s passion for open source, his views on sales, and Bitergia’s company culture.
Highlights:
Links:
Georg
Jonathan Reimer, CEO & Co-Founder at Crowd.dev, joins me to chat about community-led growth and cultivating a community around an open source startup.
In this episode, Jonathan and I discuss the differences between community-led growth and product-led growth, review the meaning of community, and explore the challenges of building a community around an open source startup. We also get into how community-led growth can benefit a company, the biggest mistakes startups make around community building, and the origins and operations of Jonathan’s company, Crowd.dev.
Highlights:
Links:
Jonathan
Brian MacDonald, Manager of Technical Editing at DigitalOcean joins me to discuss the importance of writing efficient documentation for any product.
In this episode, Brian and I chat about his talk at All Things Open entitled Verbs Not Nouns and covering the importance of writing documentation that instructs your users on how to use your product to solve the problem it intends to solve for them. We also cover common mistakes in writing documentation and tips for ensuring yours is effective. Listen to hear Brian's advice and resources to improve your documentation.
Highlights:
Links:
Brian
Joseph Jacks joins me to share his enthusiasm for Open Source and what he calls Commercial Open Source Companies, how the idea of Open Source is changing with new technologies, and what that means for the definition of Open Source.
In this episode, Joseph gets specific about the definition of Open Source and new technologies building on the original concept while sharing his excitement about the developments in and around the Open Source community. We also discuss the pros and cons of building an Open Source company and his philosophy on investing in Open Source Startups.
Highlights:
Links:
Joseph
Jon Gottfried, Co-founder of Major League Hacking, joins me to chat about community building, open source as a career accelerator, and how Major League Hacking began.
In this episode, Jon and I discuss the role of open source in Major League Hacking and the lessons maintainers can learn from new developers and vice versa. Jon also shares his thoughts on community, sharing responsibilities, and tips for ensuring the future of open source. Listen to hear his perspective and learn how Major League Hacking came to be.
Highlights:
Links:
Jon
Brian Douglas, CEO of OpenSauced, joins me to discuss insights - how they’ve been provided in the past, how OpenSauced is different, and how he hopes to contribute to the future of open source.
In this episode, Brian and I explore the origins and future of OpenSauced, including his hopes for how providing different insights can help contributors find worthy projects and maintainers find worthy contributors to hire. We also discuss the importance of community and telling fairer and fuller stories of open source projects. Listen to hear Brian’s unique perspective on the business of open source.
Highlights:
Links:
Brian
Matt Butcher, CEO of Fermyon, joins me to discuss the ethics of open source and how to keep your company's health in mind when growing your business.
In this episode, Matt and I dig into the ethics of open source and how his background in philosophy influences the decisions he makes as a CEO. We also cover how you can intentionally create and maintain your company values and culture. Finally, Matt reveals his top mistakes as a CEO and how he's overcome them to improve his business.
Highlights:
Links:
Matt
Henrik Rosendahl, CEO of Spiio, joins me to chat about his experience as an entrepreneur and what he’s learned about building successful companies.
In this episode, Henrik and I cover the many aspects of building startups. From the top mistakes new founders make to the best way to monetize your open source business. Listen to learn Henrik’s thoughts on entrepreneurship, including monetization, the three things you need to build a successful startup, and whether or not founding a startup should always feel like a struggle.
Highlights:
Links:
Henrik
Today I’m talking with Fabian Pinckaers, CEO and Founder of Odoo, a suite of business apps to manage all of a business’s activities, about his passion for open source and knowing how and when to pivot as a start-up.
In this episode, Fabien and I discuss the highs and lows of running a start-up as he details his history with Odoo. From its inception as a service offering for auction houses to its current state as an open core software vendor with a cloud offering, Odoo has challenged its founder to continue innovating the product and pivoting the business model to find success. Listen in to discover the lessons Fabien has learned in his journey as a founder and CEO.
Highlights:
Links:
Fabien
Today I’m chatting with Nicklas Gellner, co-founder of Medusa, “the open source Shopify alternative” about why he started the company, why open source, and his vision for the future.
In this episode, Nicklas details the original inspiration for Medusa as well as why they chose the name. We also review the switch from an agency to a product focused company. When I mention the buzz around a relatively young company like Medusa, Nicklas emphasizes Medusa’s developer-first approach and explains how that encourages community development.
Highlights:
Links:
Nicklas
Michael Chenetz, Head of Technical Marketing at Portainer.io, joins me to discuss why technical marketing is so much more effective for open source companies and also why it’s a hard role to fill.
In this episode, Michael and I discuss his unique background that lead him to technical marketing in the open source space, and the importance of relating tech to people. Michael explains the differences between traditional marketing and technical marketing, as well as the impact technical marketing has on a company’s trajectory.
Highlights:
Links:
Michael
Liz Rice, Chief Open Source Officer at Isovalent, joins me to discuss the business model behind Cilium and the enjoyment she has found working in open source.
In this episode, Liz and I discuss why Isovalent decided to donate Cilium to CNCF, and the additional decisions behind developing for Cilium open source versus Cilium for Enterprise. Tune into this episode to hear how entrepreneurship taught Liz what she didn’t enjoy doing so she could focus on work she enjoys, and what she finds most rewarding about working in open source.
Highlights:
Links:
Andrew Aitken, Global Open Source Leader at Wipro, joins me to discuss the benefits and challenges that come with adopting open source as a large-scale enterprise organization.
In this episode, Andrew and I discuss the three stages of open source maturity from curiosity to full-scale adoption and mastery. Tune into this episode to learn more about the trigger events that cause large-scale enterprises to explore open source, as well as the barriers and legal challenges they must overcome to effectively adopt it, and most importantly - why Andrew feels it’s so important that every large-scale enterprise goes through this process.
Highlights:
Links:
Randy Abernethy, Managing Director at RX-M, joins me for a chat about the relationship between open source and cloud native.
In this episode, Randy and I discuss how the clients he works with at RX-M are looking to cloud-native as part of their forward-thinking strategies. Tune into this episode to learn how Randy sees the C-Suite viewing open source, how he sees clients evaluate risk in open-source projects, and his views on the relationship between open source and cloud native.
Highlights:
Links:
Ian Tien, CEO and Co-Founder of Mattermost, joins me to talk about how Mattermost went from being a video game company to an open-source messaging platform that provides collaboration for developers and other mission-critical teams.
In this episode, Ian and I discuss the reality of product-led growth in open-source companies, Ian’s perspective on open source moving towards platform-based solutions, and the advice he would give to other open-source founders.
Highlights:
Links:
Ian
Amanda Brock, CEO of Open UK, joins me for an engaging conversation on best practices in founding an open-source company.
In this episode, Amanda and I chat about the various business models available for building a company around open-source technology, the common pitfalls and crossroads open-source founders find themselves facing, and how to do open-source in a way that leads to long-term success and profitability.
Highlights:
Links:
Wes McKinney, CTO & Co-Founder of Voltron Data, joins me for an in-depth conversation on how his quest to develop Python as an open-source programming language led him to creating the pandas project and founding four companies.
In this episode, Wes and I dive into his unique background as the founder of the pandas project and he describes his perspective on the early days of Python, his journey into the world of open-source start-ups, and the risks and benefits of paying developers to work on open-source projects.
Highlights:
Links:
Wes
Braden Hancock, Co-founder and Head of Technology at Snorkel AI, joins me to talk about his path from academia to start-up co-founder and his vision to make AI more accessible to both traditional and no-code development.
In this episode, Braden and I explore the journey he and his co-founders took to go from having an interesting idea to forming a company and the strategic business decisions they made along the way, such as why they opted not to use an open-source business model and the educational marketing strategy they’ve adopted.
Highlights:
Links:
Braden
Anna Filippova, Director of Community & Data at DBT Labs, joins me to chat about the fundamental role community plays in the world of open source and her role helping to create a thriving community.
In this episode, Anna and I dive into the concept of a community: why it’s essential for open-source development, how to create business value through community, and how to track community health above and beyond user count.
Highlights:
Links:
Highlights:
Links:
Rob
Ricardo Mendoza, founder and CEO of Pantacor, joins me for a chat at the Open Source Summit in Austin. Ricardo shares why he started Pantacor and describes the differences between IoT, edge, connected, and embedded devices. I ask him how Pantacor fits into the edge continuum, and he explains how Pantacor helps bring embedded devices into the future. Ricardo talks about the open source arm of Pantacor’s strategy, we discuss Pantacor’s unique interest in hardware versus primarily dealing with software, and Ricardo wraps up by sharing his advice for aspiring business owners!
Highlights:
Links:
Pantacor
Live from the Open Source Summit in Austin, I sit down with Jeff Shapiro, the License Scanning Manager for the Linux Foundation. Jeff begins by explaining what he does at the Linux Foundation, including ensuring that open source licenses are compatible and compliant. We discuss what license issues start-ups should be aware of, how to educate yourself on open source licensing, and when you should consult an expert. Jeff clarifies some confusion around dual licenses and explains the challenges of changing licenses on an open source project. Finally, we discuss the possibilities of disallowing specific uses through licensing and who can write a license.
Highlights:
Links:
Jeff
Today I sit down with Webb Brown, CEO and cofounder of Kubecost. Kubecost provides real-time cost visibility and insights for teams using Kubernetes. Webb tells the story of building Kubecost, starting with the pain points that inspired the open source tool. He talks about the transition from an open source project to becoming a commercial company, and explains the decision to build a company with the same name and branding as the open source tool. Webb talks about Kubecost’s newest initiative, OpenCost, and concludes by offering some lessons and advice for anyone in the early days of an open source startup.
Highlights:
Links:
Webb
Today I sit down with Ev Kontsevoy, the CEO and co-founder of Teleport, a software company that began as an open source project. Teleport is an identity aware multi protocol access proxy that Ev was inspired to create because of the inherent frustrations with security he experienced in his career. Ev talks about how Teleport began as an open source tool and then grew into enterprise. I ask Ev what things he has done differently from his first start-up, Gravity, and we discuss how the open source community culture has bled into the company culture at Teleport. We end by talking about the SaaS version of Teleport and the ways in which the open source version funnels business into the commercial version.
Highlights:
Links:
Ev Kontsevoy
Today I’m joined by Cillian Kieran, the CEO and co-founder of Ethyca, to talk about the privacy challenges that served as the impetus to found Ethyca. In our chat, he explains the overarching goals of the privacy engineering platform. We discuss the decision to begin Ethyca as an open source tool and why that was critical to the mission. Then we talk about the decision to move to a commercial product and how to decide which features to offer as paid versus free. Cillian reviews the differences in his process between his two start-ups, discusses lessons he learned from prior mistakes, and provides advice for aspiring founders of open source start-ups.
Highlights:
Links:
Cillian
Today I’m joined by CEO and founder of LeanIX, André Christ. André begins by describing his business, and then explains how his experiences working in large enterprise inspired him to build a product that would help businesses catalogue their software and optimize their portfolios. André offers advice for companies desiring to sell primarily to enterprise and expounds on the his experience with the differences between traditional enterprise and large enterprise. We discuss LeanIX’s transition to become a global company based in Europe, and conclude our talk with some advice from André to potential founders.
Highlights:
Links:
André
Today I chat with Keith Basil, GM of Edge Computing at SUSE. We begin by reviewing the definition of edge: Keith explains how SUSE breaks edge computing down into 3 categories, and then talks about the shared understanding of edge by the industry at large. I ask Keith about the overlap of edge products with non-edge products, and then we discuss the maturity of the edge landscape and Keith explains how SUSE helps clients with infrastructure. We wrap up by talking about managing feature bloat and SUSE’s decision to have their entire code base be open sourced.
Highlights:
Links:
Keith
Today I talk with Shaun O’Meara, the global field CTO at Mirantis. We begin by discussing the integration of Docker Enterprises with Mirantis approximately three years ago. We discuss the challenges of integrating companies, including incorporating new technology, processes, and customers and merging two very different work cultures. Shaun offers his advice for anyone considering selling to enterprises and emphasizes the role of partnering with customers and becoming part of their process. Shaun talks about the expectations and realities of merging Docker and Mirantis, including the challenges of a licensing model change. We conclude our time by discussing the differences between selling to small companies versus selling to enterprises.
Highlights:
Links:
Shaun
Today I sit down and chat with John McBride, senior software engineer at VMware. We begin by talking about John’s address at KubeCon, “Risks of Single Maintainer Dependencies and How to Mitigate Those Risks.” We discuss the definition of security and then John identifies some of the other non-security risks posed by single maintainer dependency. We talk a little bit about mitigating the risks and about building trust and community around single maintainer projects. We conclude our time by speculating on the extinction of single maintainer dependencies.
Highlights:
Links:
John
Today I talk with Catherine Paganini, Head of Marketing and Community at Buoyant. We begin by discussing the Cloud Native Glossary and how it is helping to make cloud native concepts more accessible for people around the world. Catherine talks about nurturing community in open source projects, and about the function of documentation. Catherine and I discuss pitfalls in building open source communities, and Catherine talks about her strategy for recovering from mistakes. Catherine concludes the conversation by talking about balancing her roles as head of marketing and community at Buoyant.
Highlights:
Links:
Cloud Native Glossary: https://glossary.cncf.io/
Linkerd: https://linkerd.io/
Linkerd Anchor Program: https://linkerd.io/community/anchor/
Catherine
Today I talk with Yann Léger, CEO of Koyeb, the serverless developer platform that allows businesses to safely and easily deploy applications. We begin by talking about Yann’s decision to base the company on serverless, and the true meaning of cloud native. Yann then discusses Koyeb’s relationship with Kuma, and Koyeb’s posture towards open source projects. The conversation concludes with Yann sharing mistakes he’s learned from in the process of building Koyeb and offering advice to other potential technical founders.
Highlights:
Links:
Yann
Today I chatted with Dirk Hohndel, chief open source officer at the Cardano foundation. We begin by defining an open source ecosystem, and then talk about what different open source ecosystems might look like and how they are maintained. Dirk talks about best practices for steering an open source ecosystem, and then we discuss the role of foundations in open source projects. I ask “how do you define success for an open source project” and we end with a discussion on the best practices for running open source project foundations.
Highlights:
Links:
Dirk
Today I sit down with Romaric Philogène, CEO and founder of Qovery, a platform that helps developers build, deploy, run, and scale applications. Romaric begins by talking about his first two start-ups, both social networks, and then we discuss the difference between creating consumer-facing products and products for developers. We then talk about marketing in the US as it compares to the global market. We discuss Qovary’s relationship to open source and the idea of fostering community around a company’s culture. Romaric concludes by offering advice to developers on the value of being a skilled communicator.
Full Description / Show Notes
Highlights:
Links:
Romaric
Today I’m chatting with Avery Pennarun, CEO of Tailscale. Tailscale is a VPN service that makes devices and applications accessible anywhere in the world by enabling encrypted point-to-point connections using the open source WireGuard protocol. Avery begins by talking about his experience building a start-up while he was a college student and how things have changed as he leads his current start-up. Avery recommends the book “Crossing the Chasm” and we discuss market segmentation as it relates to creating a successful start-up. Avery explains how Tailscale has been successful in implementing market segmentation strategies. We conclude our conversation by talking about goal setting and the importance of quality.
Highlights:
Links:
Avery
Today I chat with Kiersten Gaffney, CMO of Codefresh, a software delivery platform. Kiersten begins by defining her role as CMO. We then discuss the unique challenges of product strategy with open source projects. Kiersten talks about the importance of maintaining both a top-down and bottom-up approach when taking a project from open source to enterprise, and then explains some of the most common mistakes she’s seen when companies undergo this process. We discuss how technical a team should be when marketing open source and conclude the conversation by talking about analysis paralysis in start-ups and how to avoid it.
Highlights:
Links:
Kiersten
In this short summation episode, I talked a little more about why I think Deepfence's open source strategy is so genius.
Today I sat down with Sandeep Lahane, founder and CEO of Deepfence, a security preventive and detective solution for cloud and container native environments. Sandeep began by explaining both the open source and enterprise components of Deepfence. Threatmapper is a multi-cloud platform for scanning, mapping, and ranking vulnerabilities in running containers, images, hosts, and repositories, and Threatstryker is a commercial product that offers runtime attack analysis, threat assessment, and targeted protection for infrastructures and applications. We then talk about the inexhaustibility and the ever-changing landscape of cybersecurity. Sandeep explains the impetus for launching Deepfence and the process of getting to Threatmapper and Threatstryker, and then talks about his journey from working as a systems programmer to launching a tech startup. We discuss the tense relationship between security and development in the industry, and end the conversation with some words of advice for engineers considering the entrepreneurial plunge.
Highlights:
Links:
Sandeep
Some short thoughts on marketing in the open source ecosystem, drawn from my conversation with Eric on Wednesday.
Today I sit down with Eric Hendricks, the technical marketing director at Red Hat. Red Hat delivers open source solutions that make it easier for enterprises to work across platforms and environments. Eric begins the conversation by discussing his start as a technologist and how he decided to make the move to marketing. Eric then discusses the challenges of bringing marketing savvy into the devops space, including the unintended consequences of marketing buzzwords. I ask Eric about the relationship between marketing and open source, and Eric talks about how many of Red Hat’s community marketing efforts are driven through upstream communities. We then discuss the concept of the buyer in open source versus start ups, and how the difference is that the “big ask” in open source projects is emotional investment. Eric concludes the conversation by talking about the impact of his current role as a technical marketer as compared to the impact of a founder or IC.
Highlights:
Links:
I'm trying something new this week — adding an extra episode with some key takeaways from the interview earlier in the week. In this one, I talked about the education battle many cloud native companies face, the problem of open source projects that are too good and understanding pain points for different personas.
Today I’m joined by Omri Gazitt, founder of Aserto, an authorization company that offers cloud native authorization as a service. We discuss the differences between ID authorization and authentication and the problems associated with educating developers on the distinctions. Omri also talks about the evolution of authorization from server software all the way to cloud native authorization. He then expounds on the strategic nature of the decision to open source or not, and offers advice to developers based on his experience as both an engineer and an executive.
Highlights:
Links:
Omri
I’m joined by Mark Grover, one of the founders of Stemma, a data catalogue for building decentralized data informed cultures. In essence it is a “Google Search” built for data scientists, data analyst, business leaders, and more. Stemma is striving to solve data documentation and relevance issues by keeping data cataloguing up to date and current.
In this episode Mark covers his transition from the data team at Lyft to establishing Stemma. He discusses how he identified the need for a source of truth for ETA data, and how the data scientist in these teams should be the end all for this knowledge. Starting with building Amundsen, Stemma expands on the groundwork laid there to bring data to the user and open-source community’s needs.
Highlights:
Links:
Mark
I’m joined by Matt Leray, co-founder and CTO Speedscale, an API testing product that applies “real world” stresses to “collect and replay traffic without scripting, simulate load and chaos, and measure performance.” With a history steeped in various aspects of tech, and with time spent in the startup space and cloud native space, Matt brings to the table some encompassing perspectives.
Matt’s career has carried him from monitoring satallite earth stations, to fiber optics, and more recently into cloud native. Matt began in startups, then went to larger companies, then back to startups, which he offers some insight on. Matt has a lot of wisdom to share on entrepreneurship, how the startup space has changed, and how to best navigate that. Matt discusses how Speedscale works as an “traffic replay” platform for APIs and his role there both technically and as a co-founder. Check out the conversation for a list of startup how-tos!
Highlights:
Links:
Matt
Kit Merker, co-founder and COO at Nobl9, a software reliability platform. Through software-defined SLO’s Nobl9 helps developers, DevOps and reliability engineers deliver more reliable features faster. Kit has had a storied career in tech, and as a result is a great source of wisdom and know how. Especially in regard to navigating the various sides of any given business.
In this episode, Kit offers up some anecdotes from his long history in the software space, and how he transitioned from engieenering to the “business side” of things. He tears down some stereotypical misrepresentations of both sides, and expands on how empathy helps alleviate many of these issues. Kit discusses his partnership experiences, work in M&A, building a “coalition” in open space, and more! Tune in for our conversation for Kit’s emphatic and valuable insight.
Highlights:
Links:
Kit
Michael Guarino, founder of Plural, a unified platform for open-source management platform entirely hosted on Kubernetes which creates a fully functional ecosystem around deploying Airflow. Though working in Kubernetes and more, Plural can be used across a wide spectrum of open source projects. Many of which Plural is specifically targeting to make their product appealing to users.
In this episode, Michael talks about how Plural works within the open-source space, and how in using it with Airflow they’ve helped to elminate much of the work needed there. Michael lays out how using Plural makes using Airflow easier on the user, versus taking a DYI approach. Michael discusses avoiding lock-in, the various open source tools they use, working through the early days in COVID, the history of building Plural, and more!
Highlights:
Links:
Michael
Today’s guest is Michael Tanenbaum, CEO and co-founder of Mycelial, an edge data platform for distributed local first applications that is built with developers in mind. Myceclial takes the accomplishments of the cloud native movement to bring data that exists outside the data center into the hands of the developers themselves. With a focus on data from the “edge”, which Michael defines as anything from a smart thermostat, to a 5g tower, applications, and more.
In this episode Michael lays out how he and his partners captilized on the oppurtunity of recent innovations in cloud native, and in turn commercialize the need to “get applications out of the data center to work harmoniously with applications in the data center.” He and his co-founders are striving to build complex edge native applications and local native data. Michael breaks down the “three pillars” of edge native to provide some crucial definitions, how he identified the needs Mycelial addresses, the diverse range of obstacles they’ve already surmounted, and more!
Highlights:
Links:
Michael
Lyon Wong, CEO and co-founder of Blameless, a complete reliability engineering platform that brings together AI-driven incident resolution, blameless retrospectives, SLOs/Error Budgets, and reliability insights reports and dashboards that enable businesses to optimize reliability and innovation. Lyon has a history steeped in founding and investing in start ups and company building, which has lead a heavy involvement in Blameless where he can apply the many lessons learned.
In this episode, Lyon breaks down his background and how it influenced his decision to become a founder at Blameless. Over the course of his career he noticed trends in other companies where teams were prevented from learning opportunities because they were worried about catching the blame. As a result Lyon identified the need in the market for a way to synthesize the cultural tensions around blame. Lyon’s insight on building trust, partnership, and communications on learning are deep and worthwhile. Check out the full conversation!
Highlights:
Haseeb Budhani, co-founder and CEO of Rafay Systems, a Kubernetes operations company joins the conversation. What a Kubernetes operation company is as companies use Kubernetes across their organizations they need the right automation, security, visibility and more. These are needs that come from multiple teams working across multiple applications, and it creates a lot of work. This is where Rafay Systems is looking to cover down.
Haseeb introduces us to the work at Rafay systems, and his own discovery of the problems they want to address. Haseeb discusses the history of Rafay’s establishment, and how they are striving to create a fluid and robust workflow engine. He reflects on how his previous experience has reinforced the lessons he brought to Rafay, how to connect to the customers, and more! Check out the conversation!
Highlights:
Links:
Haseeb
Andrew Rynhard, Founder and CTO of Sidero Labs, joins the show today to discuss his work and Sidero Labs. Sidero is a Kubernetes lifecycle management reimagined from the operating system to entire stack. Andrew has origins steeped deeply in open source, and it has become a central focus to his entire ethos and drive.
Andrew breaks down his own trajectory that lead to Sidero and the passion he leveled for the endevour from the onset. Andrew’s passion for open source served as the impetus founding the company, and he shares his love for open source and the pathways that it created for him through his career. Andrew shares Sidero Lab’s successful initial funding, the shift to it being his full-time job, and their meteoric rise.
Highlights:
Links:
Andrew
Today’s episode is a round table with Morgan McClean, Ben Sigelman, and Alolita Sharma, the maintainers of Open Telemetry. Open Telemetry is a high-quality, ubiquitous, and portable telemetry to enable effective observability with a mission to make telemetry as approachable and applicable as possible. Open Telemetry’s values center on compatibility, reliability, resilience, and performance. With these objectives in hand, our maintainers are making waves in open space.
In this episode Morgan, Ben, and Alolita breakdown their individaul involvement in Open Telemetry. They discuss the paths each of them took to end up there, and the varied skillsets the bring to the project. Open Telemetry’s vision and mission is unique in its clarity and precision, and they share some insight as to why. Open Telemetry’s collaboration allows the space for their mission statement to shine through, and as a project before a product, give to the open source community. Check out the conversation for Morgan, Ben and Alolita’s excellent perspectives!
Highlights:
Links:
Open Telemetry
Tyler Jewell, Managing Director at Dell Technologies Capital, joins me for a deep conversation about the intersection of capital and technology. As a managing director, Tyler harnesses a focus on developer lead companies and the push he makes for those companies when it comes to funding. For Dell Technologies Capital, the focus is on providing the financial support and backing for the market that is developing around the developers themselves.
Tyler breaks down how he honed his focus on backing developers. He refers to the rise of software developers as a “talent class” where he could cultivate investments and partnerships. Tyler shares his parameters for how he categorizes companies and software into four “buckets,” which facilitates the focus he lends to these companies. From identification, to the intersection with capital, check out this conversation for Tyler’s in-depth and exacting definitions.
Highlights:
Links:
Tyler
Rob Hirschfeld, CEO of and co-founder of RakN, joins the show to discuss their work in the world of automation. Notably so, automation of data centers using infrastructure code principles to create “infrastructure pipelines.” Rob’s honest and open story provides a great example of how to identify areas that need a product, to developing the product itself.
In this episode, Rob gives us the history of RakN from the earlier inception when he was at Dell, to where they stand today. Rob shares some insight on the challenges of DevOps when it comes to dealing with the various “silos” that organizations have created. He reflects on their transition away from Dell, and how they realized they needed to be table to talk to customers about how they used their products.
Highlights:
Links:
Rob
Sam Bhagwat, Co-founder & Chief Strategy Officer at Gatsby, joins me for a conversation about his work. Gatsby is an open source project using React with a focus on building web sites, and not just web apps. As CSO Sam tracks the trends in the modern web development space and helps Gatsby to stay on the innovative edge. From the origin of the open source project in 2015, to the establishment of the company in 2017, Sam and Gatsby’s contributions have only grown exponentially since then.
Sam talks about the history of Gatsby’s rise to prominence and their shift from open source into a proper business. Sam dives into how and why they’ve leaned on investment into the company to help them better address the needs of the web site development ecosystem. From the first service they charged money for, Sam’s take on open source and commercial crossing paths, to Gatsby’s global focus, Sam offers up a lot for consideration!
Highlights:
Links:
Sam
Avi Press, CEO and Co-Founder of Scarf, joins me for an in depth conversation about Scarf and the work they are doing in transparecny in open source maintainers. Avi’s career and the tools he built lead to a decision to capitalize on his tools. Now Scarf is an extension of his work into a commercial opportunity to change the open source ecosystem.
Avi addresses the general maintaner issues that Scarf wishes to solve. Avi expands on his processes that have landed on a data forward approach and the importance of making that data is a viable capital value. Avi also breaks down the uses of Scarf for maintainers and the suite of tools they are implementing. Importantly so, Avi talks about the ways that the open source space can change to stay innovative and relevant.
Highlights:
Links:
Avi
Alex Chircop, CEO of Ondat.io, joins me to talk about his company and their recent rebrand to reflect their shift to focus on some fundamental changes in the industry. With a changing persepective that mirrors the changes happening in cloud data and its uses, Alex and the teams at Ondat.io are staying ahead of the curve and implementing some institutional changes.
In this episode Alex goes into the details of their rebranding, and he discusses how they are shifting to answer what Alex calls the “infrastructural dilemma.” With the massive shift to cloud native that developers are making, and the requirements that are demanded by the adoption of these infrastructural demands, Alex and his team are staying in step with the larger community. Alex also discusses the “why” behind their drive to rebrand, and their determination to maneuver the concept of storage as server based into data services that are application centric.
Highlights:
Links:
Alex
Matt Yonkovit, Head of Open Source Strategy at Percona, joins me for a conversation about Percona’s work and their robust history in open source. Percona has been at it for 15 years now and Matt’s work there is both prolific and sets him up to be very well informed about open source strategy at large.
In this episode, Matt discusses what exactly his job means within the context of Percona, and how he covers down to help both the higher echelons of the company, but also the community. Matt provides an excellent bird's eye view of what is going on in the world of open source. His experience highlights many of the challenges that the open source model is currently facing, and can expect to face in the near future.
Highlights:
Links:
Connect with Matt
Dawn Foster, Director of Open Source Community Strategy at VMware, joins me to chat about open sourcing and the potential risks to consider. With 20+ years of experience in business technology, Dawn lends great insight not only as a leader in the realm of open source, but as a champion for measuring project health.
In this episode, Dawn discusses key risks to consider when open sourcing a project and what startups and small companies should think about as they embrace open source technologies. We also explore trust as a currency of open source, donating to neutral foundations, the CNCF Project Health Measurement Guide, and more.
Highlights:
Links:
Connect with Dawn:
Joe Bignell, the Kubernetes recruiter at InterQuest Group, joins me for an interesting conversation about the current job market in the Kubernetes space and his role and vision as a talent seeker.
In this episode, Joe and I go into the rabbit hole as we explore the global talent shortage and its impact on the Kubernetes ecosystem. Joe shares invaluable insight and perspective on recruiting for startups, what founders can do to attract talent, and why transparency from all sides (company, recruiter, and candidate) is vital. We also discuss remote work and its increased value and how companies can leverage their Kubernetes talent.
Highlights:
Links:
Jonathan Ellis, CTO and co-founder of DataStax, has always had a startup mindset. In this episode, Jonathan joins me to discuss his journey and entrepreneurial roadmap thus far.
In our conversation, Jonathan shares how he became involved with the Apache Cassandra project and his transition to founding DataStax. He also shares insight on the importance of hiring a go to market team, why hiring executives proves to be more challenging than engineers, building a company based around an open-source project, and more.
Highlights:
Links:
Jonathan
LinkedIn: https://www.linkedin.com/in/jbellis/
Twitter: https://twitter.com/spyced
DataSTax: https://www.datastax.com/
Guy Podjarny, co-founder and President of Snyk, has seen the world of startups through the lens of an employee and as a founder. With two companies under his belt, Guy has excelled as an entrepreneur as Snyk proves to be a leader in developer security.
In this episode of Cloud Native Startup, Guy shares insight on his first startup, Blaze (acquired by Akamai), and his current company, Snyk. He lends perspective on key traits to master when building a successful company and why it’s an exciting time to be an entrepreneur. We also explore why there are major gaps in security, what it will take to fix them, and how Snyk is helping close the gap by decentralizing security.
Highlights:
Links:
Guy
For Vidya Raman, technology has always been close to her heart. As an investor at Sorenson Ventures, Vidya is guided by this passion and plays an impactful role in helping technical founders build and grow successful businesses. Vidya serves as a leader in early-stage startup investing and thrives on optimizing companies.
In this episode of Cloud Native Startup, Vidya talks about her transition from engineering to venture capital investing, important criteria to consider when evaluating companies, what founders should look for in VCs, her lessons learned, and more.
Highlights:
Links:
Vidya
Glasnostic is a cutting-edge observability solution that enables DevOps, SRE and security teams to effectively control emerging disruptive behaviors. In this episode of Cloud Native Startup, I chat with Glasnotic’s co-founder and CEO, Tobias Kunze.
As a trailblazer in the world of cloud-native technologies and a two-time startup founder, Tobias brings a wealth of insight. Prior to Glasnostic, Tobias founded Makara, which was later acquired by Red Hat Open Shift. In our conversation, we explore his journey from Makara to Glasnostic and his shift from engineering to entrepreneurship. We also discuss why sales and people management are core skills needed to become an entrepreneur, the importance of actively stepping out of your comfort zone, and the staggering pace of technology.
Highlights:
Links:
Tobias
Laurent Gil is by no means a novice when it comes to founding companies. As the Co-Founder and Chief Product Officer at CAST.AI, Laurent marks this as his fourth company. As a repeated entrepreneur, Laurent comes with valuable insight, which he brings to this conversation on Cloud Native Startup.
In this episode, we discuss Laurent’s entrepreneurial journey, which has taken him across the globe and he shares his opinion on why entrepreneurs should hear the word “no.” We also discuss the importance of simplifying product features, the bond he’s built with his co-founders, product-market fit, and more.
Highlights:
Links:
Laurent
As the Co-Founder and Chief Technology Officer at Kong Inc., Marco Palladino takes great pride in the company he has built from the ground up. Marco’s story begins with his move from Italy to San Francisco with no money and a 3-month visa. Today, he and his fellow Co-Founder, Augusto Marietti, have undoubtedly earned that pride.
In this episode of Cloud Native Startup, we explore Marco’s life journey, and he reflects on how his obsession with building Kong led to its innovative success. We also discuss why Kong’s pivot was a risk worth taking, compare building companies around open source, dive into the importance of releasing trust as a technical founder, and more.
Highlights:
Links:
Marco
In this episode of Cloud Native Startup, Ihor Dvoretskyi, Developer Advocate at Cloud Native Computing Foundation (CNCF), joins me for a conversation about contributing a project to CNCF. We discuss the benefits of contributing an open source project and Ihor shares insight on the key metrics for success. Ihor also defines each of the three project stages; sandbox, incubating, and graduated, and takes a deep dive into the history of this fascinating open source foundation.
Highlights:
Links:
Ihor
In this episode of Cloud Native Startup, Justin Borgman, Chairman and CEO of Starburst Data, takes us through Starburst’s evolution as it speedily makes its mark in the enterprise software space. As a two-time startup founder, Justin illustrates his journey towards founding Starburst, alongside his fellow co-founders, and we explore how they built this unique company. He also shares his advice and lessons learned and we discuss what’s in store for Starburst as the company ventures into its next phase.
Highlights:
Links:
Justin
This week on Cloud Native Startup, I’m joined by Tobi Knaup, CEO & Co-Founder of D2iQ.
In this episode, Tobi provides insight on how D2iQ helps its customers change the world through open source and how it is reflected in their core mission. We also explore what led to the creation of this pioneering technology company and how the cloud native space has changed since.
Highlights:
Links:
Tobi
D2iQ
HashiCorp’s Co-Founder and CTO, Armon Dadgar, joins me for a conversation on Cloud Native Startup.
In this episode, we focus on open source and how it serves as the core to HashiCorp’s identity. We also explore Armon’s journey towards founding HashiCorp with Mitchell Hashimoto and what the future holds as they both lean into their respective passions. Learn a few keys to cultivating a successful open source community, why some companies don’t rely on this success, his lessons learned, and more.
Highlights:
Links:
Armon
HashiCorp
Neil Cresswell, co-founder of Portainer, joins me this week on Cloud Native Startup. In this episode, we talk about the evolution of Neil’s fascinating career, which began at age 17, and how it led to Portainer. We also discuss Portainer’s core ethos of simplicity, open source product, Neil’s predictions on Kubernetes, and more.
Highlights:
Links:
Neil
Portainer
Michael Hyatt joins me on this episode of Cloud Native Startup.
Not only is Michael a leading tech investor and philanthropist, but he also ranks as one of Canada’s top entrepreneurs. In this episode, Michael provides a wealth of knowledge as he shares invaluable tips for aspiring, new, and current founders. We also discuss the early stages of founding companies with his brother Richard, the mentality behind hiring your weakness, the phenomenal impact of computing, and much more.
In this episode, we cover:
Links:
Michael Hyatt
J.J. Guy, Co-founder and CEO of Sevco Security, joins me this week on Cloud Native Startup. In this episode, J.J. breaks down Sevco Security and the IT security ecosystem. We also discuss challenges, lessons learned, building a solid team culture and more.
Highlights:
Links:
J.J.
Sevco Security
This week on Cloud Native Startup, I am joined by William Morgan, CEO of Buoyant, Inc. In this episode, William talks about his beginnings as a software engineer at Twitter and his transition towards starting and running his own company. We also discuss how rewriting Linkerd enhanced its core value of simplicity, the blessing and curse of open source, his advice to his younger self, and more.
In this episode, we cover:
Links:
William Morgan
Buoyant
Linkerd
David Friend, co-founder and CEO of Wasabi Technologies, Inc. writes the rules of his own success. With 7 companies under his belt, David continues to be an impactful maverick entrepreneur. In this episode, David and I talk about the evolution of his journey, which started off in the music industry, and how it led him to found a cloud data storage company. Join us for more on this week’s episode of Cloud Data Startup.
Highlights:
Links:
David
Wasabi Technologies Inc.
This week, Swaroop Jagadish, co-founder of Acryl Data, takes us through his journey from quitting his day job as an engineer to founding his first startup company alongside Shirshanka Das. Swaroop also shares his insights on Acryl Data’s business model and the advantages and challenges of building an open source project-based company. Tune in for more on Swaroop and Acryl Data in this episode of Cloud Native Startup.
Highlights
Links:
Swaroop:
Acryl Data
Dhiraj Sharan, CEO and founder of Query.AI, joins me this week on Cloud Native Startup.
With a career that spans over 20 years in cybersecurity, Dhiraj has seen the swift adoption of multi-cloud environments and SaaS apps. In this episode, Dhiraj discusses the importance of evolving your product as the world changes and why you should ask yourself, “How can I be innovative for the next layer?” Dhiraj also gives his younger self advice on the cybersecurity game of chess and much more.
Highlights
Links:
Anurag Goel, Founder and CEO of Render, joins me on this episode of Cloud Native Startup. Learn about his beginnings at Stripe as employee #8, the birth of Render and how it solved a gap in the market, and his lessons learned while transitioning roles. We also discuss how open source fits into business strategy and much more.
In this episode, we cover:
Links:
This week on Cloud Native Startup, I talked with Wei Dang, founder of cloud native security company StackRox which was acquired by RedHat in 2020.
Highlights:
How Wei met his co-founder and how the two of them saw the need for new types of security tools.
Why talking to people throughout the Kubernetes ecosystem led to a series of a realizations that security in a cloud native world was going to me an increasingly important part of the conversations as more people adopted Kubernetes.
Where the name StackRox came from.
How even understanding if there was a market for a container security product. The moments wondering ‘are we building the right product’ was the scary.
Why it’s important to focus at the beginning.
How StackRox evolved from container security to Kubernetes security as the broader conversation shifted and the industry consolidated around Kubernetes.
The moment Wei felt like there was product-market fit for StackRox.
How Wei would define Kubernetes Security.
The ways in which starting and growing a company forced Wei to learn new skills and gain knowledge.
Why community is so important for companies in the Kubernetes ecosystem.
How things have changed — and how they haven’t — since becoming part of Red Hat.
Links
https://twitter.com/weiliendang
https://www.linkedin.com/in/weiliendang/
The Business of Cloud Native is now Cloud Native Startup. Going forward, I'm moving away from talking to end users and focusing instead on what it takes to build a startup in the cloud native ecosystem. I'll be talking with startup founders, startup advisors and others in the ecosystem about making the transition from software engineer to startup founder, the stories behind companies we read about in the tech press and how to increase your odds of success in the cloud native startup world.
This week on The Business of Cloud Native, I spoke with Abby Kearns, CTO at Puppet, about the changing role of technology in the enterprise and how that changes things for software companies like Puppet.
Highlights
Whatever the exact definition of cloud native, ultimately it is a way to improve scaling and resilience.
The increasing importance of software for enterprises, because customers simply expect to use software to connect with companies of all sizes.
Why cloud native is tied to digital transformation — because you can’t do one without the other.
Picking tech and deploying it — that’s the easy part. But the people part is hard. Changing organizational structures is hard, but the companies that are succeeding in the new digital environment have to do the hard work.
Why enterprises that are successfully using software to build a better relationship with your customers have top company leadership, from the CEO on down, investing in the transformation and incorporating technology into the company’s vision.
How the changing role of technology in the enterprise has changed things for technology companies like Puppet.
How technology decisions have now become board-level decisions, rather than decisions that made in a basement among technologists.
How the changing landscape has forced Puppet to change its go to market strategy, positioning and messaging.
The speed of change in the technology space seems to be accelerating and can lead to a lot of uncertainty.
Why open source can be extremely rewarding, but requires companies to give up a huge amount of control that can be unnerving for enterprises.
What is the role of a CTO at a technology company — is it tactical? Is it visionary?
Links
This week on the Business of Cloud Native, I talked with Kelsey Hightower, principle engineer at Google and Kubernetes expert. We talked about how technology like Kubernetes helps engineers focus more on solving business problems instead of constantly solving the same low-level problems.
Highlights:
How the evolution of technology — and the evolution of customers’ expectation — have made cloud native practices table stakes.
The more established a company is, the more layers it likely has in its technology stacks. Unless a company is under 10 years old, it probably isn’t 100% cloud native because it’s rarely practical to throw away everything they’ve been doing in the past.
Why it’s so challenging for companies to “disrupt themselves” by adopting cloud native technology unless they have serious motivation.
How successful cloud native journeys involve both grand strategic visions and boring tactical plans that can actually be implemented.
Why companies need to take into account the entire ‘infrastructure’ needed to adopt cloud native. How do you collect the data you need to reach your goals? Do you have the human resources, both technical and non-technical, to achieve their goals?
How cloud native transitions can quickly become an ‘onion’ problem where there is always another layer that companies need to solve.
How to convince practitioners who are trying to build customer tools internally that they should use Kubernetes or other open source projects.
The myth of ‘tech displacing people.’ Usually evolution of technology leads to more jobs for software engineers, not less.
How Kubernetes helps engineers focus on the business — and that is a good thing.
The difference between 20 years of experience and 20 years worth of 1-year experience.
Why Kubernetes is a platform for building other platforms.
Why Kubernetes and cloud native are not a magic bullet that will completely transform your business.
Links:
This week on The Business of Cloud Native, I spoke with Mark Thiele of Edgevana about the definition of cloud and cloud native, where the line is between cloud and edge and situations where edge is the best option.
Highlights:
A discussion of situations where edge is the most appropriate option and how edge can help solve problems related to latency, data transfer costs, data sovereignty and network access.
Why the right architecture depends on your business needs — there is no one size fits all way to design an edge solution.
The relationship between data centers, public clouds and edge devices, including how co-location facilities fit into the equation.
How IT is shifting from being a cost center in the business to being a profit center, and how this re-framing of IT is the root of fundamental change.
What types of companies can successfully manage a data center and what types of companies should accept that they don’t have the skills and just go to the public cloud.
Why success in the digital transformation is really a question of prioritization.
Do you enjoy the podcast? Help others find it by leaving a review on Apple Podcasts and sharing on social media.
Links
This week on The Business of Cloud Native, I spoke with Jana Boruta, Director of Global Events at HashiCorp, about building community — for startups, for big companies and for open source projects with no budget. We also touched on digital-first events and how they differ from in person events.
Highlights:
What is community and why does it matter for companies building commercial tools for developers.
Why community building is for everyone — from Nike to volunteer organizations to enterprise software.
Is it ever too early for community building? How to determine if you’re building community for the right reasons.
Why community building is a long game — not something that will show immediate ROI after a single event.
Community building starts with creating a community blueprint. While some tactics are common, but every company’s community is going to be different and has to be authentic to the company.
Why product feedback can be an important first step for building a community.
Why starting with community building too early, when the product is too buggy, can be counter productive.
Why you should avoid thinking of your community as a demand gen program.
How create digital events that provide value for the attendees, even if they deliver it in a very different way than an in-person event.
Links:
Digital-First Events, Jana’s book about digital events
This week on The Business of Cloud Native, I spoke with James Campbell, CEO of Cado Security, about his background in the security world and why he felt like there needed to be a better way to manage security forensics in a cloud native environment.
Highlights:
Why it’s important to get better information about security incidents — or potential security incidents — to make better decisions.
Why security has to be relatively easy because otherwise people will ignore it — at their peril.
How cloud native features like auto-scaling are great for compute but make security, especially security forensics, more complex.
Without enough data collected in real time, companies can end up unable to know whether or not an anomaly actually caused data loss, which data was impacted and what the root cause of incident was.
How some of the most sophisticated attackers operate and how they can cause havoc even if the impacted container has spun down.
The triggers that led Campbell and his co-founder to start Cado Security.
Why having better information is critical to responding effectively to breaches, large and small.
Links:
What is edge? What is cloud? What is the difference and what are the different requirements for each use case? I talked to Samy Fodil, CEO and founder of Taubyte, about edge computing, industrial IoT and how the edge requires a dramatically different approach from the cloud.
Highlights:
Why edge is a truly distributed system, unlike the cloud.
What inspired Fodil to start Taubyte and why he thinks the edge will be the default computing platform in the years to come.
What overlap there is in skill sets between on-prem development, cloud development and developing edge-native applications.
Why edge-to-edge communications can be so hard for developers to understand.
What barriers prevent companies from taking advantage of the edge and why it’s worth it for those businesses in spite of the complexity.
Links:
Samy Fodil on LinkedIn
This week on The Business of Cloud Native I spoke with Travis Nielsen and Sebastien Han about how Rook has evolved over the years, beginning as a way to build a cloud native storage platform but before anyone was talking about cloud native or Kubernetes.
Links:
This week on The Business of Cloud Native, I talked with former Gartner Analyst, current VP of Solutions at Securonix Augusto Barros. We talked about how Securonix’s positioning has evolved over the years as it has move between market categories as well as how to evaluate and test cloud native security solutions.
Links:
In this episode with Evan Reiser, CEO of Abnormal Security, we explored how positioning and an understanding of who your ideal customers are and what their needs are can influence technology choices, including which cloud provider you build on.
Highlights
How a seemingly pure technology choice like cloud provider can have serious implications for customer experience.
The difference between having a board-level discussion about cloud providers is different from gathering the engineering team to talk about cloud infrastructure
Why being integrated in the Microsoft ecosystem was a strategic business decision and how technology decisions in general can be high-level business decisions
Why technology teams should think more about what the customers need and want instead of just choosing the best tool from a technical perspective
Evan’s hesitations about making the transition to Azure and why they did it anyway
Why they chose to re-architect at the time they did
Even though the move to Azure was made to improve customer experience, customers don’t necessarily have a different experience since the move
Why founders should keep in mind that startups rarely fail because their technology doesn’t work, but because they don’t meet the needs of their customers
Links:
This week on The Business of Cloud Native, I talked with Brian Gracely about using Kubernetes for edge workloads as well as the difference between “cloud” and “edge.”
Highlights
Is edge part of the cloud, is cloud a part of edge or are they completely separate but slightly related environments?
What makes something a data center vs what makes something an edge device?
How enterprises think of edge vs how Telcos think about edge.
How the edge has gone from being a cost center to a competitive advantage for enterprises.
Why Telcos have always thought of edge as a market opportunity.
Why Kubernetes can help standardize environments and make it easier to deploy software to the edge, but there are still challenges to overcome.
Why edge deployments require re-thinking many basic environmental factors like bandwidth and compute capacity.
Why consistency at the edge is so important.
Why you can’t ignore the physical conditions that make edge environments unique.
Links
In today’s episode of The Business of Cloud Native, I talked with Julien Pivotto and Richard Hartmann, two of the maintainers of Prometheus, about how the project started, how it’s evolved over the years (and how it’s stayed the same) as well as some novel ways Prometheus is used in the real world.
Highlights
Why both Julien and Richard got started with Prometheus
Some surprising ways that Prometheus is used to monitor things beyond the software engineering world
How Prometheus has evolved in technology and usage over the years
How Kubernetes and its relationship with Prometheus has changed the project
What assumptions ‘cloud native’ creates for potential Prometheus users
Links
In this episode of The Business of Cloud Native, Chris Holmes talks about bootstrapping Decipher Technology Studies and their core product, intelligent service mesh Greymatter.io. He also talks about why it's so important for brownfield and greenfield apps to talk to one another and the many similarities between public sector and private sector organizations.
Highlights:
How Greymatter combines business intelligence and security controls.
The difference between working with public sector customers and private sector / enterprise customers — and why there are more similarities than differences.
How segmentation is sometimes necessary for any highly security-conscious organization, including both government organizations and financial services companies in the private sector.
Why we need to respect legacy applications — because they tend to be the mission-critical applications that drive revenue.
Why connecting brownfield and greenfield applications is critical, because not all ‘legacy’ apps will ever be moved to the cloud.
What ‘returns’ a company is looking for when evaluating ROI on cloud migrations.
What we mean when we talk about an “ROI” on security tools.
Why Kubernetes’ terrible networking is part of why Chris could see that service meshes would be necessary even back in 2015.
Links:
This week on The Business of Cloud Native I spoke with Chris Psaltis, CEO and co-founder of mist.io. We spoke about why multicloud is necessary (and scenarios where multicloud is not necessary), where multicloud is headed in the future and the journey Chris and his co-founders have been on with Mist.
Highlights
The difference between using multicloud for legal / regulatory reasons or because of the company’s history and using multicloud strategically to improve developer velocity or improve customer experience.
The complexity involved with pursuing multicloud and why many organizations are better off in just one cloud.
Why being cloud agnostic from day one is not a good strategy in the vast majority of cases.
Why no one seems to be able to correctly estimate how difficult it is to build a multicloud platform.
Why ‘silos’ are the competitive alternative to a unified platform for companies
How Mist went from working primarily with smaller teams before figuring out that they provided more value for large teams because the pain from multicloud management increases exponentially as the number of engineers, applications and environments increases.
When the founding team decided to stop being consultants and start an open source technology startup.
Links
This week on The Business of Cloud Native, I talked to Tzury Bar Yochay, founder and CTO of Reblaze, about building a cloud native security company before twelve thousand people were going to KubeCon.
Highlights:
Why your security measures have to keep up with hackers’ sophistication.
The moment when Tzury decided to go from being a contractor for the defense industry to founding a company.
Why the default path for startups is failure.
Why open source is key to securing your cloud environment.
How selling a security product to developers has evolved over time.
Why lazy developers are good developers.
Why selling software to developers is different from selling software to other types of professionals.
Why he thinks the most brilliant developers tend to gravitate towards open source.
Why security based on obscurity is a terrible, perhaps even evil, strategy.
Links:
@tzury on Twitter
This week, I talked with Karthik Ranganathan about the challenges going from employee of a large company to startup frounder and why he founded Yugabyte because he wanted a database that both was transactional and still could be highly available.
Highlights:
Why the ability to scale is important for any cloud native application, including for a cloud native database.
Why Yugabyte is still open source and why being open source is important to the company.
Why enterprises wanted an open source database to house their mission-critical data.
Why the company went from an open core model to open source / managed service model.
Why end customers care about open source.
Why early-stage, small companies have trouble establishing trust and how being open source helps build trust.
Why building around open source helps nudge customers to ‘buy’ instead of built it themselves.
Why finding the right position and the right message is a major challenge at the beginning of the company.
Links:
This week, I talked to Natalie Ledbetter, Head of People and Platform at Boldstart Ventures. We talked about how startups can approach team and culture building, including:
Links:
In this episode of The Business of Cloud Native, we talk about the hard business goals behind words like "freedom" as well as what it's like to go from engineer to CEO. My guest, Sirish Raghuram, is the CEO and co-founder of Platform9.
Links:
https://platform9.com/
https://www.linkedin.com/in/sirishraghuram/
In this episode of The Business of Cloud Native, Shawn Lankton talks about how Microsoft 365 and related applications fit into an organization's move to the cloud and why organizations need to pay attention to security for all their SaaS applications.
Links:
https://www.coreview.com
Shawn on Twitter
Thomas Markey talks about how to remove some of the barriers to running an open source project with free hosting services.
Links:
Have you thought about how your OSS license could impact your ability to grow your community and monetize your OSS in the future? Attorney McCoy Smith talks about what to be aware of at the beginning to avoid messy legal issues down the road.
As an analyst at CCS insight, Bola Rotibi gets a birds-eye view of trends in how industries use software to advance their business goals. We had an incredible conversation about how companies use cloud native technology to meet business goals and how vendors in the cloud native space should pay more attention to the needs of specific industries.
Links:
https://www.ccsinsight.com/blog/author/bolarotibi/
https://www.linkedin.com/in/bolarotibi/
https://twitter.com/bolarotibi
SaaS companies that handle customers' sensitive data need to worry about how they manage data locality. In this podcast, Canopy CTO and founder talks about how their business would not be possible without the flexibility and ability to easily spin up resources in regions across the world that a cloud native architecture offers.
Links:
https://www.canopyco.io
https://www.linkedin.com/in/oransears
Here's what I covered in this episode:
Thanks for listening, and happy new year!
Jim Bugwadia, CEO and co-founder of Nirmata, talks about what has changed (and what has stayed the same) since the company started in 2013.
Links:
https://www.linkedin.com/in/jimbugwadia/
https://nirmata.com
https://kyverno.io
In episode 29 of The Business of Cloud Native, I talked to Krishnan Subramanian of Rishidot Research about trends he sees in how end users use cloud native technologies and how startups in the space can meet end users where they are.
Links:
https://www.linkedin.com/in/krishnansubramanian/
https://twitter.com/krishnan
This conversation covers:
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.
Emily: Welcome to the Business of Cloud Native. I'm Emily Omier, your host, and today I'm chatting with Idit Levine of Solo.io. Idit, I want to start out, first of all, by thanking you for joining me.
Idit: Oh, thanks so much for having me.
Emily: And then, second of all, I wanted you to just start off by introducing yourself: what you do, what your company does, and also a little bit about how that translates into what you do every day, like, what activities you spend your day doing.
Idit: Oh, for sure. Okay, so as you said, my name is Idit Levine. And I’m, right now, the founder and the CEO of Solo.io. I started Solo two years ago, and when I started it, my focus was try to solve our [00:01:24 unintelligible] application networking problem that we know that will come up.
So, what does it mean? As you guys all know, there was a huge shift in the market between monolithic to microservices and, kind of like, moving from technology of monolithic to microservice stack mean that now we also moved to a distributed application. And it was clear to me that now everything is basically will go on the wire; any communication, small communication, between those two microservices basically will have to go to the network. And I thought that would become a big problem because stuff that we didn't need to take care of when everything was the same binary, now we need to actually figure out how to solve. And basically, I was really passionate, thought that that will be a huge problem in the ecosystem and I was very passionate to actually try to solve that. So, the idea was, how to connect, right? How to connect the application, how to connect everything related to your, eventually, application to the user.
Emily: And then tell me a little bit, what do you do every day? When you start, what does an average day actually consist of?
Idit: Oh, wow. So, it's really interesting, that I think it's a huge difference between now and what I was doing a year ago. Right now, basically, it's pretty simple. Corona came by and it was influence a lot of companies. I was assume that it will influence also my company, and therefore I basically freeze hiring, freeze everything, and try to do the best I can with the resources that we had.
What happened is that actually, not only that we didn't was influenced, we actually over doubled our revenue every quarter. That's basically forced me to immediately grow the team to be able to actually serve all those customers. Right now, basically, the main thing that I'm focusing on is—besides the technology, of course, in the strategic of the company—is basically on growing the team. So, it's hiring, it's interviewing, it's looking for the right people, it's building. You know, basically try to grow the team as much as I can in order to basically, yeah, serve well, the customer that are asking for us to—you know, for our products. That's a lot of my focus this day.
Emily: And what do you find are the business reasons? What's the business problems that cause somebody to come to you?
Idit: So, as I said, once people basically is moving from monolithic to microservices, there is a lot of simple stuff that before that just natively happened inside of the organization; right now, it's a little bit more complex. So, first of all, they needed to find something to run it on, and this is what Kubernetes so great in this ecosystem is the ability to install, upgrade, and basically orchestrate their microservices. But then, as I said, simple stuff that before that people were baking into the microservices created a lot of issues, like small stuff, like how do two microservices communicate with each other? How do you make sure that they're doing it safely right now? Because as right now, it's all on the wire, so potentially, there's always a third party that could, you know, join the party.
So, you really need to be safe and make sure that there is a very secure line between those microservices. And then the last thing is that because there is so many because the idea of microservices was to allow you to scale, the question is how do where the request is actually routed? So, in the [00:04:52 unintelligible], request is coming, and there is a lot of replication of the same microservices, and you have no idea basically where it's coming and where it's landing. And then it will go to the next level of the microservices, and again, not know which instance of it is basically being hit.
So, now the question is, how do you get visibility to something like that? How do you know what's going on in your cluster? How do what to look for the logs when now it's distributed all over the place. So, that's a lot of problem that the organization basically started to have. As well as with this—if—before that, there was a technology called [00:05:26 api-get] that was relatively popular, but people somehow—it wasn't a must.
Right now, when microservices was adopted specific in environment like Kubernetes, when everything is very cloud-wise, you know, stuff is coming up and coming down, you really wanted to make sure that you have a place that you can actually control the policy, control the [00:05:50 unintelligible], the [00:05:51 unintelligible]. And that's basically where API can help. So, that is basically—how do you manage all this networking, basically, of all these systems and applications, as an edge gateway? It's something that going inside your cluster, as well as what's going on inside the cluster after it. And that's basically, yeah, the main problem that you're solving.
So, every traffic to your infrastructure, node to start, we're basically taking care of exactly of everything that you then have traffic between what called East and West, inside your cluster. And that's basically the st...
This conversation covers:
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.
Emily: Welcome to the Business of Cloud Native. My name is Emily, I'm your host, and today I'm chatting with Sam Selikoff. Thank you so much for joining us, Sam.
Sam: Thanks for having me.
Emily: Yeah. So, today, we're going to do something a little bit different, and we're going to talk about positioning for open source projects. A lot of people talk about positioning for companies, which is also really important. And they don't always think about how positioning is important for open source. Open source maintainers often don't like to talk about marketing because you're not selling anything.
But you are asking people to give you their time which, at least for some people, is actually more valuable than their money. And that means you have to make a compelling case for why it's worth it to contribute to your project, and also why they should use it, why they should care about it? So, anyway, we're going to talk with Sam, about Mirage. But first, I should let you introduce yourself. Sam, thank you so much for joining me, and can you introduce yourself a little bit?
Sam: Sure. My name is Sam Selikoff. These days, I spend most of my time teaching people how to code in the form of videos on my YouTube channel, and my website, embermap.com. Most of it is front end web development focused. So, we focus on JavaScript. I have a business partner who also works with me. And then we also do custom app development, you know, some consulting throughout the year.
Emily: Cool. And then tell me a little bit about Mirage.
Sam: Yeah, so Mirage is the biggest open source project I've been a part of since falling into web development, I'd say about eight years ago, I got into open source pretty early on in programming, kind of what made me fall in love with web development and JavaScript. So, I was starting to help out and just get involved with existing projects and things that I was using. Eventually, I made my way to TED Talks, the conference company where I was a front end developer, and that's actually where I met my business partner, Ryan. And we were using Ember.js, which is a JavaScript framework, and we had lots of different apps at TED that were helping with various parts of publishing talks, and running conferences, and all that stuff.
And we were seeing some common setup code that we were using across all these apps to help us test them, and that's where Mirage came from. There was another project called Pretender, which helped you mock out servers so that you could test your front end against different server states. And we first wrapped that with something called Pretenderify, and then it grew in complexity. So, I was working on it on my learning Wednesdays, renamed it to Mirage, and then I've been working on it basically ever since. And then, the other big step, I guess, in the history is that originally was an Ember only project, and then last year, we worked on generalizing it so that it can be used by React developers, React Native developers, Vue developers, so now it's just a general-purpose JavaScript API mocking library.
Emily: So, we would say that the position is an API mocking library. And—does that sound right?
Sam: Yeah. If I had to say what it is, I would say it's a mocking library that helps front end developers mock out backend API's so that they can develop and test the user interfaces without having to rely on back end services.
Emily: Why does that matter?
Sam: It matters because back end services can be very complicated, there can be multiple back end services that need to run in order to support a UI, and if you're a front end developer, and you just want to make a change and see what the shopping cart looks like when it's empty. What does the shopping cart look like when there's one item? What does it look like when there's 100 items, and we have to have multiple pages? All three of those states correspond to different data in some back end service, usually in a database.
And so, for a front end developer, or anyone working on the user interface, really, it can be time-consuming and complex to put that actual server in that state that they need to help them develop the UI. That can involve anything from running, like, a Rails server on their computer to getting other API's that other teams manage into the state they need to develop the UI. So, Mirage lets them mock that out and basically have a fake server that they control and they can put into any state they need. So, it’s like a simplified version of back end services that the front end developer can control to help them develop and test the UI.
Emily: And when you first started Mirage, did you think of it as an API mocking library?
Sam: Not exactly. We used it mostly because of testing. So, in a test, it's usually a best practice to not have your test rely on an actual network. You want to be able to run your test suite of your user interface anywhere, let's say on an airplane or something like that. So, if your user interface relies on live back end services, that's usually where you would bring in a mocking library.
And then you would say, okay, when the user visits amazon.com/cart, normally, it would go try to fetch the items in your cart from a real server, but in the test, we're going to say, “Oh, when my app does that, let's just respond with zero items. And then in this next test, when my app does that, let's respond with three items.” So, that's the motivation originally, is in a testing environment, giving the UI developer control over that. And then what happened was that it was so useful, we started using it in development as well, just to help during normal times, just because it was faster than working with the real back end services.
...This conversation covers:
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.
Emily: Welcome to The Business of Cloud Native, I'm your host Emily Omier. And today I'm chatting with Andrey Rybka from Bloomberg, thank you so much for joining us, Andrey.
Andrey: Thank you for your invitation.
Emily: Course. So, first of all, can you tell us a little bit about yourself and about Bloomberg?
Andrey: Sure. So, I lead the secure computer architecture team, as the name suggests, in the CTO office. And our mission is to help with research implementation of new compute-related technologies to support our business and engineering objectives. But more specifically, we work on ways to faster provision, manage, and elastically scale compute infrastructure, as well as support rapid application development and delivery. And we also work on developing and articulating company’s compute strategic direction, which includes the compute storage middleware, and application technologists, and we also help us product owners for the specific offerings that we have in-house.
And as far as Bloomberg, so Bloomberg was founded in 1981 and it's got very large presence: about 325,000 Bloomberg subscribers in about 170 countries, about 20,000 employees, and more news reporters than The New York Times, Washington Post, and Chicago Tribune combined. And we have about 6000 plus software engineers, so pretty large team of very talented people, and we have quite a lot of data scientists and some specialized technologists. And some impressive, I guess, points is we run one of the largest private networks in the world, and we move about a hundred and twenty billion pieces of data from financial markets each day, with a peak of more than 10 million messages a second. We generate about 2 million news stories—and they're published every day—and then news content, we consuming from about 125,000 sources. And the platform allows and supports about 1 million messages, chats handled every day. So, it's very large and high-performance kind of deployment.
Emily: And can you tell me just a little bit more about the types of applications that Bloomberg is working on or that Bloomberg offers? Maybe not everybody is familiar with why people subscribe to Bloomberg, what the main value is. And I'm also curious how the different applications fit into that.
Andrey: The core product is Bloomberg Terminal, which is Software as a Service offering that is delivering diverse array of information of news and analytics to facilitate financial decision-making. And Bloomberg has been doing a lot of things that make financial markets quite a bit more transparent. The original platform helped to demystify a lot of bond trading and pricing. So, the Bloomberg Terminal is the core product, but there's a lot of products that are focused on the trading solutions, there is enterprise data distribution for market data and such, and there is a lot of verticals such as Bloomberg Media: that's bloomberg.com, TV, and radio, and news articles that are consumer-facing.
But also there is Bloomberg Law, which is offering for the attorneys, and there is other verticals like New Energy Finance, which helps with all the green energy and information that helps a lot to do with helping with climate change. And then there's Bloomberg Government, which is focused on, specifically, research around government-specific data feeds. And so in general, you've got finance, government, law, and new energy as the key solutions.
Emily: And how important is speed?
Andrey: It is extremely important because, well, first of all, obviously, for traders, although we're not in high-frequency game, we definitely want to deliver the news as fast as possible. We want to deliver actionable financial information as fast as possible, so definitely it is a major factor, but also not the only factor because there's other considerations like reliability and quality of service as well.
Emily: And then how does this translate to your approach to new technology in general? And then also, why did you think cloud-native might be a good technology to look into and to adopt?
Andrey: So, I guess if we define cloud-native, a little because I think there's different definitions; many people think of containers immediately. But I think that we need to think of outside of not just, I guess, containers, but I guess the container orchestration and scaling elastically, up and down. And those, I guess, primitives. So, when we originally started on our cloud-native journey, we had this problem of we were treating our machines as pets if you know the paradigm of pets versus cattle where pet is something that you care for, and there’s, like, literally the name for it, you take it to the vet if it gets sick. And when you use think of herd of cattle, there's many of them, and you can replace, and you have quite a lot of understanding of scalability with the herd versus pets.
So, we started moving towards that direction because we wanted to have more uniform infrastructure, more heterogeneous. And we started with VMs. So, we didn't necessarily jump to containers. And then we started thinking like, “Is VMs the right abstraction?” And for some workloads it is, but then in some cases, we started thinking, “Well, maybe we need something more lightweight.”
So, that's how we started looking at containers because ...
This conversation covers:
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.
Emily: Welcome to The Business of Cloud Native. I'm your host, Emily Omier, and today I'm chatting with Thomas Vitale. Thomas, thanks so much for joining us.
Thomas: Hi, Emily. And thanks for having me on this podcast.
Emily: Of course. I just like to start by asking everyone to introduce themselves. So, Thomas, can you tell us a little bit about what you do and where you work, and how you actually spend your day?
Thomas: Yes, I work as a senior systems engineer at Systematic. That is a Danish company, where I design and develop software solutions in the healthcare sector. And I really like working with cloud-native technologies and, in particular, with Java frameworks, and with Kubernetes, and Docker. I'm particularly passionate about application security and data privacy. These are the two main things that I've been doing, also, in Systematic.
Emily: And can you tell me a little bit about what a normal workday looks like for you?
Thomas: That's a very interesting question. So, in my daily work, I work on features for our set of applications that are used in the healthcare sector. And I participate in requirements elicitation and goal clarification for all new features and new set of functionality that we'd like to introduce in our application. And I'm also involved in the deployment part, so I work on the full value stream, we could say. So, from the early design and development, and then deploying the result in production.
Emily: And to what extent, at Systematic, do you have a division between application developers and platform engineers, or however else you want to call them—DevOps teams?
Thomas: In my project, currently, we are going through what we can call as maybe a DevOps transformation, or cloud transformation because we started combining different responsibilities in the same team, so in a DevOps culture, where we have a full collaboration between people with different expertise, so not only developers but also operators, testers. And this is a very powerful collaboration because it means putting together different people in a team that can bring an idea to production in a very high-quality way because you have all the skills to actually address all the problems in advance, or to foresee, maybe, some difficulties, or how to better make a decision when there's different options because you have not only the point of view of a developer—so how is better the code—but also the effects that each option has in production because that is where the software will live. And that is the part that provides value to the customers.
And I think it's a very important part. When I first started being responsible, also, for the next part, after developing features, I feel like I really started growing in my professional career because suddenly, you approach problems in a totally different way. You have full awareness of how each piece of a system will behave in production. And I just think it's, it's awesome. It's really powerful. And quality-wise, it's a win-win situation.
Emily: And I wanted to ask also about security and data privacy that you mentioned being one of your interests. How do those two concepts relate to cloud-native technologies? And what are some of the challenges in being secure and managing data privacy specifically for cloud-native?
Thomas: I think in general, security has always been a critical concern that sometimes is not considered at the very beginning of the development process, and that's a mistake. So, the same thing should happen in a cloud-native project. Security should be a concern from day one. And the specific case of the Cloud: if we are moving from a more traditional system and more traditional infrastructure, we have a set of new challenges that have to be solved because especially if we are going with a public cloud, starting from an on-premise solution, we start having challenges about how to manage data.
So, from the data privacy point of view, we have—depending also on the country—different laws about how to manage data, and that is one of the critical concerns, I think, especially for organizations working in the healthcare domain, or finance—like banks. The data ownership and management can really differ depending on the domain. And in the Cloud, there's a risk if you're not managing your own infrastructure in specific cases. So, I think this is one of the aspects to consider when approaching a cloud-native migration: how your data should be managed, and if there is any law or particular regulation on how they should be managed.
Emily: Excellent. And can you actually tell me a little bit about Systematic’s journey to cloud-native and why the company decided that this was a good idea? What were some of the business goals in adopting things like Docker and Kubernetes?
Thomas: Going to the Cloud, I think is a successful decision when an organization has those problems that the cloud-native technologies attempt to solve. And some goals that are commonly addressed by cloud-native technologies are, for example, scalability. We gain a lot of possibilities to scale our applications, not only in terms of computational resources, and le...
This conversation covers:
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.
Emily: Welcome to The Business of Cloud Native. I'm Emily Omier, your host, and today I'm chatting with Iftah Gideoni. Iftah is the CTO at Forter. Iftah, first of all, thank you so much for joining me.
Iftah: Very glad to be here.
Emily: So, I wanted to have you start by introducing yourself and what you do, and then also what Forter does.
Iftah: Hi, I'm Iftah. I’m a physicist of education, and in the last 20 years, a CTO of several companies, mostly [00:01:11 unintelligible] governmental companies, and companies that I founded. In the last six and a half years, I'm with Forter. And what Forter started to do from 2014 is to provide what was, at the time, very bold vision of fully automated, fully cloud-based decisions about whether to allow or decline e-commerce transactions.
Now, from that time we actually implemented and executed that, we decide very many more than 3 million transactions every day, today, all in real-time without a human in the loop. And we expanded into being a fully-fledged trust engine that gives decisions not only about transactions, but about many other points of interaction with the consumer, for example, in their login time, and in other points where trust decision is needed.
Emily: So, just because I think it might be interesting to listeners, give me some examples of, like, when somebody might interact with Forter or have some sort of action approved or declined by Forter.
Iftah: Right. The prime customers of Forter are the big e-commerce enterprises. Think about the [00:02:42 Sephoras], the Nordstroms, the Home Depots, and this kind of companies. And whenever you press the button of requesting to committing to the purchase and you see this small things rounding on the screen, then it is sent to Forter and Forter within, usually, half a second returns a decision.
Now, Forter does not act as an additional data point, or input, or score into some system of the merchant. It actually answer whether to approve or decline the transaction. In very many—and most of the revenue of Forter comes from a covered transaction that, if this transaction was fraud, it’s on Forter. Forter will guarantee it. And we were pioneering this model to putting our mouth where our money is.
Emily: Tell me just a little bit about why this is so difficult. What makes what Forter does unique?
Iftah: What Forter does is unique because it tells the human story, and takes it all the way to the decision itself. For example, it's very easy to approve the fourth transaction of a person that is sitting at home, browsing from home, making the purchase on the same desktop they made at previous times, and sending the shipment to the same home. That's very easy. But we want to be able to approve the traveler, the person that is sending a gift to a third party, or a person that is sending a gift to another state while not browsing from home and not from his common device.
We want to be able to approve those transactions that are checking out as guests from a new device and that's the first time this person ever appeared on our radar. And the ability to do that and to take the calculated risks and to look at the behavior, the cyber clues, and still be able to tell that this is indeed a new person and not someone that visited before and is trying now to hide. That's what makes what we do very difficult and complex.
Emily: So, tell me a bit about the technology story. What technology do you use to accomplish this, and how does it work? What does your stack look like?
Iftah: When I came to—from 2014, I looked at the system and what is actually needed in order to cater to such a complex story? And I thought to myself—and we'll talk about maybe a bit later about how all this is excellently suited for the Cloud, but what I found that throughput and big data is not the problem. First, it’s more or less solved, but it is the e-commerce business; it's not Facebook scale throughput. And on the other hand, it's not hardcore real-time, right? We're talking about tens of milliseconds, not the microseconds domain.
What is extreme about what we do is the complexity of the flow. We have hundreds of processes that are needed to be ran within that half a second in order to test, and check, and infer, and decide on many aspects of this transaction and of this person. So, first, we started from Amazon Web Services, and we started with, actually, Apache Storm. And why we decided that because we wanted to have something that enables first, a lot of parallelism—doing many things in parallel—with smart joins, that is with processes that takes information from other processes that executed in parallel, and can decide whether what they have so far from these processes is enough. Because we are very high availability, we didn't lose more than 10 seconds straight in the last four years. We are very high availability, but a lot of our sub-processes are not.
So, you need such a machine that will be able to infer about whether the information at hand is good enough and to move forward and still give, after half a second, the answer. We also wanted to have within this high availability system, we wanted to have the domain experts, the analysts, and the fraud researchers, we wanted to give them a very direct access to the code and each insight that they get, in close to real-time, maybe in 10 or 15 minutes from the time that they understood that there is a new wave of attacks or a new fraudster in action in a particular store or across stores. We wanted all these insights to be manifested in the sys...
This conversation covers:
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.
Emily: Welcome to The Business of Cloud Native. Today, I am talking with Tobie Langel from UnlockOpen, and I wanted to start, Tobie, by just asking, you know, what do you do? Can you give us sort of an introduction to what you do, and how you tend to spend your days?
Tobie: Sure. So, I've been back into consulting for a number of years at this point. And I essentially focus on helping organizations align their open-source strategy with business goals. So, it can be both at the project level—so sometimes helping specific projects out—or larger strategy at the corporate level.
Emily: So, I actually recently had Nithya Ruff, who's the head of the OSPO at Comcast on the podcast. For listeners who don't know, that's an open-source program office. So, are you sort of an outsourced OSPO for companies that aren't Comcast’s size?
Tobie: So, that's a really good question. My answer would be no, but it tends to happen that I help companies build that capacity internally. So, I would generally tend to come up before an OSPO is needed, and help them figure out what exactly they need to build. For OSPO, my pet peeve is companies building OSPOs like they need to tick a checkbox on the list of the things that they have to do to be up-to-date with good engineering practices, if you will.
In general, if you want to be successful, with an OSPO, it has to meet the particular needs of your company, and that's usually kind of hard to figure out if you just leave it to whoever in the organization is more interested in driving that effort. And so essentially, I sort of help in the early stages of that by bringing all of the stakeholders at the table, and essentially listening to them and making sure that what they want out of an OSPO is aligned between the different stakeholders and matches the overall strategy of the company.
Emily: And who are the stakeholders that you're generally talking to?
Tobie: So, essentially, open-sources is strange, for one reason, in terms of how it was adopted in companies from a historical perspective. Adopters have always been essentially engineers who just wanted better tools, or the package or the software that best fitted their current intention, and there's a very, very grassroots process by which companies start using open-source. And what happened at some point is companies sorted to see all of the software, and got concerned, and started trying to assess the risk. And so companies just tended to bring in the legal arm and lawyers at this point. And so to fulfill compliance questions, you bring in lawyers, and then the responsibility of grown-up open-source kind of falls on to lawyers, which tends to be problematic from the perspective of good engineering practice and velocity that you want from your engineering and product side in a company.
And so clearly, the two stakeholders or the two main stakeholders tend to be legal and engineering, and there tends to be a tension between these two sides. And in lots of companies this tension, instead of being resolved to some degree, tends to be won by the legal side that understands business concerns better and is better able to praise or explain what they do in terms of business impact and business risks than the engineering side. And so this equilibrium tends to create OSPOs which are legal heavy, process heavy, and don't really give engineers the kind of freedom that they would need to be effective in their daily engineering practice. And the reason behind that being essentially over exaggerated risk perception of open-source because, to be frank, open-source is not well taught in legal school and clearly not part of the curricular that most lawyers are familiar with when they move into helping tech companies out. So, essentially, I sort of tried to bridge these two worlds.
Emily: I can imagine that being an open-source lawyer, that's a niche, that's a very specific niche.
Tobie: Yeah, actually there's a running joke in that community, which is, “As soon as you get your law degree and you’re an open-source lawyer, you’re one of the 25 best open-source lawyers in the world.”
Emily: [laughs]. That's awesome. Why do you think engineering teams are so bad at clearly articulating their perspective on open-source, and what can they do to improve?
Tobie: So, there are clearly multiple reasons why engineers aren't the best at articulating how open-source matters. So, I think one of the key ones, it's just, it's something that's part of their daily practice, and they don't really understand and never have been taught the actual intellectual property—IP—impact, that open-source has on their company, and they don't really understand how others in the company might perceive this IP impact. So, I think, one part of it is, essentially, this is just how engineers work. Like, you want to use a piece of software, you put it in it, right? If you want to fix something, well, you do a pull request. This is sort of, like, a common practice. And it's always hard to articulate things that are essentially part of your, like—you know, like a native language, like part of your culture. It's really hard to describe, why you would do this, and why it matters. So, I think that's one reason.
The other reason, I think, is that there is a lot of overlap between the way legal works, and the way business works in general. Few examples of that are, engineers tend to think really like in binary way, like, you know, something is true or false, something is on or off, whereas business and law a much more spectrum thinking and into the gray area of things. Similarly, law will share with executive manager’s schedule, versus a maker’s schedule. So, there's lots of cultural artifacts of law culture in corporat...
The conversation covers:
Links
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.
Emily: Welcome to The Business of Cloud Native. Today, I'm chatting with Tracy Miranda. Tracy, thank you so much for joining me.
Tracy: Hi, Emily. Thanks for having me. It's my pleasure.
Emily: So, as usual, I just want to start off with having you introduce yourself, both what you do, where you work, but also, like, some details, what does this actually mean? How do you actually spend your day?
Tracy: Yeah, so I'm the director of open-source CloudBees, and I'm also the board chair at the Continuous Delivery Foundation, which is an open-source foundation, which is home to projects like Jenkins, and Spinnaker, and Tecton, and Jenkins X. So, basically, I'm a big fan of all things open-source, which in day-to-day means I'm doing anything which is related to building communities. So, either involved with code, or building communities and through conferences, or sometimes just the boring governance stuff around open-source.
Emily: What is the boring governance stuff around open-source?
Tracy: So, I guess it is just trying to get folks moving in the same direction, and reminding people that it's sometimes more than just code. And whether it's updating a code of conduct, and one of the things we've seen and—okay, I wouldn't call this boring; it's actually taken over a bit in open-source communities, but it's sort of different from the code, but it's the whole terminology updates. We've seen a lot of open-source communities have become more aware about wanting to be better about using terms like ‘master’ and ‘slave’ and move away from that. That being said, it's not that easy, so there's a lot to do in getting people on the same page and ready to move forward even before you can start changing a line of code.
Emily: Since the topic of the podcast is cloud-native, obviously, open-source and cloud-native are related. In fact, some people think that cloud-native must be open-source. Where do you fall on that spectrum? How do you think the relationship between open-source and cloud-native should be described?
Tracy: Yeah, I think that they're pretty distinct things. So, cloud-native is all about using the Cloud effectively and having technology which takes advantage of modern architectures to give you things like rapid elasticity, or on-demand self-service. And that's distinct from open-source, which is around the licensing, and it's become more about communities, as well. But I think because Kubernetes has been the most successful cloud-native project that is open-source, I guess there's become this very, very strong association which, in my mind, is a very, very good thing because I think open-source communities are really the way to drive innovation very, very quickly across the industry.
Emily: And this may seem sort of obvious, but what are some of the advantages and disadvantages to an organization in using open-source?
Tracy: Yes. So, I think—well, lots—virtually every company uses open-source, and the first thing people can see as the benefits are just the engineering efficiencies. So, using technologies which, say aren’t core to the business, but then building on top of those and taking advantage of the features rather than dedicating their own engineering resources to developing them. I used to work as a consultant, and I would go from company to company, and usually, they would be adopting open-source when they wanted to get away from an in-house project where the people or person who had written it had left the company. So, I think there's a lot to be said, as well, for sustainability of technology: that communities and open-source communities are really good at sustaining projects over the long term, and therefore kind of the best bet for technology that's going to live on beyond individuals or even companies, acquisitions, or whatever.
Emily: Do you think there are any risks to using open-source? I'm even interested in hearing if there are risks that are not real, but that are perceived risks. And then even maybe some risks that people don't think about, but that are in fact, quite real.
Tracy: Yes, yeah, no, absolutely there are risks. So, it's wise for companies to approach with caution. I think the risks sort of depend on which side—like, are you looking to just use open-source that someone else has written, or are you contributing something, which might be key to your company, but then you’re saying, “Okay, I'm going to do this in an open way,” which brings us to one of those common perceived myths, that someone, like a cloud provider, is then going to take your open-source software and do a better job of making money around it, so thereby just ruining your entire business model.
And I think the other area where we tend to see a lot of dialogue around, is always around open-source security. For a long time, people used to, sort of, make out that this was different from closed source security, somehow. Security through obscurity meant that closed-source was better than open-source, which is clearly not the case. You can have secure open-source software, not secure open-source software. It just really depends on the project and the practices.
Emily: And then also, I thought we'd talk a little bit specifically about this CI/CD work that you do. How important is CI/CD, do you think, in the pursuit of being cloud-native?
Tracy: Yes, no, I think CI/CD h...
The conversation covers:
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.
Emily: Welcome to The Business of Cloud Native, my name is Emily Omier, and today I'm chatting with Nithya Ruff, and she's joining us from the open source program office at Comcast. Nethya, thank you so much for joining us.
Nithya: Oh, it's such a pleasure to be here, Emily. Thank you for inviting me.
Emily: I want to start with having you introduce yourself, you run an open source program office. And if you could talk a little bit about what that is, and what you do every day.
Nithya: So, just to introduce myself, I started working in open-source back in 1998, when open-source was still kind of new to companies and organizations. And from that point on, I’ve been working to build bridges between companies using open-source and communities where open-source is created. At Comcast, I have the pleasure of running our open source program office for the company, and I also sit on the board of the Linux Foundation and recently was elected chair. So, it gives me a chance to both look at the community side through the LF and through corporate use of open-source at Comcast.
So, you also ask what does an OSPO do? What is an OSPO, and why does Comcast have one? So, an open source program office is a fairly new construct, and it started about 10, 11 years ago, when companies were doing so much open-source that they really couldn't keep track of all of the different areas of open-source usage, contribution, collaboration across their companies. And they felt that they wanted to have a little more coordination, if you will, across all of their developers in terms of policy for use, the process for contribution, and some guidelines around how to comply with open-source licenses and, on a more strategic note, to educate both executives as well as the company in terms of open-source and opportunities from a business engagement and a strategy perspective. So, you find that a lot of large companies typically have open source program offices.
And we, frankly, have been using open-source for a very long time as a company, almost since the turn of the century, around 2005. And we started contributing and our number of developers started growing, and we didn't realize that we needed a center of excellence, which is what an open source program office is, where people can come to ask for help on legal matters—meaning compliance and license matters—ask for help in engaging with open-source communities, and generally come for all things open-source; be kind of a concierge service for all things open-source.
Emily: And how long has Comcast had an OSPO?
Nithya: I came on board in 2017 to start the OSPO, but as I mentioned before, we’ve done open-source organically throughout the company for many, many more years before I came on board. My coming on board just, kind of, formalized, if you will, the face of open-source work for the company to the outside world.
Emily: You know, when we think about open-source in the enterprise, what sort of business opportunities and risks do you have to balance?
Nithya: That's a great question. There are lots and lots of great business value and opportunity that companies get from open-source. And the more engaged you are with open-source, the more business value you'll get. So, if you're just consuming open-source, then clearly it reduces the cost of your development, it helps you get to market faster, you're using tried and tested projects that other companies have used and hundreds of developers around the world have used. So, you get a chance to really cut cost and go to market faster.
But as you become more sophisticated in collaborating with other companies and contributing open-source back, you start realizing the benefit of, say leveraging a lot of other developers in maintaining code that you've contributed. You may start off at contributing a project, and you are often the only one bearing the burden of that project, and very soon, as it becomes useful to more and more people, you're sharing the burden with others, and you benefit from hundreds of new use cases coming into the code, hundreds of new features and functions coming in which you could never have thought of as a small team yourself. I believe that the quality of code improves when you're going to open-source something, it helps with recruitment and thought leadership because now candidates can actually see the kind of work that you do and the quality of work that you produce, and before that, they would just know that you were in this space, or telecom, or other areas, but they could not see the type of work that you did. And so, to me, from a business value, there's a tremendous amount of business value that companies get.
On the risk side is the fact that you need to use it correctly, meaning you need to understand the license; you need to understand how you're combining your code with the proprietary code in your company; you need to understand if the code is coming from a good community, meaning a healthy community that is here to stay, and that has a good cadence of releases and is vibrant ...
This conversation covers:
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.
Emily: Welcome to The Business of Cloud Native, my name is Emily Omier. I'm your host, and today I'm chatting with Ben Golub. Ben, thank you so much for joining us.
Ben: Oh, Thank you for having me.
Emily: And I always like to just start off with having you introduce yourself. So, not only where you work and what your job title is, but what you actually spend your day doing.
Ben: [laughs]. Okay. I'm Ben Golub. I'm currently the executive chair and CEO of Storj Labs, which is a decentralized storage service. We kind of like to think of it as the Airbnb of disk drives, But probably most of the people on your podcast who, if they're familiar with the, sort of, cloud-native space would have known me as the former CEO of Docker from when it was released up until a few years ago. But yeah, I tend to spend my days doing a lot of stuff, in addition to family and dealing with COVID, running startups. This is now my seventh startup, fourth is a CEO.
Emily: Tell me a little bit, like, you know, when you stumble into your home office—just kidding—nobody is going to the office, I know. But when you start your day, what sort of tasks are on your todo list? So, what do you actually spend your time doing?
Ben: Sure. We've got a great team of people who are running a decentralized storage company. But of course, we are decentralized in more ways than one. We are 45 people spread across 15 different countries, trying to build a network that provides enterprise-grade storage on disk drives that we don't own, that are spread across 85 different countries. So, there's a lot of coordination, a lot of making sure that everybody has the context to do the right thing, and that we stay focused on doing the right thing for our users, doing the right thing for our suppliers, doing the right thing for each other, as well.
Emily: One of the reasons I thought it’d be really interesting to talk with you is that I know your goal is to, sort of, revolutionize some of the business models related to managing storage. Can you talk about that a little bit more?
Ben: Sure. Sure. I mean, obviously, there's been a big trend over the past several years towards the Cloud in general, and a big part of the [laughs] Cloud is storage. Actually, AWS started with S3, and it's a $90 billion market that's growing. The world's going to create enough data this year to fill a stack of CD-ROMs, to the orbit of Mars and back. And yet prices haven't come down, really, in about five years, and the whole market is controlled by essentially three players, Microsoft, Google, in the largest, Amazon, who also happen to be three of the five largest companies on the planet.
And we think that data is so critical to everything that we do that we want to make sure that it doesn't stay centralized in the hands of a few, but that we, sort of, create a more, sort of, democratic—if you will—way of handling data that also addresses some of the serious privacy, data mining, and security concerns that happen when all the data is held by only a few people.
Emily: With this, I'm sure you've heard about digital vegans. So, people who try to avoid all of the big tech giants—
Ben: Right, right.
Emily: Does this make it possible to do that?
Ben: Well, so we're more of a back end. So, we're a service that people who produce-consumer-facing services use. But absolutely, if somebody—and we actually have people who want to create a more secure way of providing data backup, more secure way of enabling data communications, video sharing, all these sorts of things, and they can use us and service those [laughs] digital vegans, if you will.
Emily: So, if I'm creating a SaaS product for digital vegans, I would go with you?
Ben: I would hope you’d consider us, yeah. And by the way, I mean, also people who have mainstream applications use us as well. I mean, so we have people who are working with us who may have sensitive medical data on people, or people who are doing advanced research into areas like COVID, and they're using us partially because we're more secure and more private, but also because we are less likely to be hacked. And also because frankly faster, cheaper, more resilient.
Emily: I was just going to ask, what are the advantages of distributed storage?
Ben: Yeah. We benefit from all the same things that the move towards cloud-native in general benefits from, right? When you take workloads, and you take data, and you spread them across large numbers of devices that are operated independently, you get more resilience, you get more security, you can get better performance because things are closer to the edge. And all of these are benefits that are, sort of, inherent to doing things in a decentralized way as opposed to a centralized way. And then, quite frankly we’re cheaper. I mean, because of the economics and doing this this way, we can price anywhere from a half to a third of what the large cloud providers offer, and do so profitably for ourselves.
Emily: You also offer some new revenue models for open-source projects. Can you talk about that a little bit more?
Ben: Sure, I mean, obviously I come from an open-source background, and one of the big stories of open-source for the past several years is the challenges for open-source companies in monetizing, and in particular, in a cloud world, a large number of open-source companies are now facing the situation where their produc...
The conversation covers:
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.
Emily: Welcome to The Business of Cloud Native. I'm Emily Omier, your host, and today I'm chatting with Josh Stella. Josh, thanks so much for joining us.
Josh: Well, Emily, thanks so much for having me.
Emily: Of course. I always like to start the same. Can you just introduce yourself and your company, and tell me a little bit about what the company does, and then also what you do?
Josh: Sure. So, Fugue does cloud security for public cloud providers like AWS, and Azure, and Google. Prior to founding Fugue, I worked at AWS as a principal solutions architect primarily focused on national security; Department of Defense, and similar things. My background is I'm a programmer and I'm a software architect, and I've kind of lived between national security kinds of work and high tech in startups. And so what Fugue does is we’ll tell you all about the security posture of your cloud environments, and teach you where you have weaknesses that hackers can exploit; we help you close those, and then we can actually keep things from having those misconfigurations going forward. So, that's a little bit about us. If you're a developer, you can use our forever free developer version, and we work with a lot of enterprises folks like SAP, and big organizations, too.
Emily: So, were you involved with setting up the super-secret CIA cloud that AWS was involved in?
Josh: I was not personally. A very close colleague of mine was actually working very closely on that, but no, I was not directly involved in that.
Emily: Okay, you probably couldn't talk about it, even if you were so. [laughs].
Josh: No comment.
Emily: Anyway, I always like to ask also, what do you actually do? Like, you get up in the morning, presumably, you don't go to an office anymore, but—
Josh: Oh, true. True, yeah. Whether going to an office or not, my days are… so I started out founding the company with my co-founder, Andrew Wright. And for a while, I was the CEO when we were in the kind of R&D phase, but then I always intended to hire a really great CEO, which we did a couple of years ago, Phillip Merrick, and I became the CTO. And there are different kinds of CTO.
My main functions are, like, I get up in the morning, I go read the news about any breaches in Cloud that have happened, and then I try to recreate them whenever possible, if there's enough information, because the attack vectors on Cloud are completely different than in the data center, and are inobvious to folks. So, when you read about a breach, and you see that they use the identity and access management service almost like a network, to get to S3, that's really interesting and it's really important so that Fugue can protect our customers. So, I spent a fair amount of time doing that. I do work every day with the product team. Occasionally, I will weigh in fairly strongly on an engineering topic, but a lot of times our engineers are just very, very good and we've hired experts and all their areas so I work with them, but it's usually just to give advice and some guidance.
And I do a fair amount of writing, and I do a fair amount of teaching classes online: we have a masterclass series on Cloud security that has been very well received. And then the research I do into how cloud exploits are actually being done by recreating those in my own environments, I use those both in the classes and of course, Fugue as our product can then have protections built-in against them. So, I’d say that's a lot of what I do.
Emily: I wanted to ask a little bit more about this difference between cloud security and data center security. Can you go into that a little bit more? And then also, what do people miss in that difference?
Josh: Okay, so I'm going to start at the prosaic and kind of go to the sublime a little bit, but the most simple way to think about the difference is in the data center days, you really had a network perimeter. So, you've got a big pile of servers, they're racked and there are switches that that connect them together, and then there's this layer of security at the, kind of, perimeters of the network where the data center network connects to, whether it's the corporate network, or another data center, or the internet. And that kind of perimeter defense slash defense in-depth idea meant when you were talking about data center security, the primary things you were thinking about were, “What's happening on my netwo...
The conversation covers:
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.
Emily: Welcome to The Business of Cloud Native. I'm Emily Omier, your host, and today I'm chatting with AJ. AJ, can you go ahead and introduce yourself?
AJ: Hey, I'm AJ. I’m vice president of product for DigitalOcean. I've been with the company for about 15 months. Before that, I spent about a couple of decades with Microsoft. I was fortunate to work on Azure for the last decade, and I had the opportunity to build some cloud services with the company.
Emily: And thank you so much for joining us.
AJ: Thank you, thank you for having me.
Emily: I always like to start out by asking, what do you actually do? What does a day look like?
AJ: [laughs]. It’s an interesting question. So, yes, the day is usually all over the place depending on the priorities and things that are in motion for a given quarter or a week, per se. But usually, my days involve working with the team around the strategic initiatives that have been planned, driving clarity around different projects that I [unintelligible]. Mainly working with leadership on defining some of the roadmap for the product as well as the company. And yeah, and talking to lots of customers. That's something that I really, really enjoy. And every other day I have a meeting or two talking to our customers, learning from them, how they use our products and how can we get better.
Emily: I'm going to ask more about those conversations with customers because that's what I find really interesting. But first, actually, I wanted to start with another question. What do you see as the difference between cloud computing and cloud-native?
AJ: The difference essentially, in a way, the cloud computing is a much bigger umbrella around how we as a technology industry are enabling other businesses to bring their workload to a more scalable, more efficient, more secure environment versus trying to host, optimize, or do things by themselves. And the cloud-native, in a way, it's a subset of a cloud computing where not necessarily you always have to have existing workloads or something that is prior technology that has been already built and you're looking for a place to host. In a way, when you're building something out, new, greenfield apps and whatnot, you're starting from scratch, you're building your applications and solutions that are cloud-native by definition. They're built for Cloud; they're born in Cloud, and are optimizing the latest and the greatest innovations that are present and as future-looking to help you scale and succeed your business, in a way.
Emily: Do you think it's possible to have a cloud-native application that runs on-premise?
AJ: There's a lot of [laughs] innovations happening in pockets, and especially from the top providers to enable those scenarios. But at the end of the day, those investments are essentially driven to help people and companies, especially on the larger scale, to buy some time to completely move to the public cloud where the industry takes their time to come up with the compliance, security requirements and [unintelligible]. So, you'll start to see—you might have heard about some of the investments these top cloud providers are doing about allowing and bringing those similar stack and technologies that they are building in a public cloud to on-premise or running on their own data center, in a way. So, it is possible, in bits and pockets to start with a cloud-native to run, on-premise, but that customer segment and the target is very, very different than the ones that start in a public cloud first.
Emily: I want to switch to talking about some of the conversations that you have with customers. I really like to understand what end users are thinking. What would you say when you talk to customers? What's the thing that they're most excited about?
AJ: Right. So, it depends on what segment of customers you're speaking with, right? DigitalOcean serves a very different set of customers than a typical large cloud providers do. We're focused more on individual developers, small startups, or SMBs. Again, when I say SMBs, it's a broad term, when I say SMBs the S with [unintelligible].
So, we focus mainly on two to ten devs team, and smaller companies and whatnot. So, their requirements are very different; their needs are very unique compared to what I used to talk, back in my past life, with enterprise customers. Their requirements are very unique and different as well. So, what I hear from the customers that I speak with recently, and have been speaking with for last over a year, is how can I make my business that is [unintelligible] on a cloud? And what I mean by that is how do I build solutions that are simple, easy to understand, and where I'm focused on building software and not really worrying about the complexity of the infrastructure, at the same time, keep the price in control and very simple and predictable.
And that resonates really, really well. The tons and tons of customers that I spoke with recently, they moved from large cloud providers to our platform because their business was not viable on those cloud providers. And what I mean by that...
The conversation covers:
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.
Emily: Welcome to The Business of Cloud Native, I'm your host Emily Omier, and today I am chatting with Gou Rao. Gou, I want to go ahead and have you introduce yourself. Where do you work? What do you do?
Gou: Sure. Hi, Emily, and hi to everybody that's listening in. Thanks for having me on this podcast. My name is Gou Rao. I'm the CTO at Portworx. Portworx is a leader in the cloud-native storage space. We help companies run mission-critical stateful applications in production in hybrid, multi-cloud, and cloud-native environments.
Emily: So, when you say you’re CTO, obviously that's a job title everyone, sort of, understands. But what does that mean you spend your day doing?
Gou: Yeah, it is an overloaded term. As a CTO, I think CTOs in different companies wear multiple hats doing different things. Here at Portworx, technically I'm in charge of this company strategy and technical direction. What does that mean in terms of my day to day activities? And it's spending a lot of time with customers understanding the problems that they're trying to solve, and then trying to build a pattern around what different people in different industries and companies are doing, and then identifying common problems and trying to bring solutions to market, by working with our engineering teams, that sort of address, holistically, the underlying areas that I see people try and craft solutions around, whether it's enabling an agile development environment for their internal developers, or cost optimization, there's usually some underlying theme, and my job is to identify what that is, and come up with a meaningful solution that addresses a wide segment of the market.
Emily: What are the most common pain points that you end up talking to customers about?
Gou: Over the past, I think, eight-plus years or so—I think the enterprise software space goes through iterations in the types of problems that are being solved. Over the past eight-plus years or so, it really has been around this—we use this term cloud-native—enabling cloud-native environments. And what does that really mean? In talking to customers, what this is really meant recently is enabling an agile application development and deployment environment. And let's even define what that is.
Me as an application developer, I have to rely on traditional IT techniques where there's a separate storage department, compute department, networking department, security department, and I have to interact with all of them just to develop and try out an application. But that really is impeding me as a developer from how fast I can iterate and build product and get it out there, so by and large, the common underlying theme has been, “Make that process better for me.” So, if I'm head of infrastructure how can I enable my developers to build and push product faster? So, getting that agility up in a sense where it makes—cost-wise, too, so it has to make cost sense—how do I enable an efficient, cost-efficient development platform? That has been the underlying theme. That sort of defines a set of technologies that we call cloud-native, and so orchestration tools like Kubernetes, and storage technologies like, hopefully, what we're doing at Portworx, these are all aimed at facilitating that. That's been sort of what we've been focused on over the past couple of years.
Emily: And when you talk to customers, do they tend to say, “Hey, we need to figure out a way to increase our development velocity?” Or do they tend to say, “We need a better solution for stateful applications?” What's the type of vocabulary that they're attempting to use to describe their problems, and how high-level do they usually go?
Gou: That's a good question. Both. So, the backdrop really is, “Increase my development velocity. Make it easier for me to put product out there faster.” Now, what does it take to get there? So, the second-order problems then become do I run in the public cloud, private cloud? Do I need help running stateful applications? So, these are all pillars that support the main theme here, which is increasing development velocity. So, the primary umbrella under which our customers are operating under is really around increasing the development velocity in a way that makes cost sense.
And if you double-click on that and look at the type of problems that they're solving, they would include, “How do I efficiently run my applications in a public cloud? Or a hybrid cloud? How do I enable workflows that need to span multiple clouds?” Again because maybe they're using cloud provider technologies, like either compute resources, or even services that a cloud provider may be offering, so that, again, all of this so that they can increase their development velocity.
Emily: And in the past, and to a certain extent now, storage was somewhat of a siloed area of expertise. When you're talking to customers, who are you talking to in an organization? I mean, is it somebody who's a storage specialist or is it someone who's not?
Gou: No, they're not. So, that's been one of the things that have really changed in this ecosystem, which is the shift away from this kind of like, hey, there's a storage admin and a storage architect, and then there's a compute admin or BM admin or a security admin, that's really not who are driving this because if you look at that—that world really thinks in terms of infrastructure first.
The conversation covers:
Links
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.
Emily: Welcome to The Business of Cloud Native. I'm Emily Omier, your host, and today I am chatting with Kevin Crawley. And Kevin actually has two jobs that we're going to talk about. Kevin, can you sort of introduce yourself and what your two roles are?
Kevin: First, thank you for inviting me on to the show Emily. I appreciate the opportunity to talk a little bit about both my roles because I certainly enjoy doing both jobs. I don't necessarily enjoy the amount of work it gives me, but it also allows me to explore the technical aspects of cloud-native, as well as the business and marketing aspects of it. So, as you mentioned, my name is Kevin Crawley. I work at a company called Containous. They are the company who created Traefik, the cloud-native load balancer.
We've also created a couple other projects, and I'll talk a little bit about those later. For Containous, I'm a developer advocate. I work both with the marketing team and the engineering team. But also I moonlight as a co-founder and a co-owner of Single Music. And there, I fulfill mostly SRE type duties and also architect duties where a lot of times people will ask me feedback, and I'll happily share my opinion. And Single Music is actually based out of Nashville, Tennessee, where I live, and I started that with a couple friends here.
Emily: Tell me actually a little bit more about why you started Single Music. And what do you do exactly?
Kevin: Yeah, absolutely. So, the company started out of really an idea that labels and artists—and these are musicians if you didn't pick up on the name Single Music—we saw an opportunity for those labels and artists to sell their merchandise through a platform called Shopify to have advanced tools around selling music alongside that merchandise. And at the time, which was in 2016, there weren't any tools really to allow independent artists and smaller labels to upload their music to the web and sell it in a way in which could be reported to the Billboard charts, as well as for them to keep their profits. At the time, there was really only Apple Music, or iTunes. And iTunes keeps a significant portion of an artist's revenue, as well as they don't release those funds right away; it takes months for artists to get that money.
And we saw an opportunity to make that turnaround time immediate so that the artists would get that revenue almost instantaneously. And also we saw an opportunity to be more affordable as well. So, initially, we offered that Shopify integration—and they call those applications—and that would allow those store owners to distribute that music digitally and have those sales reported in Nielsen SoundScan, and that drives the Billboard Top 100. Now since then, we've expanded quite considerably since the launch.
We now report on sales for physical merchandise as well. Things like cassette tapes, and vinyl, so records. And you'd be surprised at how many people actually still buy cassette tapes. I don't know what they're doing with them, but they still do. And we're also moving into the live streaming business now, with all the COVID stuff going on, and there's been some pretty cool events that we've been a part of since we started doing that, and bands have gotten really elaborate with their live production setups and live streaming.
To answer the second part of your question, what I do for them, as I mentioned, I mostly serve as an advisor, which is pretty cool because the CTO and the developers on staff, I think there's four or five developers now working on the team, they manage most of the day-to-day operations of the platform, and we have, like, over 150 Kubernetes pods running on an EKS cluster that has roughly, I'd say, 80 cores and 76 gigabytes of RAM. That is around, I'd say about 90 or 100 different services that are running at any given time, and that's across two or three environments, just depending on what we're doing at the time.
Emily: Can you tell me a little bit about the sort of technical evolution at Single? Did you start in 2016 on Kubernetes? That's, I suppose, not impossible.
Kevin: It's not impossible, and it's something we had considered at the time. But really, in 2016, Kubernetes, I don't even think there wasn't even a managed offering of Kubernetes outside of Google at that time, I believe, and it was still pretty early on in development. If you wanted to run Kubernetes, you were probably going to operate it on-premise, and that just seemed like way too high of a technical burden. At the time, it was just myself and the CTO, the lead developer on the project, and also the marketing or business person who was also part of the company. And at that time, it was just deemed—it was definitely going to solve the problems that we were anticipating having, which was scaling and building that microservice application environment, but at the time, it was impractical for myself to manage Kubernetes on top of managing all the stuff that Taylor, the CTO, had to build to actually make this product a reality.
So, initially, we launched on Docker Swarm in my garage, on a Dell R815, which was like a, I think was 64 cores and 256 gigs of RAM, which was, like, overkill, but it was also, I think it cost me, like, $600. I bought it off of Craigslist from somebody here in the area. But it served really well as a server for us to grow into, and it was, for the most part, other than electricity and the internet connection into m...
The conversation covers:
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...
The conversation covers:
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.
Emily: Welcome to The Business of Cloud Native. I'm your host Emily Omier. And today I'm chatting with Jón Eðvald. And, Jón, thank you so much for joining me.
Jón: Thank you so much for having me. You got the name pretty spot on. Kudos.
Emily: Woohoo, I try. So, if you could actually just start by introducing yourself and where you work in Garden, that would be great.
Jón: Sure. So, yeah, my name is Jón, one of the founders, and I’m the CEO of Garden. I've been doing software engineering for more years than I'd like to count, but Garden is my second startup. Previous company was some years ago; dropped out of Uni to start what became a natural language processing company. So, different sort of thing than what I'm doing now.
But it's actually interesting just to scan through the history of how we used to do things compared to today. We ran servers out of basically a cupboard with a fan in it, back in the day, and now, things are done somewhat differently. So, yeah, I moved to Berlin, it's about four years ago now, met my current co-founders. We all shared a passion and, I guess to some degree, frustrations about the general developer experience around, I guess, distributed systems in general. And now it's become a lot about Kubernetes these days in the cloud-native world, but we are interested in addressing common developer headaches regarding all things microservices.
Testing, in particular, has become a big part of our focus. Garden itself is an open-source product that aims to ease the developer experience around Kubernetes, again, with an emphasis on testing. When we started it, there wasn't a lot of these types of tools around, or they were pretty early on. Now there's a whole bunch of them, so we're trying to fit into this broad ecosystem. Happy to expand on that journey. But yeah, that's roughly—that's what Garden is, and that’s… yeah, a few hop-skips of my history as well.
Emily: So, tell me a little bit more about the frustration that led you to start Garden. What were you doing, and what were you having trouble doing, basically?
Jón: So, when I first moved to Berlin, it was to work for a company called Clue. They make a popular period tracking app. So, initially, I was meant to focus on the data science and data engineering side of things, but it became apparent that there was a lot of need for people on the engineering side as well. So, I gravitated into that and ended up managing the engineering team there. And it was a small operation. We had more than a million daily active users yet just a single back end developer, so it was bursting at the seams.
And at the time running a simple Node.js backend on Heroku, single Postgres database, pretty simple. And I took that through—first, we adopted containers and moved into Docker Cloud. Then Docker Cloud disappeared, or was terminated without—we had to discover that by ourselves. And then Kubernetes was manifesting as the de facto way to do these things. So, we went through that transition, and I was kind of surprised. It was easy enough to get going and get to a functional level with Kubernetes and get everything running and working. The frustration came more from just the general developer experience and developer productivity side. Specifically, we found it very difficult to test the whole application because we had, by the end of that journey, a few different services doing different things. And for just the time you make a simple change to your code to it actually having been built, deployed, and ultimately tested was a rather tedious experience. And I found myself building tools, bespoke tools to be able to deal with that, and that ended up being sort of a janky prototype of what Garden is today. And I realized that my passion was getting the better of me, and we wanted to start a company to try and do better.
Emily: Why do you think developer experience matters?
Jón: Beyond just the, kind of, psychological effect of having to have these long and tedious feedback loops—just as a developer myself, it kind of grinds and reduces the overall joy of working on something. But in more concrete material terms, it really limits your productivity. You basically, you take—if your feedback loop is 10 times longer than it should be, that exponentially reduces the overall output of you as an individual or your team. So, it has a pretty significant impact on just the overall productivity of a company.
Emily: And, in fact, it seems like a lot of companies move to Kubernetes or adopt distributed systems, cloud-native in general, precisely to get the speed.
Jón: And, yeah, that makes sense. I think it's easy to underestimate all the, what are often called these day-two problems, when—so, it's easy enough to grok how you might adopt Kubernetes. You might get the application working, and you even get to production fairly quickly, and then you find that you've left a lot of problems unsolved, that Kubernetes by itself doesn't really address for you. And it's often conflated by the fact that you may be actually adopting multiple things at the same time. You may be not only transitioning to Kubernetes from something analogous, you may be going from simpler, bespoke processes, or you might have just a monolith that didn't really have any complicated requirements when it comes to dev tooling and dev setups. So, yeah, you might be adopting microservices, containers, and Kuberne...
Some of the highlights of the show include:
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.
Emily: Welcome to the Business of Cloud Native. I'm your host, Emily Omier, and today I'm here with Ricardo Rocha. Ricardo, thank you so much for joining us.
Ricardo: It's a pleasure.
Emily: Ricardo, can you actually go ahead and introduce yourself: where you work, and what you do?
Ricardo: Yeah, yes, sure. I work at CERN, the European Organization for Nuclear Research. I'm a software engineer and I work in the CERN IT department. I've done quite a few different things in the past in the organization, including software development in the areas of storage and monitoring, and also distributed computing. But right now, I'm part of the CERN Cloud Team, and we manage the CERN private cloud and all the resources we have. And I focus mostly on networking and containerization, so Kubernetes and all these new technologies.
Emily: And on a day to day basis, what do you usually do? What sort of activities are you actually doing?
Ricardo: Yeah. So, it's mostly making sure we provide the infrastructure that our physics users and experiments require, and also the people on campus. So, CERN is a pretty large organization. We have around 10,000 people on-site, and many more around the world that depend on our resources. So, we operate private clouds, we basically do DevOps-style work. And we have a team dedicated for the Cloud, but also for other areas of the data center. And it's mostly making sure everything operates correctly; try to automate more and more, so we do some improvements gradually; and then giving support to our users.
Emily: Just so everyone knows, can you tell a little bit more about what kind of work is done at CERN? What kind of experiments people are running?
Ricardo: Our main goal is fundamental research. So, we try to answer some questions about the universe. So, what's dark matter? What's dark energy? Why don't we see antimatter? And similar questions. And for that, we build very large experiments.
So, the biggest experiment we have, which is actually the biggest scientific experiment ever built, is the Large Hadron Collider, and this is a particle accelerator that accelerates two beams of protons in opposite directions, and we make them collide at very specific points where we build this very large physics experiments that try to understand what happens in these collisions and try to look for new physics. And in reality, what happens with these collisions is that we generate large amounts of data that need to be stored, and processed, and analyzed, so the IT infrastructure that we support, it’s larger fraction dedicated to this physics analysis.
Emily: Tell me a little bit more about some of the challenges related to processing and storing the huge amount of data that you have. And also, how this has evolved, and how it pushed you to think about containerization.
Ricardo: The big challenge we have is the amount of data that we have to support. So, these experiments, each of the experiments, at the moment of the collisions, it can generate data in the order of one petabyte a second. This is, of course, not something we can handle, so the first thing we do, we use these hardware triggers to filter this data quite significantly, but we still generate, per experiment, something like a few gigabytes a second, so up to 10 gigabytes a second. And this we have to store, and then we have large farms that will handle the processing and the reconstruction of all of this. So, we've had these sort of experiments since quite a while, and to analyze all of this, we need a large amount of resources, and with time.
If you come and visit CERN, you can see a bit of the history of computing, kind of evolving with what we used to have in the past in our data center. But it's mostly—we used to have large mainframes, that now it's more in the movies that we see them, but we used to have quite a few of those. And then we transitioned to physical commodity hardware with Linux servers. Eventually introduced virtualization and private clouds to improve the efficiency and the provisioning of these resources to our users, and then eventually, we moved to containers and the main motivation is always to try to be as efficient as possible, and to speed up this process of provisioning resources, and be more flexible in the way we assign compute and also storage.
What we've seen is that in the move from physical to virtualization, we saw that the provisioning and maintenance got significantly improved. What we see with containerization is the extra speed in also deployment and update of the applications that run on those resources. And we also see an improving resource utilization. We already had the possibility to improve quite a bit with virtualization by doing things like overcommit, but with containers, we can go one step further by doing more efficient resource sharing for the different applications we have to run.
Emily: Is the amount of data that you're processing stable? Is it steadily increasing, have spikes, a combination?
Ricardo: So, the way it works is, we have what we call ‘beam’ which is when we actually have protons circulating in the accelerator. And during these periods, we try to get as much collisions as ...
Highlights from this episode include:
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.
Emily: Welcome to The Business of Cloud Native. I'm Emily Omier, your host, and today I'm here with Andy Waroma. Andy, I just wanted to start with having you introduce yourself.
Andy: Yeah, hi. Thanks, Emily for having me on your podcast. My name is Andy Waroma, and I'm based in Singapore, but originally from Finland. I've been [unintelligible] in Singapore for about 20 years, and for 11 years I spent with a company called SAP focusing on business software applications. And then more recently, about six years ago, I co-founded together with my ex-colleague from SAP, a company called Cloud Comrade, and we have been running Cloud Comrade now for six years and Cloud Comrade focuses on two things: number one, on cloud migrations; and number two, on cloud managed services across the Southeast Asia region.
Emily: What kind of things do you help companies understand when you're helping with cloud migrations? Is this like, like, a lift and shift? To what extent are you helping them change the architecture of their applications?
Andy: Good question. So, typically, if you look at the Southeast Asian market, we are probably anywhere between one to two years behind that of the US market. And I always like to say that the benefit that we have in Southeast Asia is that we have a time machine at our disposal. So, whatever has happened in the US in the past 18 months or so it's going to be happening also in Singapore and Southeast Asia. And for the first three to four years of this business, we saw a lot of lift and shift migrations, but more recently, we have been asked to go and containerize applications to microservices, revamp applications from monolithic approach to a much more flexible and cloud-native approach, and we just see those requirements increasing as companies understand what kind of innovation they can do on different cloud platforms.
Emily: And what do you think is driving, for your clients, this desire to containerize applications?
Andy: Well, if you asked me three months ago, I probably would have said it's about innovation, and business advantage, and getting ahead in the market, and investing in the future. Now, with the global pandemic situation, I would say that most companies are looking at two things: they're looking at cost savings, and they are also looking at automation. And I think cost savings is quite obvious; most companies need to know how they can reduce on their IT expenditure, how they can move from CAPEX to OPEX, how they can be targeting their resources up and down depending on the business demand what they have. And at the same time, they're also not looking to hire a lot of new people into their internal IT organization. So, therefore, most of our customers want to see their applications to be as automated as possible. And of course, microservices, CI/CD pipelines, and everything else helps them to achieve that somewhat. But first and foremost, of course, it's about all services that Cloud provides in general. And then once they have been moving some of those applications and getting positive experiences, that's where we typically see the phase two kicking in, going into cloud-native microservices, containers, Kubernetes, Docker, and so forth.
Emily: And do you think when companies are going into this, thinking, “Oh, I'm going to really reduce my costs.” Do you think they're generally successful?
Andy: I don't think in a way that they think they are. So, especially if I'm looking at the Southeast Asian markets: Singapore, Malaysia, Thailand, Philippines, Indonesia, and perhaps other countries like Vietnam, Myanmar, and Cambodia, it’s a very cost-conscious market, and I always, also like to say that when we go into a meeting, the first question that we get from the customers, “How much?” It is not even what are we going to be delivering, but how much it's going to cost them. That's the first gate of assessment. So, it's very much of an on-premise versus clouds comparison in the beginning.
And I think if companies go in with that type of a mindset, that's not necessarily the winning strategy for them. What they will come to know after a while is that, for example, setting up disaster recovery systems on an on-premise environment, especially when a separate location is extremely expensive, and doing something like that on the Cloud is going to be very cost-efficient. And that's when they start seeing cost savings. But typically, what they will start seeing on Cloud is a process cost-saving, so how they can do things faster, quicker, and be more flexible in terms of responding to end-user demands.
Emily: At the beginning of the process, how much do you think your customers generally understand about how different the cost structure is going to be?
Andy: So, we have more than 200 customers, and we have done more than 500 projects over the six years, and there's a vast range of customers. We have done work with companies with a few people; we have done companies with Fortune 10 organizations, and everything in between, in all kinds of different industries: manufacturing, finance, insurance, public sector, industrial level things, nonprofits, research organizations. So, we can't really say that each customer are same. There are customers who are very sophisticated and they know exactly what they want when going to a cloud platform, but then there are, of course, many other customers who need to be advised much more in the beginning, and that’s where we typically...
Some highlights of the show include:
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 your host, Emily Omier, and today I am chatting with Paul Ingles. Paul, thank you so much for joining me.
Paul: Thank you for having me.
Emily: Could you just introduce yourself: where do you work? What do you do? And include, sort of, some specifics. We all have a job title, but it doesn't always reflect what our actual day-to-day is.
Paul: I am the CTO at a company called RVU in London. We run a couple of reasonably big-ish price comparison, aggregator type sites. So, we help consumers figure out and compare prices on broadband products, mobile phones, energy—so in the UK, energy is something which is provided through a bunch of different private companies, so you've got a fair amount of choice on kind of that thing. So, we tried to make it easier and simpler for people to make better decisions on the household choices that they have. I've been there for about 10 years, so I've had a few different roles. So, as CTO now, I sit on the exec team and try to help inform the business and technology strategy. But I've come through a bunch of teams. So, I've worked on some of the early energy price comparison stuff, some data infrastructure work a while ago, and then some underlying DevOps type automation and Kubernetes work a couple of years ago.
Emily: So, when you get in to work in the morning, what types of things are usually on your plate?
Paul: So, I keep a journal. I use bullet journalling quite extensively. So, I try to track everything that I’ve got to keep on top of. Generally, what I would try to do each day is catch up with anybody that I specifically need to follow up with. So, at the start of the week, I make a list of every day, and then I also keep a separate column for just general priorities.
So, things that are particularly important for the week, themes of work going on, like, technology changes, or things that we're trying to launch, et cetera. And then I will prioritize speaking to people based on those things. So, I'll try and make sure that I'm focusing on the most important thing. I do a weekly meeting with the team. So, we have a few directors that look after different aspects of the business, and so we do a weekly meeting to just run through everything that's going on and sharing the problems. We use the three P's model: so, sharing progress problems and plans. And we use that to try and steer on what we do. And we also look at some other team health metrics.
Yeah, it's interesting actually. I think when I switched from working in one of the teams to being in the CTO role, things change quite substantially. That list of things that I had to care about increase hugely, to the point where it far exceeded how much time I had to spend on anything. So, nowadays, I find that I'm much more likely for some things to drop off. And so it's unfortunate, and you can't please everybody, so you just have to say, “I'm really sorry, but this thing is not high on the list of priorities, so I can't spend any time on it this week, but if it's still a problem in a couple of weeks time, then we'll come back to it.” But yeah, it can vary quite a lot.
Emily: Hmm, interesting. I might ask you more questions about that later. For now, let's sort of dive into the cloud-native journey. What made RVU decide that containerization was a good idea and that Kubernetes was a good idea? What were the motivations and who was pushing for it?
Paul: That's a really good question. So, I got involved about 10 years ago. So, I worked for a search marketing startup that was in London called Forward Internet Group, and they acquired USwitch in 2010. And prior to working at Forward, I'd worked as a consultant at ThoughtWorks in London, so I spent a lot of time working in banks on continuous delivery and things like that. And so when Uswitch came along, there were a few issues around the software release process. Although there was a ton of automation, it was still quite slow to actually get releases out. We were only doing a release every fortnight. And we also had a few issues with the scalability of data.
So, it was a monolithic Windows Microsoft stack. So, there was SQL Server databases, and .NET app servers, and things like that. And our traffic can be quite spiky, so when companies are in the news, or there's policy changes and things like that, we would suddenly get an increase in traffic, and the Microsoft solution would just generally kind of fall apart as soon as we hit some kind of threshold. So, I got involved, partly to try and improve some of the automation and release practices because at the search start-up, we were releasing experiments every couple of hours, even.
And so we wanted to try and take a bit of that ethos over to Uswitch, and also to try and solve some of the data scalability and system scalability problems. And when we got started doing that, a lot of it was—so that was in the early heyday of AWS, so this was about 2008, that I was at the search startup. And we were used to using EC2 to try and spin up Hadoop clusters and a few other bits and pieces that we were playing around with. And when we acquired Uswitch, we felt like it was quickest for us to just create a different environment, stick it under the load balancer so end users wouldn't realize that some requests was being served off of the AWS infrastructure instead, and then just gradually go from there. We found that that was just the fastest way to move.
So, I think it was interesting, and it was both a deliberate move, but it was also I think the degree to which we followed through on it, I don't think we'd really anticipated quite how quickly we would shift everything. And so when Forward made the acquisition, I joined summer of 2010, and myself and a colleague wrote ...
Some of the highlights include:
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 am chatting with Tom Kivlin. Tom, thank you so much for joining us.
Tom: You're welcome. No problem.
Emily: Let's just start out with having you introduce yourself. What do you do? Where do you work, and what do you actually do during your workday?
Tom: Sure. So, I'm a principal cloud orchestration architect at Vodafone Group. I work in the UK. And my day job consists of providing guidance and strategy and architectural blueprints for cloud-native platforms within Vodafone. So, that's around providing guidance to the software domains that are looking to adopt cloud-native architectures and methodologies and also to the more traditional infrastructure domains to try and help them provide their services in a more cloud-native manner to those modern teams.
Emily: And what does that mean when you go into the office—or your home office, go into your dining room where your laptop is, I don't know—what do you actually do? What does an average day look like?
Tom: It can vary. So, depending on the activity at the time, it could be anything from preparing a global policy that needs to go through the senior technology leadership team, to preparing some extremely detailed requirements for selection process or creating some infrastructures code, or the code artifacts for the deployment of cloud-native services, whether that's in our lab, or to help our services teams within Vodafone.
Emily: Tell me a little bit more about what pain made Vodafone think about moving to cloud-native and Kubernetes.
Tom: Primarily, it was the challenge of having 25 different markets, or 23 now. We launched a digital strategy to—so back in 2015, we launched a five-year strategy, which we wanted to massively increase the rollout of 4G, of converged network offerings, of improved customer experience. And we found that the traditional way of managing software was not supportive enough in our ambition. And so, having to choose cloud-native technologies, things like Kubernetes, but also the modern operating models, that was the driver: it was to improve our customer experience, and our customer-affecting KPIs, really.
Emily: And when you say it wasn't supportive enough, what do you mean specifically?
Tom: So, things like time to market, for example. So, if we wanted to offer a new service—so one of the things that 4G started the drive towards was a more granulated service offering to consumers, and so lots of different things could be offered. And if it took you six months to think of an idea and then have to go through—or even longer than six months to get to the point where that could be offered to customers, even if it was just a very minor feature within an existing product, then that's not going to engender customer loyalty. And so, things like the cloud-native mindset, where there's a much closer link between the engineering teams and the customer, there are much shorter periods of time between ideas coming in from the customers and then being delivered back to the customers as product features, that sort of time to market was really enabled by cloud-native technologies and mindsets.
Emily: And how does having two dozen, more or less, different markets, how does that play into the decision A) to move to cloud-native in general, and managing the IT infrastructure?
Tom: So, one of the things that's really driven it is trying to simplify and reuse artifacts. So, if you've got 23 markets all doing a different thing, then there's obviously a lot of duplication happening across the group, whereas if everyone's using the same technology in the same platforms—take Kubernetes as the example—everyone can write their software for that platform. Everyone can write their operational ecosystem around that platform. So, the deployment artifacts, the pipelines, the day two operational activities, they can all be based around that single cloud-native platform. And so, that enables a huge amount of efficiency from the operational side. And that in turn allows those engineering teams to focus on things that are adding value to the business and the customer instead of having to focus on fairly low-level tasks that are just keeping the lights on, if you like.
Emily: What's different for each one of those markets?
Tom: So, it might be something like language, it might be something as simple as that. It may be that the offerings are slightly tweaked. So, rather than, I don't know, as an example, rather than Spotify being included as a kind of add on, it might be some other service that's more relevant to that market. It may be that there are particular regulatory requirements that are specific to a market that needs to be considered within the product design and the engineering of it. And so, having a cloud-native response allows sharing and reuse of artifacts where we can, but still allows for that customization where it's required.
Emily: Where would you say Vodafone is in the cloud-native journey? Do you feel like you've, mission accomplished?
<...
This conversation covers:
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 your host, Emily Omier, and I'm here today with Travis Rehl, who is the director of product at CloudCheckr. Travis, I just wanted to start out, first of all, by saying thank you for joining me on the show. And second of all, if you could just start off by introducing yourself. What you do, and by that I mean, what does an actual day look like? And some of your background?
Travis: Yeah. Well, thanks for having me. So yeah, I'm Travis Rehl, director of product here at CloudCheckr. What that really means is, I have the fun job of figuring out what should the business do next in relation to our product offering here at the business. That means roadmap, looking at the market, what are customers doing differently now, or planning to do differently over the next year, two years or so, on cloud? What their cost strategies are, what their invoicing and chargeback strategies are, all that type of fun stuff, and how we can help accommodate those particular strategies using our product offering.
Sort of, day to day, though, I would say that a bunch of my time during the day is spent talking to customers, figuring out where they are in their cloud journey, if you will, what programs or projects they may have in flight that are interesting, or complicated, or they need help on. Especially making any sort of analysis help in particular, and then lastly, taking all that information and packaging it up neatly, so that the business can make a decision to add functionality to our product in some way that can assist them move forward.
Emily: The first question I wanted to ask is actually if you could talk just a little bit about the distinction between cloud-native, and cloud computing, and operating in the cloud. What do all of those things actually mean, and where's the delta between them?
Travis: Sure. Yeah so, it's actually kind of interesting, and you'll hear it a little bit differently from different people. In my background, in particular—I used to run an engineering department for a managed service provider. And so we used to do a lot of project planning of companies as to what's their strategy for their software deployment of some kind on cloud. And typically the two you see for, say, cloud-native versus operating in the cloud, operating on the cloud is very atypical.
You'd associate that to something like lift and shift—probably hear about a lot—the concept of taking your on-prem workload and simply cloning it, or taking it in some way and copying in some way, on to the cloud-native vendor in particular. So, literally just standing up servers of clones of hard drives and so forth, and emulating what you had on-prem, but on the cloud. That's a great technique for moving quickly to cloud. That's not a great technique if you want to be cloud-native. So, that's really the big segue for cloud-native, in particular, is you want to build a software solution that takes advantage of cloud-only technology, meaning serverless compute resources, meaning auto-scaling different types of services themselves, stuff you probably didn't have when you're on-prem originally, that you now have, you can take advantage of on the cloud. That's almost like a redesign, or reimplementation around those models that cloud itself provides to you. That, to me, is the big difference. And I see oftentimes that gap-wise, many companies who are starting on-prem, they will do the migration to cloud first, the lift and shift model, and then they will decide, “Hey, I want to redesign pieces of it to make it more cloud-native.” And then you'll see startups who don't have on-prem at all, they will just go into cloud-native from the get-go.
Emily: Of course, CloudCheckr specializes in helping with costs among some other things, but how do costs fit into this journey, and what sort of cost-related concerns do companies have as they're on this cloud journey?
Travis: Yeah, so there's a few. I would actually say that years ago—just to clarify, the discussion has changed over the last few years—but years ago, it started with CapEx versus OpEx costs, specifically for purchasing of your IT services. On-prem, you'd probably purchase up-front a bulk number of VMs or servers or otherwise, for a number of years, and so be a CapEx cost. When you moved over to cloud and more of this, usage-based, model kind of threw a lot of people for a loop when it came to more OpEx usage space models. AWS, Azure, GCP have helped in that regard with things like reserved instances for companies who are more CapEx oriented as well, but in terms of the initial years ago, a big hurdle was communicating that difference and how the business may pay for these services. And a lot of people were very interested in moving to OpEx back then, in particular.
When it came to how do you take into account all these cost-related changes the business may go through, one of the big ones that I see most recently is around the transference and storage of data. In the past, it would have been about how much money total am I going to spend on the cloud itself. Now, it's about what am I forecasting to spend based off of those usage patterns. It's a bit easier to forecast those things when you have servers that run for a period of time, but when you have usage patterns for data ingestion, for data transfer, for servers spinning up and spinning down and scaling out horizontally, ...
Some of the highlights of the show include:
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 your host, Emily Omier, and today I am chatting with Dave Mangot. And Dave is a consultant who works with companies on improving their web operations. He has experience working with a variety of companies making the transition to cloud-native and in various stages of their cloud computing journey. So, Dave, my first question is, can you go into detail about, sort of, the nitty-gritty of what you do?
Dave: Sure. I've spent my whole technical professional career mostly in Silicon Valley, after moving out to California from Maryland. And really, I got early into web operations working in Unix systems administration as a sysadmin, and then we all changed the names of all those things over the years from sysadmin to Technical Infrastructure Engineer, and then Site Reliability Engineer, and all the other fun stuff. But I've been involved in the DevOps movement, kind of, since the beginning, and I've been involved in cloud computing, kind of, since the beginning.
And so I'm lucky enough in my day job to be able to work with companies on their, like you said, transitions into Cloud, but really I'm helping companies, at least for their cloud stuff, think about what does cloud computing even mean? What does it mean to operate in a cloud computing manner? It's one thing to say, “We're going to move all of our stuff from the data center into Cloud,” but most people you'll hear talk about lift and shift; does that really the best way? And obviously, it's not. I think most of the studies will prove that and things like the State of DevOps report, and those other things, but really love working with companies on, like, what is so unique about the Cloud, and what advantages does that give, and how do we think about these problems in order to be able to take the best advantage that we can?
Emily: Dive into a little bit more. What is the difference between cloud computing and cloud-native? And where does some confusion sometimes seep in there?
Dave: I think cloud-native is just really talking about the fact that something was designed specifically for running in a cloud computing environment. To me, I don't really get hung up on those differences because, ultimately, I don't think they matter all that much. You can take memcached, which was designed to run in the data center, and you can buy that as a service on AWS. So, does that mean because it wasn't designed for the Cloud from the beginning, that it's not going to work? No, you're buying that as a service from AWS.
I think cloud-native is really referring to these tools that were designed with that as a first-class citizen. And there's times where that really matters. I remember, we did an analysis of the configuration management tools years back, and what would work best on AWS and things like that, and it was pretty obvious that some of those tools were not designed for the Cloud. They were not cloud-native. They really had this distinct feel that their cloud capabilities were bolted on much later, and it was clunky, and it was hard to work with, whereas some of the other tools, really felt like that was a very natural fit, like that was the way that they had been created. But ultimately, I think the differences aren't all that great, it just, really, matters how you're going to take advantage of those tools.
Emily: And with the companies that you work with, what is the problem or problems that they are usually facing that lead them to hire you?
Dave: Generally the question, or the statement, I guess, that I get from the CIOs and CTOs, and CEOs is, “My production web operations team can't keep up with my development teams.” And there's a lot of reasons why those kinds of things can happen, but with the dawn of all these cloud-native type things, which is pretty cool, like containers, and all this other stuff, and CI/CD is a big popular thing now, and all kinds of other stuff. What happens, tends to be is the developers are really able to take advantage of these things, and consume them, and use them because look at AWS. AWS is API, API, API. Make an API call for this, make an API call for that.
And for developers, they're really comfortable in that environment. Making an API call is kind of a no brainer. And then a lot of the operations teams are struggling because that's not normal for them. Maybe they were used to clicking around in a VMware console, and now that's not a thing because everything's API, API, API. And so what happens is the development teams start to rocket ahead of the operations teams, and the operations teams are running around struggling to keep up because they're kind of in a brand new world that the developers are dragging them into, and they have to figure out how they're going to swim in that world.
And so I tend to work with operations teams to help them get to a point where they're way more comfortable, and they're thinking about the problems differently, and they're really enabling development to go as quickly as development wants to go. Which, you know, that's going to be pretty fast, especially when you're working with cloud-native stuff. But I mean, kind of to the point earlier, we built—at one of the companies I worked at years ago—what I would say, like, a cloud environment in a data center, where everything was API first, and you didn't have to run around, and click in consoles, and try to find information, and manually specify things, and stuff like that; it just worked. Just like if you make a call for VM in AWS, an EC2 instance. And so, really, it's much more about the way that we look at the problems, then it is about where this thing happens to be located because obviously cloud-native is going to be Azure, it's going ...
This conversation covers:
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 am chatting with Abhinav Srivastava. Abhinav, can you go ahead and introduce yourself and tell us about where you work, and what you do.
Abhinav: Thanks for having me, Emily. Hello, everyone. My name is Avinash Srivastava. I'm a VP and the head of information security and infrastructure at Frame.io. At Frame, I am building the security and infrastructure programs from ground up, making sure that we are secured and compliant, and our services are available and reliable. Before joining Frame.io, I spent a number of years in AT&T Research. There I worked on various cloud and security technologies, wrote numerous research papers, and filed patents. And before joining AT&T, I spent five great years in Georgia Tech on a Ph.D. in computer science. My dissertation was on cloud and virtualization security.
Emily: And what do you do? What does an average day look like?
Abhinav: Right. So, just to tell you where I answer the question where I work: so I work at Frame.io, and Frame.io is a cloud-based video review and collaboration startup that allows users to securely upload their video contents to our platform, and then invite teams and clients to collaborate on those uploaded assets. We are essentially building the video cloud, so you can think of us as a GitHub for videos.
What I do when I get to office—apart from getting my morning coffee—as soon as I arrive at my desk, I check my calendar to see how's my day looking; I check my emails and slack messages. We use slack primarily within the company doing for communication. And then I do my daily standup with my teams. We follow a two-week sprint across all departments that I oversee. So, a standup gives me a good picture on the current priorities and any blockers.
Emily: Tell me a little bit about the cloud-native journey at Frame.io? How did the company get started with containers, and what are you using to orchestrate now? How have you moved along in the cloud-native journey?
Abhinav: We are born in the cloud, kind of, company. So, we are hosted in Amazon AWS since day one. So, we are in the cloud from the get-go. And once you are in the cloud, it is hard not to use tools and technologies that are offered, because our goal has always been to build secure, reliable, and available infrastructure. So, we were very, very mindful from the get-go that while we are in the cloud, we can choose to be cloud-native or just cloud-enabled. Means use tools, just virtual machines, or heavyweight virtual machines, and not to use container and just host our entire workload within that.
But we chose to be cloud-native because, again, they wanted to boot up or spin up new containers very fast. As a platform we, as I mentioned, we allow users to upload videos, and once the videos are uploaded, we have to transcode those videos to generate different low-resolution videos. And that use case fits with the lightweight container model. So, from the get-go, we started using containerized microservices; orchestration layer; From AWS, their auto-scaling; automation infrastructure as a code; monitoring. so all those things were, kind of, no brainer for us to use because given our use case and given the way we wanted to be a very fast uploader and transcoder for all of our customers.
Emily: This actually leads me to another question: have you guys seen a lot of scaling recently as a result of stay-at-home orders and work from home?
Abhinav: Right. So, we are seeing a lot more people moving towards remote collaboration tools who are actually working in the production house since they have to work from home now. So, they are now moving to these kind of tools such as Frame.io. And we do see a lot more customers joining our platform because of that. From the traffic perspective, we did not see much increase in the web traffic or load our infrastructure, because we have always set up the auto-scaling and our infrastructure can always meet these peak demands. So, we didn't see any adverse effect on our infrastructure from these remote situations.
Emily: What were some of the other advantages? Like you were talking about that you had the choice to be either cloud-enabled or truly cloud-native? What were the biggest, you know—and I'm interested, obviously in business rationale to the extent you can talk about it—for being truly cloud-native?
Abhinav: So, from business perspective, again, a goal was to [basic] secure available and reliable production infrastructure to offer Frame.io services. But cloud-native actually helped us to faster time to market because our developers are just focusing on the business logic, deploying code. They were not worried about the infrastructure aspect, which is good. Then we’re rolling out bug fixes very quickly through CI/CD platform, so that, again, we offer the better [good] services to our customer.
Cloud-native helped us to meet our SLA and uptime so that our customer can access their content whenever they would like to. It also helped us securing our infrastructure and services, and our cost also went down because we were scaling up and down based on the peak demand, and we don't have to provide dedicated resources, so that's good there. And it also allowed us to faster onboard developers to our platform because we are using a lot of open source technologies, and so the developers can learn q...
In this episode of the Business Cloud Native, host Emily Omier talks with Jon Tirsen, who is engineering lead for storage at Cash App. This conversation focuses on Cash App’s cloud native journey, and how they are working to build an application that is more scalable, flexible, and easier to manage.
The conversation covers:
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. My name is Emily Omier, I'm here chatting with Jon Tirsen.
Jon: Happy to be here. My name is, as you said, Jon Tirsen, and I work as the engineering lead of storage here at Cash App. I've been at Cash for maybe four or five years now. So, I've been with it from the very early days. And before Cash, I was doing a startup, that failed, for five years. So, it's a travel guide in the mobile phone startup. And before that, I was at Google working on another failed product called the Google Wave, which you might remember, and before that, it was a company called ThoughtWorks, which some of you probably know about as well.
Emily: And in case people don't know, the Cash App is part of Square, right?
Jon: Yes. Cash App is where we're separating all the different products quite a lot these days. So, it used to be called just Square Cash, but now it has its own branding and its own identity, and its own leadership, and everything. So, we're trying to call it an ecosystem of startups. So, each product line can run its business the way it wants to, to a large degree.
Emily: And so, what do you actually spend your day doing?
Jon: Most of my days, I'm still code, and doing various operational tasks, and setting up systems, and testing, and that sort of thing. I also, maybe about half my day, I spend on more management tasks, which is reviewing documents, writing documents, and talking to people trying to figure out our strategy and so on. So, maybe about half my time, I do real technical things, and then the other half I do more management stuff.
Emily: Where would you say the cloud-native journey started for you?
Jon: Well, so a lot of Square used to run on-premises. So, we had our own data centers and things. But especially for Cash App, since we've grown so quickly, it started getting slightly out of control. We were basically outgrowing—we could not physically put more machines into our data centers. So, we've started moving a lot of our services over to Amazon in this case, and we want to have a shared way of building services that would work both in the Cloud and also in our data centers.
So, something like Kubernetes and all the tools around that would give us a more uniform programming model that we could use to deploy apps in both of these environments. We started that, two, three years ago. We started looking at moving our workload out of our data centers.
Emily: What were the issues that you were encountering? Give me a little bit more details about the scaling issues that we were talking about.
Jon: There two dimensions that we needed to scale out the Cash App, sort of, system slash [unintelligible] architecture. So, one thing was that we just grew so quickly that we needed to be able to increase capacity. So, that was across the board. So, from databases to application servers, and bandwidth, everywhere. We need to just be able to increase our capacity of handling more users, but also we were trying to grow our product as well. So, at the same time, we also want to build and be able to add new features at an increased pace. So, we want to be able to add new product lines in the Cash App.
So, for example, we built the Cash Card, which is a way you can keep your money in the Cash App bank accounts, and then you can spend that money using a separate card, and then we add a new functionality around that card, and so on. So, we also needed to be able to scale out the team to be able to have more people working on the team to build new products for our users, for our customers. Those are the two dimensions: we needed to scale out the system, but we also needed to have more people be able to work productively. So, that's why we started trying to chop up—we have this big monolith as most companies probably do, which that's I don't know how many hundreds of thousands of lines of code in there. But we also wanted to move things out of that, to be able to have more people contribute productively.
Emily: And where are you in that process?
Jon: Well, [laughs], we're probably adding still adding code at an exponential rate to the monolith. We're also adding code at an exponential rate outside of the monolith, but it just feels so much easier to just build some code in the monolith than it is outside of it, unfortunately, which something we're trying to fix, but it's very hard. And it is getting a little bit out of hand, this monolith now. So, we have, sort of, a moratorium on adding new code to the monolith now, and I'm not sure how much of an effect that has made. But the monolith is still growing, as well as our non-monolith services as well, of course.
Emily: When you were faced with this scaling issue, what were the conversations happening between the technical side and the business owners? And how is this decision made about the best way to solve this problem is x, is the Cloud, is cloud-native architecture?
<...
Emily and Dejan cover the following points:
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, and I am talking with Dejan Deklich, from 8x8.
Dejan: So, I'm the Chief Product Officer at 8x8. To give you an idea, 8x8 is now 16 or 1700 employees worldwide, 450 million in revenue, give or take, offices all over the world, customers all over the world. I'm responsible for all product management, engineering, QA, project management operations for all the products worldwide for 8x8.
Emily: Can you give me a little bit of an idea of 8x8’s history in the Cloud?
Dejan: So, 8x8 has been around, probably, a lot longer than most companies you're talking about. We've been public 30 years, give or take. We have been in the business of communication and collaboration since early 2000s. As you can imagine, we have gone through so many different tech stacks, architectures, and so on, that it is pretty amazing.
We have, in the last several years, done a massive cleanup and rebuild of our software stack. We rebuilt pretty much all of the mobile apps, desktop apps, web apps. We rebuilt the platform starting with billing and provisioning all the way down to how the voice traverses the world. So, it's been a incredible couple of years, incredible journey where I would argue we have gone from the early versions of hosted service to early versions of Cloud, maybe 10 years ago, and we are now what I would like to call a proper cloud technology company. And it's been a very interesting, difficult journey. We learned a lot. We messed up a lot of things, then we learned some more than they did it correctly.
Emily: When you first moved to Kubernetes, and the modern public cloud, what was the rationale? What were their business reasons?
Dejan: Those multiple steps there. We moved to public cloud I don't know, five, six, seven years ago. We ran a lot of things in Amazon. And to be fair, we still also have data centers around the world. So, let me explain quickly what we actually running because I think it's important. So, we have, I think 16 data centers around the world, and then we run in pretty much every region of Amazon, we use Google Cloud extensively, and we have now shifted a lot of workloads to Oracle Cloud. At the same time, business is threatening me with Alibaba Cloud and Tencent Cloud as something that might be coming our way in the next couple of quarters. So, data centers are there because on the networking layer, the Cloud does not yet give us what we need for the realtime voice and video transmission.
We actually are the best voice provider in the industry. We have proven that, and that's where your milliseconds really matter, therefore networking still sits in data centers. As soon as the backbone can be moved into Amazon, and we are told that could happen in the next three to four years, we will move likely everything to the Cloud. So, what we have generally in the Cloud are different applications, and the reason for that is simply the velocity of deploying and scaling them.
So, what matters to us is, on one hand, the global reach: we have customers in 150 countries around the world. We have to have data centers close to the customers. And the applications need to be as close to the customer as possible, therefore all the different regions of Amazon, and Google, and whatnot. So, as you can imagine, managing all of that, monitoring all of that is a non-trivial exercise.
So, we moved to Kubernetes, in large reason, simply because it is one underlying framework that allows us to run workloads wherever we want. So, to give you an idea, we launched a video meetings product to compete with Zoom. We had, on launch, a couple of hundred thousand users, nothing really. And then, this COVID-19 happened, and within a period of weeks, we now hit 15 million users. The only way you can scale a system like that is if you have a properly built underlying architecture, everything horizontally scalable.
I was blown away, everything really worked. People were super busy, but by having proper cloud architecture, we were able to actually scale, and fulfill the demand that we have seen worldwide. Now, the nice thing is, as you put more and more workloads on top of Kubernetes, you can shift them between clouds as you want, or data centers as you want. And I think that's number one reason why we went with Kubernetes.
I love Amazon, I love Google, and nothing makes me happier than writing them a million-dollar checks, but I also want to be able to move the workloads wherever I can run them cheaply. And, to me, that's very important. I don't have unlimited budget; I have to be able to play the game and get the most compute and the most bandwidth for the lowest cost that I can, and Kubernetes lets me do that.
Emily: And would you say that Kubernetes was a technical decision or a business decision or both?
Dejan: That's a good question. I think normally, the way we operate at 8x8, you start with the business problem. The business problem was we don't want to be locked into one cloud. We want to be able to run wherever we want to run, and on top of that, we have customers in Europe who are not very friendly towards Amazon, and want us to run on other clouds. And then, we took a peek: what can we do? What's the fastest and easiest way to do it? Turned out it was Kubernetes, so that's the way we went.
Emily: What did the move to Kubernetes, what was it like? What were some of the surprises?
Dejan: It was very interesting. It is still very interesting. So, on one hand, the good thing was we have already broken the monoliths in the past God knows how many years, into services. But to get things running properly in Kubernetes, you have to go a bit deeper, you actually have to really clean up your code, and so on, and so on. So, one thing that I thought was incredibly useful was this allowed us to, for the first time in 8x8 history, create a proper template for a service where all yo...
Some of the highlights of the show include
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. My name is Emily Omier, and I am here with Austin Adams and Zack Arnold, and we are here to talk about why companies go cloud-native.
Austin: So, I'm currently the CTO of a small Agrotech startup called HerdX. And that means I spend my days designing software, designing architecture for how distributed systems talk, and also leading teams of engineers to build proof-of-concepts and then production systems as they take over the projects that I've designed.
Emily: And then, what did you do at Ygrene?
Austin: I did the exact same thing, except for without the CTO title. And I also had other higher-level engineers working with me at Ygrene. So, we made a lot of technical decisions together. We all migrated to Kubernetes together, and Zack was a chief proponent of that, especially with the culture change. So, I focused on the designing software that teams of implementation engineers could take over and actually build out for the long run. And I think Zack really focused on—oh, I'll let Zack say what he focused on. [laughs].
Emily: Go for it, Zach.
Zach: Hello. I'm Zack. I also no longer work for Ygrene, although I have a lot of admiration and respect for the people who do. It was a fantastic company. So, Austin called me up a while back and asked me to think about participating in a DevOps engineering role at Ygrene. And he sort of said at the outset, we don't really know what it looks like, and we're pretty sure that we just created a position out of a culture, but would you be willing to embody it?
And up until this point, I'd had cloud experience, and I had had software engineering experience, but I didn't really spend a ton of time focused on the actual movement of software from developer’s laptops to production with as few hiccups, and as many tests, and as much safety as possible in between. So, I always told people the role felt like it was three parts. It was part IT automation expert, part software engineer, and then part diplomat. And the diplomacy was mostly in between people who are more operations focused. So, support engineers, project managers, and people who were on-call day in and day out, and being a go-between higher levels of management and software engineers themselves because there's this awkward, coordinated motion that has to really happen at a fine-grained level in order to get DevOps to really work at a company.
What I mean by that is, essentially, Dev and Ops seem to on the surface have opposing goals, the operation staff, it’s job is to maintain stability, and the development side’s job is to introduce change, which invariably introduces instability. So, that dichotomy means that being able to simultaneously satisfy both desires is really a goal of DevOps, but it's difficult to achieve at an organizational level without dealing with some pretty critical cultural components. So, what do I spend my day on? The answer to that question is, yes. It really depends on the day. Sometimes it's cloud engineers. Sometimes it's QA folks, sometimes it's management. Sometimes I'm heads-down writing software for integrations in between tools. And every now and again, I get to contribute to open-source. So, a lot of different actual daily tasks take place in my position.
Emily: Tell me a little bit more about this diplomacy between software engineers and management.
Zach: [laughs]. Well, I'm not sure who's going to be listening in this amazing audience of ours, but I assume, because people are human, that they have capital O-pinions about how things should work, especially as it pertains to either software development lifecycle, the ITIL process of introducing change into a datacenter, into a cloud environment, compliance, security. There's lots of, I'll call them thought frameworks that have a very narrow focus on how we should be doing something with respect to software. So, diplomacy is the—well, I guess in true statecraft, it's being able to work in between countries. But in this particular case, diplomacy is using relational equity or influence, to be able to have every group achieve a common and shared purpose.
At the end of the day, in most companies the goal is actually to be able to produce a product that people would want to pay for, and we can do so as quickly and as efficiently as possible. To do that, though, it again requires a lot of people with differing goals to work together towards that shared purpose. So, the diplomacy looks like, aside from just having way too many meetings, it actually looks like being able to communicate other thought frameworks to different stakeholders and being able to synthesize all of the different narrow-focused frameworks into a common shared, overarching process. So, I'll give you a concrete example because it feels like I just spewed a bunch of buzzwords. A concrete example would be, let's say in the common feature that's being delivered for ABC Company, for this feature it requires X number of hours of software development; X number of hours of testing; X number of hours of preparing, either capacity planning, or fleet size recommendations, or some form of operational pre-work; and then the actual deployment, and running, and monitoring. So, in the company that I currently work for, we just...
Some highlights of the show include
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: So, I always start the same way. Can you introduce yourself?
Haojie: Hey, my name is Haojie Hang. I'm a product manager in the CTO office at Ant Financial. I work on the product and strategy side for, basically, the CTO and the other executive leaders, as well as leading a small product teams within the org to look at the frontier technology in the cloud and other infrastructure businesses.
Emily: And can you tell me a little bit more about what Ant Financial does? And then, also, what do you do on a day to day basis? What do you do when you get into the office?
Haojie: Yeah, I'll do a quick introduction about the Ant Financial business. It's not just one business or two business, it's a group of businesses that we innovate and we do, mostly in China, but we're also expanding very rapidly all over the world. So, Ant Financial is basically a group of businesses including credit for both consumers and the enterprise, as well as loan businesses, both consumer and enterprise businesses. We say that the parent organization is basically, we call it Alipay, it’s the earliest business we do since 2004 when the business was basically born from Taobao, which is our parent company. So, in short, the Ant Financial Business has a lot of presence in the business of payments business, remittance, credit card, loans, securities, and many other businesses like intelligent technology, blockchain, pretty much everything you can imagine in the FinTech and financial services, we’re in there.
Emily: Tell me a little bit more about the cloud-native journey for Ant Financial. When did it start? Why did it start? What was some of the motivations behind moving to cloud-native?
Haojie: Yeah, it's actually quite interesting. I joined Ant Financial in 2008, but actually, the entire company started to look at cloud-native technology quite early, in 2012. So, back then, people were just looking at these technologies around the world, mostly from the US, they look at this open-source community, look at what other companies are doing, how to use the cloud-native technology to help with their business in the peak time, so during event. There’s online promotion event we're doing every year, called Double 11—Shuāng shíyī in Chinese. Every year, so we have a large amount of promotional events happening online, trying to help merchants and the customer is trying to sell and buy stuff in our Tmall and Taobao platform in very, very discounted price. So, for that promotion event online, we have to think about the resilience, the resource pooling, oftentimes the visits has to increase multiple times, sometimes over 100 times the increase compared to the normal time. So in that case, we have to think about how we can be very resilient and efficient infrastructure to support that business needs. So, this is a very large topic. And then, back then, there was a lot of focus and study in our cloud computing department. So, we started looking at this technology called Mesos in 2012. And then, we do a lot of experiments around this technology, but from the business perspective, it's still hard to justify the benefits of moving to Mesos completely. So, we have multiple teams doing a lot of research in Mesos, in Kubernetes, sometimes in our own technology stack, but there's not enough proof or enough confidence for us to move completely over to that technology, until the emergence of Docker container, this Docker technology. Then we started to look at our container infrastructure, really do the investigation around this technology, and understand why this is taking over so quickly over the world, from the business perspective, and from the technology perspective. If you look at the community of Docker, the thing does not really happen until 2015. But we are already in the game for about a year or two. So, we're actually quite happy about our original strategy, but it's just in terms of the research. We're actually a little bit behind in terms of moving to this cloud-native architecture. But as you can see, that I had an interview with CNCF. So, we are very happy about the results that we have right now. Pretty much the entire architecture we run within Ant Financial is, basically, on Kubernetes ecosystem. It's not just using the open-source version of it. We're doing a lot of customization around this open-source framework. Yeah, I can talk more about the details.
Emily: Yeah. Well, let's back up just a little bit. I’m curious what you were doing to manage this scaling before? And how did that change? And what about the whole process changed? Like, how stressful is it now, compared to before?
Haojie: The process was very manual, I would say. We have extremely large team of engineers, and DevOps, security teams. And oftentimes their responsibility are overlap. So, some engineers are doing security work, some engineers are doing basically operational work. I would say, some people really hated it because they have to be on the computer, look at monitor 24/7, making sure transactions succeeded. When the peak time happens, there's nothing wrong with it. Sometimes they have to keep their phone open 24/7, basically to make sure this thing will not fail, right? And then, just many parts of work has to—so in the previous way, the way we do this operation is quite manual. We don't have a mature system or methodology telling us what we should do first, we should do second, and what's what would you do after this. So, basically the collaboration chain was not there. Therefore, when issue happens, our operation team has to respond very quickly. But then, how can we quickly identify the problem, and make it a problem? That's a problem, right? So, we have to make sure every time we respond, we respond in a very effective manner. That's the problem. In the previous process when something unexpected happen, who had to engage with the entire team from product, engineering, operation, security, everybody has to get up and look at the problem together, which was quite inefficient. So, after we moved to this cloud-native architecture—it's not the standard cloud architect, it's, kind of—we have a lot of innovation on...
Some of the highlights of the show include
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...
Some of the highlights of the show include
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 I’m here today with Edgaras Apsega, lead IT systems engineer at AdForm. Edgaras, what I’d like to do is just start out with you introducing yourself.
Edgaras: I’m Edgaras. I’m working in the Adform. For anyone that doesn't know, Adform is one of the leading advertising technology companies in the world, and provides the software used by buyers and sellers to automate digital advertising. And, probably one of the most interesting parts of our solution stack is demand-side platform that has real-time bidding. And, what it means is that when that page is loading for some kind of internet users, behind the curtain, there's actually a bidding process that takes place for the placeholders to show ads. So, basically, you're doing low latency stuff. And, in Adform, I'm a lead systems engineer for the cloud services team. Our team consists of eight people, and we are providing private cloud storage, load balancing, CDN, service discovery and Kubernetes platforms for our developers that are in [00:01:36 unintelligible] production services. So, to better understand the scale that our team is working on, first of all, you can see that we are not using public cloud and we have our own private cloud that has six regions, more than 1500 physical servers, and there are more than 4000 [00:01:55 unintelligible]. And, for Kubernetes, we have seven clusters, more than 50 physical machines and around 300 constantly running [00:02:05 pods]. So, we can say that we prefer bigger clusters with bigger resources sharing pools. And you asked, how do I spend my daily work, right?
Emily: Yeah. So, when you get into the office or—right now you're not going into the office—get into your table or your [laughs] home office, what are the first couple things that you do, or…
Edgaras: Yeah, so, when I arrive at work, or, like, at these times, just get off the showers straight into work desk, [laughs] actually, I'm most productive in the mornings and evenings. So, in the mornings, when I go to my work desk, I try to do as much as I can. My sprint plan tasks, and then I scroll through the Slacks, emails, and the tickets assigned to me because we have a development team in another region. So, instantly in the mornings, we have some kinds of support tasks that we need to do.
Emily: Let's go ahead and talk about what this is all about, the business of cloud native, and tell me a little bit about why Adform decided to move to a cloud native architecture. Why did you decide to use Kubernetes, for example?
Edgaras: I'd say, actually, there were two parts. At first, we moved from traditional and, let's say, old-fashioned monitoring solutions to Prometheus, and its integration with service discovery solved lots of operational time for constantly managing and configuring monitoring and alerting for our, quite often, changing infrastructure. And the second part is the adoption of Kubernetes and all of the together coming parts like continuous integration and delivery. So, why we moved to this kind of architecture? It was because the biggest pain points for developers were to maintain actually their virtual machines. And rolling out new software releases in an old-fashioned way, took just lots of time for new software releases to reach production. So, we were looking at the new solutions that were available in the market, and Kubernetes was actually one of them. So, after successful proof of concept, we have selected it as our main application scheduler and orchestration tool.
Emily: What would you say was, like, the business value that you were hoping to get out of Kubernetes, out have the ability to release software faster, for example?
Edgaras: Yeah. So, actually, we wanted to remove the operational time from our developers so that they could spend more time coding without taking care of all of the infrastructure surrounding parts, like the application operating system management, [00:04:58 unintelligible] monitoring, alerting, logging, and so on. So, basically what, I'm saying is that the business value was for the developers to be able to ship features faster, and have a more stable platform that scales application [00:05:15 unintelligible] as well. So, in addition to that, we have a big research department, and the research department always wanted us to have a dynamic environment where they could just launch an applications around some research models, and then shut it down. So, I believe that was the business value.
Emily: Who in the organization do you think was motivating, or driving the move to Kubernetes?
Edgaras: I'd say, actually, it was more like the operation engineers, because the developers ended taking care of their environment virtual machines. They don't know much about it, but they still have to look after it, and constantly asking us for help. And we wanted to have this operational stuff only in our hands and for the developers to run only the code. So, I believe, yeah.
Emily: To what extent was the move to Kubernetes, or to cloud native in general, just purely an engineering decision? Or did it involve other people outside of engineering?
Edgaras: Well, it wasn't only the engineering decision, because we had to take it to the upper levels, just to show this new cloud native, the modern way of developing and running applications. So, the upper management level had to invest time for us to move to microservices oriented architecture and so on. So, basically, we had to show that with a little bit of time investment we can gain lots of benefits, like faster code deploys. So, we are taking the operational work from developers, and developers, when they're releasing their applications, they have full stack monitoring, logging, and they don't need to do any of the operational tasks.
Emily: How difficult was it to have this conversation? Do you feel like the upper management, did they understand the value?
Edgaras: Yeah, it was kind of hard, because nobody wants to invest time to write the code. And, as we are a software company, we always need to write new features. But, once we showed a good example, when investing not so much time, we have those kinds of benefits, then it was quite easy to change the mindset of upper management.
Emily: And, how important do you think this was for Adform?
Edgaras: I think it was very im...
About Emily Omier
Emily Omier is a content strategy consultant who helps companies leverage content to build thought leadership, increase website traffic, grow their mailing list and book more demos. She has worked with CloudBees, Portworx, Plutora, Armory, and is a regular contributor for The New Stack. She graduated from the Columbia University Graduate School of Journalism and lives in Portland, Oregon.
En liten tjänst av I'm With Friends. Finns även på engelska.