The Kubernetes Learning Curve with Edgaras Apsega

The Kubernetes Learning Curve with Edgaras Apsega

Some of the highlights of the show include

  • Why Adform decided to move to a cloud native architecture and Kubernetes specifically
  • Who was the driving force behind the move to Kubernetes?
  • Was the switch purely an engineering decision or did it involve people outside of engineering?
  • Positive and less positive surprises that come with switching to cloud native
  • Organizational and technical problems Edgaras has faced
  • What’s next for Adform on their cloud journey

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...

Jaksot(267)

Go-To-Market for Open Source Companies with Quentin Sinig

Go-To-Market for Open Source Companies with Quentin Sinig

This week on The Business of Open Source, I spoke with Quentin Sinig, who has been the first “business” hire at three open source companies; Strapi, Kestra and now Pruna.ai. We covered a lot of ground in this conversation, which was especially interesting because it spanned three open source companies so we were able to talk about patterns Quentin saw at all of them, as well as how the ecosystem is changing now. We talked about the need to find product-market fit, particularly in the AI era — Quentin says that AI companies need to find product-market fit constantly, because the ecosystem is changing so quickly. Quentin mentioned hearing from an advisor earlier in his career that you can’t focus on both usage and revenue — but that in some ways you are forced to focus on both, especially now. When I asked how you decide which of the two goals you should throw more resources behind, he couldn’t say… it’s such a case-by-case decision that there isn’t an easy formula for deciding. Lastly, I had a burning question: What actually does go-to-market mean? And what does it mean to be a “Head of Go To Market?” Quentin says that to a large extent it’s a euphemism for sales, but there’s a little more to it than just that. In his mind, Go-To-Market is a much less siloed function than sales. It’s about getting the entire company aligned, in the expectation that ultimately that will lead to sales. But it’s not just about forcing prospects down the funnel or cold calling, either. Want to talk more about the specifics of go-to-market for open source companies, with people who have been there? You should join Open Source Founders Summit, an in-person conference for leadership in open source companies. The next edition will be May 18th and 19th, 2026 in Paris. And curious about my consulting options? Check out how I help open source companies here.

24 Syys 34min

Open Foundations with Or Weis

Open Foundations with Or Weis

This week on The Business of Open Source, I spoke to Or Weis, the CEO and co-founder of Permit.io. Or is a serial entrepreneur who has had a long career in developer tools. We talked about Permit’s relationship with open source, including of course the open source projects that they create and maintain. One thing to note is that none of Permit’s open source projects are branded as “Permit.” They are all separate from the permit.io brand. On the other hand, Or talked about the essential balancing act for open source companies… figuring out the balance between what goes in the open source project and what goes in the commercial offering. “Companies that get it wrong die, and companies that get it right end up flourishing,” he said. Or Weiss has a theory about open source businesses that he calls ‘open foundations.’ He thinks that this model is better than open core — to be honest I think open foundations is a type of open core, but I think that Or’s argument about how to do open core are fundamentally correct. Permit’s primary open source project is OPAL, and the way that Or puts it is that Permit uses OPAL, but it is not OPAL. The two pieces of software are different and have different value propositions. He also talked about how important it is for everyone to understand what features belong in the project and what belongs in the product… by ‘everyone’ he means product managers in your team but also members of the open source community. We also talked about how you have to have a moat for your product, and especially with AI coding tools a lot of models do not have a moat anymore. Which is why he doesn’t think that just SSO and a fancy UI are enough of a difference between project and product anymore. If you are interested in having more conversations about building open source businesses, join us next May in Paris at Open Source Founders Summit!

17 Syys 37min

Straddling open source software and the hardware industry with Rob Taylor

Straddling open source software and the hardware industry with Rob Taylor

This week on The Business of Open Source, I spoke with Rob Taylor, CTO/CSO and founder of ChipFlow. Although ChipFlow is unambiguously a software company, it creates software that facilitate the creation of semiconductors, so it straddles the software and hardware worlds.Some of the things we talked about include: The state of open source in the semiconductor space, and why that matters. A large part of it is the high cost of proprietary software for chip design, and the fact that there are a lot of barriers to entry, both for the design software and to chip creation. Rob also talked about how an open source approach is the only way to bridge between research institutions and universities and the commercial world — too often, researchers would do brilliant work during a Ph.D. program and then it would be completely lost when they entered the commercial world. On the other hand, open source is little-known and mistrusted in the semiconductor space. Rob described it as a marketing liability, which is why it’s downplayed on the company webpage. —> I come across this more often than is often recognized inside the open source bubble. It’s one thing to build an open source company in the software infrastructure space, where open source has a positive reputation and is often seen as simply table stakes; it’s quite another to build an open source company in a conservative industry where open source doesn’t have a positive image. Perhaps the most interesting thing is that this means you have to have a reason other than marketing to build and maintain the open source project. Want to join others to talk about the challenges and opportunities in building open source companies? Join us at Open Source Founders Summit next spring in Paris.

10 Syys 34min

The double-edged sword of big initial customers with Taco Potze

The double-edged sword of big initial customers with Taco Potze

This week I’m back from vacation and I have a new episode of The Business of Open Source, with Taco Potze! Taco is the co-founder and CEO of Open Social. A couple interesting takeaways from our conversation: When you’re transitioning from a services company to a product company, it’s much easier if the product you work on is connected to the services your clients are already paying for. Landing a huge customer, particularly if it’s your first customer, can be a double-edged sword. On the one hand you have a lot of revenue, but you also risk becoming your customer’s servant and losing control of your product’s roadmap. You can’t do everything; and particularly you can’t build a product that meets the needs of small, medium and large organizations. Sometimes you need to re-launch / reposition. Open Social recently completely changed their positioning earlier this year in response to changes in the marketplace and how their customers were use the product. Customers might not care about open source, but they care very much about lock-in, exit costs, and data sovereignty. This is all a part of risk management that CIOs are thinking about a lot. Some organizations use both the self-hosted and the SaaS product. One of the biggest / most instructive mistakes they made was maintaining completely separate codebases. When they invested in merging the codebases, it dramatically improved the customer experience in relation to updates, bug fixes and simplicity of the engineering effort.  We talked about Open Source Founders Summit at the end — and which is where I first met Taco. If you’re interested in joining us in 2026, sign up for the newsletter! Tickets will be on sale soon.

3 Syys 39min

Build for Dual Audiences with Pablo Ruiz-Muzquiz

Build for Dual Audiences with Pablo Ruiz-Muzquiz

This week on The Business of Open Source, I spoke with Pablo Ruiz-Muzquiz, CEO and co-founder of Penpot. We started out by talking about the transition from services company to product company, how they decided to pivot to building a product company and when they made the decision to go all-in on the product. Perhaps the most interesting part of the conversation is the discussion of the business model. It’s almost like open core in reverse. Penpot open source is fully featured and very flexible; but there’s a separate product available for business stakeholders to control how Penpot is used in their organizations. So when you need gouvernance and control, you should pay for the additional product to control Penpot usage in your organization. But if you don’t need to limit how Penpot is used at all, you (and everyone else in your organization) can use the open source version without the additional controls. We also talked about dual audiences. Penpot has to appeal to designers and developers, and building something (and ultimately marketing/selling it) that has to appeal to two very different stakeholders. We talked about how the company manages that balance, and why they want to have more developers using Penpot than designers. We talked a bit about Open Source Founders Summit as well. If you’re interested in learning from other founders and leaders in open source companies, join us at Open Source Founders Summit in Paris!

2 Heinä 39min

Managing community contributors with Alya Abbott

Managing community contributors with Alya Abbott

This week on The Business of Open Source I talked with Alya Abbott, COO of Zulip, about managing community contributors. This is a hot topic for open source companies — and for that matter, open source projects in general, including those that aren’t being monetized in any way. It’s a bit of a third rail in the open source ecosystem to suggest that there’s a downside to community contributions, but there undoubtably is. At Zulip, they think about the contribution process as a product. They think about the contributor experience and making it as easy as possible for new contributors to get started. They even did user experience testing on the developer experience for contributors — and made changes as a result. And why does this even matter? Because when it’s done right, community contributors can end up increasing your development velocity. Especially on things like integrations, the community contributors can really push things forward. There’s much more to this episode, so check it out! And if you’d like more content about open source companies, or if you’re the leader of an open source company, join the mailing list for Open Source Founders Summit.

25 Kesä 36min

Building a Dual Growth Flywheel at GitLab with Nick Veenhof

Building a Dual Growth Flywheel at GitLab with Nick Veenhof

This week on The Business of Open Source, I spoke with Nick Veenhof, Director of Contributor Success at GitLab. GitLab has probably the most well-articulated open source strategy out there, and we talked about the two main prongs of that strategy, the co-create strategy and the dual flywheel strategy. We also talked about incentivizing individuals versus incentivizing companies and how to build recognition system as part of the way to encourage people to contribute. We also talked about how to make sure that contributing is accessible — thinking about the “time to success” for contributors in a similar way as how you would think about time to value for software users. The dual flywheel strategy This strategy is based on the idea that as an open source company you want to simultaneously push growth in your open source user base and your customer base, and that the two should reinforce each other.  The co-create strategyThe co-create strategy involves encouraging paying customers to contribute to the open source project. In other words, customers who are already paying are encouraged to also invest engineering resources to improve the product. Nick said that this has obvious benefits for GitLab, but it also has benefits for the customers. They end up with a much better understanding of the product, and end up getting more out of the product then they would otherwise. If you want to learn more, I highly recommend having a look at the GitLab Handbook, particularly the section on strategy. And if you want more information about working with me, check out the options here.

18 Kesä 36min

Solving Universal, Persistant Problems with David Aronchick

Solving Universal, Persistant Problems with David Aronchick

This week on The Business of Open Source, I spoke with David Aronchick, CEO and founder of Expanso, about luck and timing, building into universal truths and the reasons for Kubernetes’ success. Before David founded Expanso (which is behind the project Bacalhau), he was the first non-founding PM on the Kubernetes project, and we kicked off by talking a bit about what made Kubernetes so successful… and you probably can guess that it didn’t have to do with having the most awesome technology. A big part of it was that it was the right time and a number of factors in the larger ecosystem were aligned in favor of making Kubernetes a success. It comes down to luck and building to where the puck is going… so how do you know where the puck is going to be a year from now? David talks about selling into basic truths. If you’re pegged to a specific technology, you’re putting yourself at huge risk. But if you are solving a problem that has always been a problem and is likely to continue to be a problem, you are more likely to be successful. We also talked about Adam Jacob’s talk on building a business around open source that he gave at KubeCon Salt Lake City, which you should definitely listen to. Adam Jacob also came on this podcast a year ago, and you should also listen to the episode he did. Lastly, we talked about how hard GTM is, and how David would invest way more into GTM, starting much earlier, if he could start over again. David was at Open Source Founders Summit this year, and you should come next year too!

11 Kesä 45min

Suosittua kategoriassa Liike-elämä ja talous

sijotuskasti
mimmit-sijoittaa
psykopodiaa-podcast
puheenaihe
rss-rahapodi
ostan-asuntoja-podcast
rss-lahtijat
pomojen-suusta
rss-rahamania
rss-startup-ministerio
rss-turvacast
taloudellinen-mielenrauha
rss-neuvottelija-sami-miettinen
rahapuhetta
rss-h-asselmoilanen
oppimisen-psykologia
kasvun-kipuja
sijoituspodi
hyva-paha-johtaminen
rss-40-ajatusta-aanesta