Episode 63: The One Where We Talk with Benjamin Eberlei about Tideways

Because We Enjoy Learning How SaaS Projects Tick

00:55:24 N/A download

Transcript

Dave 00:17 Hi, and welcome to another episode of That Podcast. I'm Dave.

Beau 00:20 And I'm Beau.

Dave 00:21 And today we're joined by a guest, Benjamin Eberlei, of tideways.io. And previously you were quite high into the structure of the Doctrine project and you were part of another company. Is that still going? Was it, I want to say Qafoo but it's probably Qafoo, wasn't it?

Ben 00:45 I think Qafoo is right, Qafoo was just... also makes sense since the company did a lot of things in quality assurance.

Beau 00:57 Right, is that still going, are you fully on Tideways now?

Ben 01:01 I'm fully on Tideways now, since the beginning of 2018, and mostly 2017 already as well. I just worked I think one day a week for Qafoo then. Yeah.

Dave 01:18 Okay. So do you want to tell the listeners a little bit about Tideways. And I'm sure some of them have heard of it before. But the last time I checked the project out, it had grown a bit since because it was just of profiling to begin with, then I believe came monitoring and then... Look like you're doing exception tracking now as well. Is that right?

Ben 01:39 Yes, exactly those three sort of bigger features. And so then initially, what I was doing is that we needed a profiler for our load testing. So a lot of our customers had load testing from eCommerce shops so they would, way before Christmas try to find out if their new shop system or changes to their shop system would actually hold to the traffic that would come to Christmas and Black Friday and all this kind of stuff.

Ben 02:15 And that was around 2013, so a long time ago already. And there has only been a few profilers back then that you could use in production, or actually just the XHProf code base that Facebook sort of dumped into the world and then left to rot.

Ben 02:36 And so we built a little tool around XHProf and stored this data for load testing purposes. And then I had the idea to build a more complex profiling product around it, especially since most people don't actually... So load testing is something that not many companies do. So to get a good overview about how your website actually performs, you need continuous monitoring and sort of, say, using your users as a load testing device to generate the traffic and see what is happening on the site and what parts are slow, what parts are fast, and then from there go into a more traditional profiling, but, yeah.

Ben 03:28 And yeah, the exception trapping was something we added because it was very adjacent to monitoring and not really to profiling, but to monitoring. It sort of fell off as a side product, and it was something that a lot of people ask for, like, if we are in there already collecting all this data, then why not also store exception messages and then provide a workflow around that? Yeah.

Dave 03:57 Yeah, that makes sense. So you've been full-time with Tideways from 2013. And how's the business grown? Did it starts out with just you and people from Qafoo? Or did you or was it just you to start with? Or how'd it go?

Ben 04:15 So we started working on the project 2014 and full-time since 2017 something.

Beau 04:23 Okay.

Ben 04:23 Before that, I worked on it in my free time. And then I was able to work on it a little bit on company time. And when we founded the Tideways Company actually which is now its own company, I worked on it more and also the other guys from Qafoo worked on it, and that was around two years time where we worked on it all sort of part-time.

Ben 04:55 And once the project had enough revenue that it could support my salary, I switched over to working full-time on it. And I was able to hire my first employee last year in March. And we have now grown to five employees at the moment. Yeah.

Dave 05:18 Well, that's fantastic. Congratulations.

Beau 05:20 Yeah, it is.

Ben 05:20 Well, thanks. Yeah.

Dave 05:22 So where have you been bringing in, I assume initially, revenue, well, clients came from existing Qafoo clients. And then how did you go about finding other people to come and use? Or did you just use Qafoo as a leader into Tideways?

Ben 05:40 So Qafoo was one very, very big step, or opportunity that made this possible. So through Qafoo, I had a lot of contacts through to our eCommerce customers that we served at that time, and also to hosting companies that we work with for the load testing parts. And so we were able to, very early on in the, I think, first three months or something, find a hosting company that was super interested in Tideways and they actually, they deployed the product for all their customers in the first five or six months. And that allowed us to have a big customer base already, people using it, and also allowed us to have some revenue, so we had revenue very early on.

Ben 06:36 And this was something that never worked with all the projects I tried before. So this was the first time I had a project that actually made revenue and some, a side project of mine that made revenue, and that was a very, very big motivation boost. So before that, most of the projects I did sort of fizzled down because I never thought anyone would ever buy it or it would never come out to something.

Ben 07:06 And I already learned a lot when I started, what became Tideways in the end, that I needed to build something that works in three months, that or two months or something. That it had to be something that people are going to be excited about it at least a little bit and try it. Because otherwise, if you don't have external motivation from other people, it's just a project you're fiddling with and it's very hard to, at some point, get it out of the closet and say, “Ta-da, I've been working on this for two years or something.”

Ben 07:41 And so this is something I learned and that worked quite well. And I was super happy that we found this hosting partner that trusted us with building this product so early on and so that was-

Dave 07:58 So just so I'm clear. Was the hosting company one client too? Or were they sort of like a partner who makes this Tideways profiling available to its customers who could then individually, they're almost like generating leads for you? And so you had... Did you have one client who then sold it on to their people as part of their hosting deal? Or did you have this way to multiple clients via the hosting company?

Ben 08:28 So the hosting company was buying the product and they gave it to their customers for free.

Dave 08:36 Excellent. Okay. That makes it even easier for you, doesn't it?

Ben 08:39 Yes.

Dave 08:39 It's perfect.

Ben 08:40 Yeah. So, and this early success actually allowed us to, or make me very, very confident in charging for the beta. So we actually charged for the beta of Tideways, which we started, I think six months after, I think we started coding on the project in, I think, in May or something, and we launched the beta end of October or November or something like this.

Beau 09:13 When did the hosting company come on then? At the beta?

Ben 09:16 In July?

Beau 09:17 In July? Okay.

Ben 09:18 Yeah.

Beau 09:18 Wow. Cool.

Ben 09:20 Yeah. So that was a very quick timeframe actually. And the beta period took about, I think, eight months or something. And then we launched the next year after that in June or something, I don't remember exactly the numbers. And so, yeah, the first customers we had this, just a very, like very, very few. So except the hosting companies minus this hosting company, we had, I think, 10 customers in the first year. Then it was like one new customer every month or something like that. So maybe two. So it was very, very slow growing.

Ben 10:03 And that was obviously because it still was a beta version. And then when we launched it, it started to kick up a little bit. But it was still very, very slow in the beginning. Yeah.

Dave 10:17 Yeah. And where did those 10 customers come from? Did you know by word of mouth or people you knew or?

Ben 10:23 I think when we announced that we are working on a profile of a PHP we collected email addresses, and at that time, I think about 500 people signed up, and we sent them emails for the trial. And I think a few of the customers who had been from that list, a few customers had been sort of friends and family, or at least, like one degree of network-

Dave 10:50 Mm-hmm (affirmative).

Ben 10:50 -so very close to, we actually know the persons that are, or people that are our customers. And after this, it quickly became that people maybe half of the people that signed up were people that I never heard of before. And so then people that somehow heard about the project from somewhere, I don't know.

Dave 11:17 Okay, that's cool. So in terms of, more about the technical side of things, what sort of big challenges have you had to overcome with it? I mean, it's obviously a very complex project. And you're really moving fully up and down the stack. You're here from, I assume, instrumenting PHP with XHProf or... Did you adapt to XHProf for the actual product, or did you start fresh or?

Ben 11:45 And so we used XHProf for about a year, I think. And then we had, we forked it and we changed quite a lot internally and made it up. But it's still the basis XHProf. And we only just got rid of sort of the basis last year when we released the completely rewritten PHP extension. Yep. But this tech is quite complex, and the one thing why this project was interesting to me from a side project perspective, was the technical challenges.

Ben 12:26 So I wanted to build something that is quite complex from the technical side, because at the time, I really enjoyed working on complex technical problems. And to be honest, it's built the benefit to the product or the company and also a downside because the complexity obviously requires everybody working on the product to know a lot of technologies.

Ben 12:56 So it's not really only a web application because it's also a C extension running in PHP, then we have an intermediate software that is written in Go, which communicates between the PHP extension and the back end. And yeah, the back end is completely written in PHP. So as a Symfony application. Yeah.

Beau 13:22 So does your team, the Dev team anyway, do they work? Like, are they cross functional teams where everybody works on everything? Or do you have them more siloed for people working on the Go App versus the extension versus the Symfony App.

Ben 13:40 So I try to give them tasks across the whole stack. So everybody has to work on everything. And obviously, everybody has sort of a specialty working in different things. And we have one engineer who's also just beginning to learn to program. So she's working mostly on the PHP code base and has to learn a lot or stay with the PHP code. So she, but she also works on JavaScript and sometimes a little bit on Go code small things. But everybody else sort of gets things assigned that are working across the stack.

Ben 14:29 And I, personally, I really like when one person works on the technical implementation of something completely from the full stack, because it's much easier if there's just one person working on a feature, instead of having the coordination between, “Ah, you need to finish this one before I can work on that one.”

Beau 14:50 Mm-hmm (affirmative).

Ben 14:51 And so, this is why from the Go stack to the user interface, usually, if you have a feature you have to implement, one person is implementing everything. The exception is the C code, because C code is quite different in that it requires a lot of additional skills like memory management, that my employees don't have experience in. So I would trust them with learning this for, and starting to learn this, but at the moment, this is the only part of the code base where I am the only one working on.

Beau 15:35 Hmm. Okay.

Ben 15:37 Yeah. And I guess that is one of the downsides of the complexity of this project that, you can't keep this company small in a way that you just have four employees or something, because the technology stack is so complex that to have experts in the different fields, then you need to look at hiring different employees for the different technology stacks, because it's very hard to find somebody that can work on other stacks. Especially for us as a small, self-funded company, it's impossible to hire somebody with that much experience and be able to pay them a salary or pay them a competitive salary. Yeah.

Dave 16:32 Yeah. So, but if you continue growing as you are, then you get there one day, right?

Ben 16:38 Yeah, yeah.

Beau 16:39 So the Tideways extension, the XHProf, part of it, you forked that, and that's actually available as open source, correct?

Ben 16:49 Yes. There's still an open source extension available. It's somewhat also already using the modernized extensions code base. So there's a branch, four point something, that is still the old XHProf, and there's a new branch that is also based on our new code base.

Beau 17:09 Okay. But even the new code base uses the same file format or protocol or whatever the XHProf use. So, as I understood, at the Tideways, even the new extension, you can use that standalone without paying for the service-

Ben 17:25 Yes.

Beau 17:25 -if you want to use one of the other XHProf visualizers.

Ben 17:29 Exactly. So then you could use the Tideways XHProf extension, PHP extension and it generates compatible format to the XHProf output they are insured upon. So you can combine it with any of the publicly available open source user interfaces like Paul Reinheimer's XHProf user interface or the XHGui or something, and I recently saw that there was a new one available a few months or a few weeks ago on Reddit that was open-sourced. So that is, that you can still use for free. Yeah.

Dave 18:12 That's pretty cool. I didn't know that. I didn't-

Ben 18:15 Yeah.

Dave 18:15 -know you've maintained compatibility. That's cool.

Beau 18:19 That's one of the big differences that I've seen with Blackfire. The listeners know that I've worked with Blackfire in the past, and Blackfire's extension isn't open source. So I was a bit surprised when I saw that Tideways' was. So I wanted to better understand that a little bit just to make sure that I was reading that correctly.

Beau 18:40 I did a performance talk at php[tek], talking about profiling PHP code, and I mentioned both Blackfire and Tideways. I gave people examples of running both code. So it's... I've been able to take a look at both sort of ways to do things, and was pretty excited about some of the stuff I saw on Tideways that I hadn't known before. So thank you for confirming that for me, that the extension is public.

Beau 19:08 The other thing about the XHProf, the original Facebook implementation is, it doesn't support PHP 7.

Ben 19:13 Yes.

Beau 19:13 Is that correct?

Ben 19:15 Yeah, that's right.

Beau 19:15 Yes. So even if people didn't want to use one of the SaaS products, if you're on PHP 7, you don't have the option to use XHProf. But they do have that option if they use the Tideways extension.

Ben 19:31 And yeah, that's right. So there are obviously lots of forks of XHProf, so Tideways is not the only one providing XHProf compatible, PHP 7 compatible, and-

Beau 19:41 Mm-hmm (affirmative).

Ben 19:41 -repository. Yeah. But most of the forks I've seen only adapted the code that it works for PHP 7-

Beau 19:58 Mm-hmm (affirmative).

Ben 19:58 -but PHP 7 had a lot of changes in the engine that make it much more suitable to actually rewrite the extension built from PHP 7 from scratch, because the improvements that you can do this way, are very, very big. So, from a profiling perspective, you can reduce the overhead quite a bit if you are coming from a PHP 7 approach of writing a PHP extension instead of coming from a PHP 5 approach and adapting it to PHP 7. That makes a huge difference.

Ben 20:36 And second thing is that when XHProf was released, there wasn't a great API for taking low level performance counters in Linux, so they used some assembler code, and it required to do some hacks to make the timing work and with modern computers which have a lot of cores, it's actually super expensive to start the old Expos because it has to sort of synchronize the clock across all the cores, and that takes a few seconds, maybe.

Ben 21:18 So it's much better to use one of the modern Linux APIs for timing. And yeah. XHProf was released in 2008, and then nothing changed on it. So it makes sense that in 12 years APIs change. Yeah.

Beau 21:37 Yeah.

Dave 21:38 Hmm.

Beau 21:38 I guess from my perspective, knowing that there are SaaS services out there or SaaS products out there, that support PHP 7 has like a first class language, the fact that any of those have their extensions available to me is like a huge thing.

Beau 21:58 That to me, anytime you have a company producing something and using something that makes them money, like I feel like I would trust, say, the Tideways' extension for PHP 7 over one of these other plugins. Even without knowing what you just said-

Ben 22:15 Wow, okay.

Beau 22:16 -But for me, seeing that a service that's using this in production and selling it and making it available, that's what caught my eye and I was excited about that and the things that you've just said, just sort of reinforced that feeling for me. That you've actually... You have your you have a very vested interest in it beyond just some hobbyist that needed to get it working for PHP 7 versus getting it to work for PHP 7 well, so that you were serving your customers well, and they were happy with the performance even while they were being profiled.

Ben 22:49 Yes, exactly. Yeah. That's right. Yeah.

Dave 22:51 I'm interested to know, you mentioned obviously, eCommerce was... A lot of your clients were eCommerce-based stores and preparing for the rushes at certain times of the years. Would you say eCommerce makes up most of your clientele? Or is that a bit more varied now? Do you have applica... like software applications? Or do you have like more publishing side of things or anything like that?

Ben 23:16 So eCommerce makes up a big share. So I would say, in excess, way in excess of 50%. And I think the reason for this is very simple because eCommerce has a direct relationship to revenue. And often, it is the primary revenue of a company. So it's actually their product and there, the most important thing to work is their eCommerce shop.

Ben 23:47 And, in addition, there have been a lot of studies that performance is important for eCommerce shops, so the faster the shop, the higher the checkout rates and all this kind of stuff. So, and performance is always something that is relevant to eCommerce teams so they know that they have to work on it.

Ben 24:05 And then the other big group of customers is probably products. So like Tideways, I would say, any kind of product that is a web application and is written in PHP could be a Tideways' customer.

Ben 24:24 And then the smaller share is probably publishing and CMS hosting and this kind of group of customers but because they usually are well served by tools like Pingdom or something like this, that checks their performance from the outside and that is usually enough for CMS-based websites. So in my opinion from talking to a lot of people, they usually tend to go for these kinds of tools instead of a full fledged profiling tool.

Dave 25:07 Okay. So do you have any particular sort of success stories you could mention? Whether you could mention them by name, or whether just, you could keep it anonymous, but any sort of like, massive examples where a client said to, “Oh, yeah, we did this and this happened.” Or anything like that?

Dave 25:25 I mean, we do talk about, I know, I understand all the studies that say how performance really matters with eCommerce and checkout rates and abandonment and all those kinds of things. Yeah.

Ben 25:38 Yeah, so we have customers writing us that they found big problems and how they, that they fixed them with or didn't see them before without Tideways and... But in general, I'm not keeping, I'm not very good at keeping track of them. So I couldn't tell like a big story of a customer or specific numbers that they have and have been improving.

Ben 26:07 So we are using Tideways for ourselves and we always find a lot of improvements, and they often... So it tends to be the case that over a few months, some performance problems creep into every application. And then you find out what it is, and you can drop the performance again to the previous levels. And then they goes slower again, slowly. And yeah, but to be honest, the specific, I don't know.

Ben 26:41 Like, things that people often posted or wrote about was not specifically Tideways-based improvements, but the PHP 5, PHP 7 upgrades, has consistently been something where people sent us screenshots and said like, “Wow, that's amazing, the difference. And I can see it here, how the performance sort of halved the latency.” And that was quite nice to see. Yeah.

Beau 27:13 One of the things that, I've referenced a lot on any of the performance talks I've given on the PHP 5, the PHP 7, is one of the, I think it was one of your posts from Tideways about how the perception that profiling has a bigger impact on PHP 7 code than it did on PHP 5.

Beau 27:35 But it's just that PHP 7 is so much faster. Even though the actual profiling overhead has stayed the same, it's now taking a larger percentage of the request. Do you get a lot of people asking about that still?

Ben 27:51 Actually not. They see it in a different way. So sometimes customers have applications that make a lot of requests and, no, a lot of function calls in the many hundred thousand ones. So let's say, I think both WordPress and Magento are very, very good contenders in going into the direction of having, let's say, 500,000 function calls in a single request.

Ben 28:20 And if you enable any kind of profiler, like Tideways or Blackfire or something, and they have a fixed over--, it's not a fixed overhead, but let's say it's a fixed overhead for every function call, and then if the function call itself is super fast, let's say, sub string, or stringpos, or count or something like this, and that function is called 100,000 times, then the profiling overhead might be larger than the actual time the function takes. And that causes requests to take, let's say, 10 times as long as if you wouldn't run them with a profiler.

Ben 29:03 So that is something we get some time. So I enable the profiler and suddenly the site is five times slower than before. And then when looking at the profiling data, you'll see, “Okay, you're calling functions 500,000 times, and that is your problem.” And the profiling just exaggerates or makes the problem worse sort of. Yeah.

Beau 29:28 Yeah. I was profiling a Laravel. Do you get many Laravel applications profiled through Tideways?

Ben 29:35 More and more Laravel. And-

Beau 29:36 Yeah.

Ben 29:37 -it's not as much as Magento or other subsystems, but it's increasing.

Beau 29:43 I had over 6 million calls to is_array.

Ben 29:47 Ohh!

Beau 29:51 So yeah, I was looking at 750 calls to their collection map function. And yeah, looking at that from that perspective, it's like, all right, you can't really do much to figure out what's going on there when you end up with 6 million calls to something like is_array, it's just, it's a mess to try to play with those.

Beau 30:15 So I'd love to talk a little bit about the business model pricing, that sort of thing. I was involved a little bit with the product stuff on the Blackfire side of things. So I kind of understand maybe some of the the oddities of this type of service.

Beau 30:35 We've talked about, like Laravel Shift before where if people buy Laravel Shift, they could use it. But you can't really try Laravel Shift because it's going to do it for you the first time they try it that they don't need to buy it.

Ben 30:49 Yeah. That's right.

Beau 30:50 And that's kind of the problem with profiling as well, that if someone has a performance problem right now, if you give them a trial, then they're going to fix their performance problem then they don't need you.

Ben 31:00 Yeah.

Beau 31:01 So I see that Tideways has a trial but I also see there isn't a free plan. So to compare that to say, Blackfire, Blackfire has a free plan with limitations but they don't have a trial necessarily of some of their higher end stuff. Definitely not the enterprise stuff but they do have a trial.

Beau 31:25 I'm just curious how the pricing is worked, what kind of these sorts of SaaS dials you've played with to land where you are now. If you're getting pushback on pricing or anything like that.

Ben 31:42 That's a very good large-faceted question. And so with respect to the free trial, so I was always against having a free trial because, not a free trial, having a free plan or something, a freemium model, because I, in the beginning, I was just working on it alone in my spare time. So I had the fear that there would be a lot of free users and they would ask a lot of support questions, and I wouldn't be able to handle it, and the conversion rate from freemium to paid is usually about 2% or something.

Ben 32:25 And so for me, it didn't make sense to offer a freemium model. So what I did instead is saying, “Okay, I keep working on this open source XHProf proper version, if you want to have a free profiler, then hook this open source extension that we provide up with a user interface and just do everything yourself.” So that is sort of the free plan that we offered.

Ben 32:54 And then what we, what I think works with the having a free trial and customers getting the value immediately and not paying for it is that we also have the monitoring and exception tracking features. So we serve customers Tideways as a solution that has a history of your performance and finds out when the performance changes for you all the time. So you don't have to actually look at the numbers and we send you an email every week with the changes that are happening. We point out specific endpoints that we find that got slower or faster, and we send you exceptions and all those kind of things.

Ben 33:41 So the idea is that Tideways runs for you in production and finds out if something goes wrong, and then you go in and can fix it. And, of course, customers come to us because they have a specific problem maybe that they can fix in an hour or in a week, and then they can finish the trial and never pay us any money.

Ben 34:05 But from my experience, those customers also come back. At some point they have another performance problem. And then they convert to being a customer. Or they realize that the performance is monitored 24/7, and they can rely on these numbers, and they can stop worrying about performance working on the actual code, and then if something gets slower, they can look in the historic data and see when it changed, when did it change, and how did the code look before, how does it look like now, what changed? So the whole monitoring aspect is also very important for customers that stay on after the trial.

Beau 34:50 It's kind of, I don't remember the term, kind of like a hook. I don't remember, the stickiness, giving them a, like once they install it, and it's just running, then they will keep using it versus using just the profiler as a one off. There's no reason necessarily for them to go back and use it again.

Ben 35:10 So I think it's... We see a lot of use from the, for example, from the weekly report that is sent, where we crunched the numbers and send everybody reports on how the application was doing the last 7 days.

Ben 35:26 And I think this is something where our customer say, “Okay, I haven't been using the product in the last week, but I saw this email everything still seems to look fine and described.” And yeah.

Beau 35:40 How about, like marketing and position, comparing against tools like New Relic, other profiling tools like Blackfire, things that are doing like exception tracking. I've recently started using Sentry.

Beau 35:57 How are you approaching the marketing of Tideways and how do you try to differentiate from competitors from maybe even completely different things? Like New Relic isn't necessarily even a competitor but in potential users' minds they might be?

Ben 36:15 It is definitely a competitor because rarely people would pay for both products. So it's either using New Relic or using Tideways. And-

Beau 36:27 Correct. I was... maybe not necessarily New Relic, but other things, like have you found other services where people see them as a competitor and don't realize because in terms of Blackfire when I was working with them, people saw New Relic and Blackfire as a competitor when really those weren't.

Beau 36:44 Do you have something similar in Tideways where there's a class of users that come to you thinking that it's either you or this other provider? And really they aren't actually the same? And how do you try to solve that problem? If you don't have it, that's great. But if you-

Ben 37:02 I think we don't have that, but-

Beau 37:03 Okay.

Ben 37:04 -what we have is that because we are sort of competing with New Relic, and that is that Tideways has a much more limited scope and functionality. So we only have application monitoring, profiling, exception tracking.

Beau 37:19 Mm-hmm (affirmative).

Ben 37:19 So we don't have infrastructure monitoring, we don't have uptime monitoring, we don't have, yeah, the huge range of additional products that New Relic offers that we don't have. So Tideways works good as a, if you complement it with something that does infrastructure monitoring, for example.

Ben 37:41 And that makes it a little bit more complex to deploy because you need two products instead of just using one product. But I think you mentioned a lot of different tools like Sentry, Blackfire, and New Relic-

Beau 37:56 Mm-hmm (affirmative).

Ben 37:56 -all of those three are very good and offer huge benefits in what they are doing. And then Tideways is sort of in the middle and so we are a little boxed in I guess, and taking punches from everywhere. But I think, I don't know, there's a big enough number of customers that think the way we fix this problem for them offers the best value compared to the other tools. So it really depends on the customers, what they want.

Beau 38:34 I also see on your pricing page, a heavy emphasis on no per server pricing or no per host pricing. I imagine that's a big way to differentiate against New Relic. Last I heard they were still per host, right? Or no?

Ben 38:50 Yeah. I think it... I don't know. I wouldn't know to be honest. I think it depends on how you host with them. They also have usage-based I think, but I couldn't tell you to be honest. But-

Beau 39:02 Is that something that you found to be like a big sticking point for people or something that people were excited about?

Ben 39:09 Our customers generally find that the host pricing unfair. It doesn't scale with the value they perceive. So if you have an application running on one server with a per host priced product, that's fine. And then if you add the second server, the next price, usually, it costs additional money for the product to be monitored.

Ben 39:40 But there's a difference between adding, going from one to two servers, or going from 10 to 11 servers. So the marginal benefit of also having that server monitored decreases a lot.

Beau 39:53 Mm-hmm (affirmative).

Ben 39:57 And so we realized early on that a lot of customers would like to have something else than per host-based pricing.

Beau 40:04 Okay.

Ben 40:07 So at the moment, we have two models. You can either pay based on PHP request that your application has, or applications have. This is usually used for customers that have a lot of applications with just limited traffic. And then the other way would be to have the pricing based on application. So single application as a single price. And then if you add more applications, you pay more.

Dave 40:39 That sounds reasonable. The per host, and I must admit, last time I looked at New Relic, it looked like it was per host or per server pricing. I'm not sure if they had anything to do with per CPU but or anything like that. But I mean, we also scale our web layer and our worker layer and I tend to prefer to have lots of small servers than several, than fewer big ones I mean, if you're using the different sized instances on wherever you are, AWS, DigitalOcean, whatever it is.

Dave 41:14 And I was felt like, oh, I'd be getting punished for per server or per host pricing, just because I'm deciding to deploy a fleet of angry bees rather than behemoths. And-

Ben 41:32 Yeah, that's right. And if the pricing of the product forces you to make architectural decisions, just to keep the costs lower, then it might be problematic, yeah. But I think our per request pricing has this problem as well. And since this was the only pricing we had in the beginning, and if a customer would split up their application to use varnish and easy, then one user request would doubled the amount of PHP requests that suddenly get to the back end.

Ben 42:11 So with something that actually is a good architectural change, and you were get double the amount of requests against our pricing plans and maybe double your bill as well. So I don't know. The monitoring pricing question is something I'm struggling with since the beginning. And I think we have changed our billing slightly every year since. So there's so much learning with the billing and pricing and the different ways how customers need it.

Ben 42:47 And in the end, I didn't want to do a lot of sales. And so I also had to pick a price model where I could work without having sales, a lot of sales. And one additional thing is also that I came to realize that the customers we have, they don't like when the price changes every month. So they like to approve some budget for a monthly price and then have this be constant all the way.

Ben 43:19 So it was very hard to find a pricing model that would allow customers to pick something in the beginning and then stick with it, even if they grow a little or not. And then to adjust the way Tideways works, and to make it work for them. And, yeah, that took a long while to figure out, to get this right and didn't have to send the customers emails after one month, “Oh, you're over your limits already. You have to go to the next plan.” And they were happy that they actually could convince their boss paying this already and now they have to go back and ask for, by paying even more something like this.

Ben 44:03 So it's very tricky. And I think it would work if you have employees that work on this side of the business the whole time, talk to customers and upgrade them and all this kind of stuff. But this is something I didn't want to deal with it at all. So the pricing model is picked in a way where we minimize all this kind of hassle as much as possible.

Dave 44:31 Cool. So I've got one last question, if you don't mind. Do you have anything sort of specific lined up for the future in say, the next year of Tideways or any big features you're working on or any big changes you're working on or just, is it continuous improvement?

Ben 44:46 So we are doing a lot of continuous improvements. But one thing that's a little bit bigger that's coming in the next months is that we are improving the functionality, how to be able to trigger profiling from the application. So with the new PHP extension that we released last year, a lot of additional features have been unlocked for us. We were able to reduce the overhead a lot, and we were able to do and collect much more data with less overhead. So it was a really big win.

Ben 45:23 And one thing that we are looking into is that users are able... So a developer in the web interface would be able to say, “I'm interested in this endpoint. And for all, let's say, whenever this endpoint is hit in my application, and it's lower than this or that amount, or it has, it is from a specific user or from a specific account or a specific product, please look for a request that have this criteria, and if you find them, then trigger a call graph from them.”

Ben 46:05 So the idea would be that you see in the application, some specific endpoint is slow, and you just click a button and say for one hour, whenever you find a request that is against this endpoint, maybe just this endpoint or some more criteria, then also generated a call graph profile from it. So this would allow users to get profiles whenever they want from any kind of endpoint.

Ben 46:35 So customers have been struggling with getting call graphs for API endpoints, which are very hard to trigger or reproduce, or specific scenarios of their customers that are slow, but for them it's fast. It always depends on the view that, for example, one customer has 2,000 items in their basket and just that makes it slow. So this kind of-

Dave 47:03 Flight focused.

Ben 47:05 Yeah. So this is something customers have been asking for since the beginning, but we are only able to work on this kind of thing because of the technological foundational changes that we made in the last two years.

Dave 47:23 That sounds really good. I like the sound of that. I'd be interested in seeing how it looks.

Dave 47:30 So anything else you want to ask Beau, or should we be looking to wrap this one up now?

Beau 47:34 I think we'd be looking to wrap it up. What we were talking about the pricing model, that reminded me of a conversation I saw on Twitter recently. Do either if you happen to know how Microsoft SQL Server is licensed?

Dave 47:47 No.

Beau 47:48 It's licensed per core.

Ben 47:50 Yeah.

Dave 47:50 Yeah.

Ben 47:51 I think it's per core.

Beau 47:52 And it's like $3,700 per core.

Ben 47:57 Yeah.

Beau 47:57 So it's not even CPU. And I can't remember who it was, but they were talking about some of the new Xeon CPUs that have 12 core. I mean, I can't imagine a situation where any of the projects I've ever worked on would be able to afford that. So like some of these big enterprise systems I can imagine but. And other people are worried about what? 70 EU a month, when other people are paying multiple thousands of dollars per core. It's kind of-

Ben 48:32 Yeah. I guess the database is central to the workings of the application. So without the database, nothing would work so.

Beau 48:39 Yeah.

Ben 48:40 Hmm yeah.

Beau 48:41 No, I'm not saying it doesn't make sense. I'm just... We were talking at another episode recently about when people want to pay for things versus when they don't, in terms of like open source software.

Dave 48:54 Okay. Yeah.

Beau 48:56 Because when you [crosstalk 00:48:56]-

Dave 48:56 Yeah. Who was the guy then? I would like to [crosstalk 00:48:59].

Beau 48:59 Yeah. Yeah. And that's just looking at all of this, all the money that's flying around, but there are people who are struggling, trying to work on software. It can be interesting sometimes when you realize how much money some of these companies really have and where they put it or where they have to put it.

Dave 49:17 And it was with that Oliver Davies I think so.

Beau 49:19 Oh, okay. Yeah.

Dave 49:20 But it was only briefly, we talked about it. I mean, I talked about, I was talking about Doctrine, particularly last night, because basically, I was saying I find it hard to sort of support a library like Doctrine because I really do see it as like a tool I use, rather than the thing that makes me the money.

Dave 49:48 So you as you move further up this, because it's one component of a larger application versus the foundation for application. I think we were comparing it with things like Drupal, Symfony, Laravel, and how the support they get. Because it was, I think this is Jonathan Wage, that mentioned on Twitter about, he'd love to work on Doctrine part-time or something if he could find it.

Beau 50:14 Or, yeah.

Dave 50:16 And it just seemed far fetched, no not far fetched for me, it just, it doesn't attract the same kind of message.

Ben 50:23 It would be much easier if Doctrine was sort of part of Symfony, and would belong to the Symfony framework or any kind of other library, like Eloquent belongs to Laravel.

Dave 50:37 Yeah.

Ben 50:37 Makes it much easier to have this as one big package. And, yeah, so since I worked a lot on Doctrine myself, this was always something we thought about, like how would it be possible to get paid from the community to work on this full-time? And it's a very, very hard problem for a library to find a solution for.

Dave 51:05 Hmm.

Beau 51:05 Well, bringing this back to the SQL Server pricing question, right? It's like sure the database is core to your application. But at what point is SQL Server driving the value to pay $14,000 per core for the enterprise license versus PostgreSQL, which you can get for free. But you can pay for it if you want to, I think, right? Or you can get it for free. I mean, what's like, maybe I'm just completely out of the loop on what SQL Server can do for an enterprise.

Beau 51:41 But really, what's the value add there that people are willing to pay that but wouldn't be willing to pay for PostgreSQL?

Ben 51:48 You're clearly out the customer for SQL Server.

Beau 51:51 Yeah, well, clean-

Ben 51:53 There are surely aren't enough customers for it. Sometimes-

Beau 51:54 Yeah.

Ben 51:55 -Sometimes you can't see it because you're not the, you're actually not the customer. And part of the problem-

Dave 52:00 Yeah, I mean, I mentioned, if you want a particular software package that relies on SQL Server then-

Ben 52:06 Yeah.

Dave 52:07 -If you really want that package, you're going to be prepared to pay for SQL Server. That's usually the way it is I imagine. Or if your windows network is big enough, I'm sure that whatever, it's a long time since I've used-

Ben 52:21 What?

Dave 52:23 -that kind of thing. But if you've got 2,000 Windows users, they have to have it backed by the SharePoint half to SQL Server, whatever, I don't know. Do you know what I mean?

Beau 52:34 Hmm. Yeah. No, no. That makes sense. It's the same, it's a similar question, right? Like, Doctrine's a tool, versus if it were a part of a framework, then it wouldn't be and then it would be getting funds from Symfony because Symfony's its own community now and its own company that gets funding or whatever, right? It's, just looking at the various aspects of software and projects and packages, and clearly there's money-

Ben 53:04 Yeah.

Beau 53:05 -and some way to get it, but there are a lot of other places that it doesn't exist.

Ben 53:12 Your user base, I think, has to be massive to be successful with an open source product, and you have to cover a lot of ground, you have to be able to help users in a very, very large way. And this is why things like WordPress, Drupal, Symfony, Laravel, Magento and all these kinds of things work because they have this very big ecosystem.

Ben 53:37 They already provide an almost finished solution for a problem. And this way they drive a lot of value, and that makes it much easier to build a business model around it, I think than on a particular library. But this is just my, I think, my opinion about how I think open source and business models could work or not, but I believe it requires a very large user base and community.

Beau 54:10 Cool. I threw that one out there just kind of randomly. So thank you both for discussing that a little bit more. I don't have anything else. And Dave you?

Dave 54:19 No, I'm good.

Ben 54:20 I'm also good. Yeah. It was very nice to talk to you.

Dave 54:23 Yeah. Thank you for coming.

Beau 54:24 Yeah, thank you very much. All right. We'll call this one a wrap.