RVU’s Cloud Native Transformation with Paul Ingles

RVU’s Cloud Native Transformation with Paul Ingles

Some highlights of the show include:


  • The company’s cloud native journey, which accelerated with the acquisition of Uswitch.
  • How the company assessed risk prior to their migration, and why they ultimately decided the task was worth the gamble.
  • Uswitch’s transformation into a profitable company resulting from their cloud native migration.
  • The role that multidisciplinary, collaborative teams played in solving problems and moving projects forward. Paul also offers commentary on some of the tensions that resulted between different teams.
  • Key influencing factors that caused the company to adopt containerization and Kubernetes. Paul goes into detail about their migration to Kubernetes, and the problems that it addressed.
  • Paul’s thoughts on management and prioritization as CTO. He also explains his favorite engineering tool, which may come as a surprise.

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

Jaksot(267)

Getting Your Pricing Model Right-ish with Alex Olivier

Getting Your Pricing Model Right-ish with Alex Olivier

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:The first step of figuring out your pricing is not the number, but rather what you’re charging for. Is it API calls, or amount of data you’re processing, or monthly active users, or monthly active principles… that last one is what Cerbos is charging forWhy it’s important to have a pricing system that allows potential users to be able to roughly estimate for themselves how much using your software is going to cost themYou also want to avoid pricing models that encourage people to look for ways to hack around to find ways to lower their monthly costsWhy your pricing model should be about the value you’re providing, not about how much it costs you to run your systemDiscovering what your price anchors are / what your customers are comparing you toCheck 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.

10 Huhti 202425min

Nailing Customer Acquisition with Patrick Backman of MariaDB and OpenOcean

Nailing Customer Acquisition with Patrick Backman of MariaDB and OpenOcean

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: Why they decided to put MariaDB open source in a foundation, and why they created a separate foundation instead of putting it in an existing foundation The relationship between MariaDB foundation and company today, including the financial relationshipMariaDB 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.

3 Huhti 202436min

Ensuring a Project's Long-Term Survival with William Morgan

Ensuring a Project's Long-Term Survival with William Morgan

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:Being an open source mercenary, but also being dedicated to making Linkerd a ‘proper’ open source projectFeeling like open source was table stakes for a company in the space Buoyant plays in. This is an under-appreciated reason for being an open source company — you feel like it’s just expected in the market you play in, so you do. Waiting too long (or is it too long?) to commercializeStarting out by selling support, but the problem with that because Linkerd worked well and people kept saying that they didn’t need support because they never had problemsCompeting against Istio, which was backed by the Google engine and how that made Linkerd / Buoyant an underdog (or cockroach). For those of you who haven’t been following Linkerd / Buoyant… Buoyant recently announced that they would be doing edge releases for Linkerd, but not stable releases. We talked about why they made this change and how the ecosystem responded. Check out the full episode!

27 Maalis 202435min

From Project to Profit with Heather Meeker

From Project to Profit with Heather Meeker

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:Why you should think of your project and product as two different products so you avoid thinking of your open source project as a loss leader and get your incentives rightThe differences between supplementary and complementary products, and how the relationship between project and product is often complementary, even in situations where that relationship is non-obviousWe disagreed about pricing — should COSS businesses have cheaper products than closed-source companies? Why cares about your being open source? Are open source companies more capital efficient? Heather says so, but I’m not convinced. Heather also talked about how they select companies to invest inDo open source companies by definition do a better job at paying attention to user / customer demand? Check out the episode, and check out more about Heather Meeker here: Personal websiteOSS CapitalLinkedIn

20 Maalis 202437min

Delivering Value Quickly in the Observability Space with Pranay Prateek

Delivering Value Quickly in the Observability Space with Pranay Prateek

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: How SigNoz is differentiated in the crowded observability marketWhy Pranay thinks being open source makes it much easier for developers to play around with the project and get to know it; so for them it made intuitive sense that the company that they’d build an open source company Why Pranay also thinks open source enables much deeper integrations, which is critically important for an observability company like SigNozHow one of their first lessons / mistakes was releasing an open source project that didn’t work well on an individual developer’s laptop, because it used too much resourcesThe GTM market, and the challenge delivering value within 30 minutes of trying out the project/product for an observability tool that provides maximum value during an incident — but no one is going to be trying out a new tool during an incident situation Why their first commercial product was a cloud offeringAnd 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.

13 Maalis 202439min

OSFS Special Episode: Being a Strategic Acquisition Target as an OSS Company with Thomas Di Giacomo

OSFS Special Episode: Being a Strategic Acquisition Target as an OSS Company with Thomas Di Giacomo

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: Exits 101. You probably know that strategic buyers usually pay more for companies than other types of acquirers, but we talked about different exit strategies and what they entailWhy strategic buyers acquire businesses (in general) but also why you, as the business seller, need to understand every specific potential acquirer’s story and goals so you can see how your company fits into their strategic planStrategic acquisitions are about 1+1=3… so you have to know what your buyer’s “3” isWhy it’s important to be self-aware and know your own goals before you sign any acquisition paperworkAnd 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.

12 Maalis 202432min

Buyer-Based Open Core with Zach Wasserman

Buyer-Based Open Core with Zach Wasserman

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:Leaving his first company, Kolide, when the founders had divergent visions about where the company should goHow his investor arranged a ‘co-founder marriage’ for Zach and his co-founder Mike McNeilHow the transparency aspect of open source can be extremely important, especially for anything in the security spaceLastly, 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.

6 Maalis 202437min

The Evolving Relationship between Apache Cassandra and DataStax

The Evolving Relationship between Apache Cassandra and DataStax

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. Patrick on LinkedInMick on LinkedIn

28 Helmi 202440min

Suosittua kategoriassa Liike-elämä ja talous

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