E001: Open Source in the Enterprise: Building Composable Systems Without Vendor Lock-In

Sven Al Hamad (00:00)

Welcome to Enterprise Engineering, a podcast by Webiny, the composable open source content platform for enterprises. I'm your host, Sven Elhammet, CEO and co-founder. Since this is our first episode, I invited Pavel, my co-founder and the Chief Technical Officer of Webiny. Today, the two of us will be talking about what it means to be an open source solution in the enterprise space, it means to build composable open source systems without vendor lock-in, but also...

talk about some of the common struggles and challenges that enterprises are dealing with, and discuss what serverless infrastructure, open source, and more brings to the there will be a lot of market insights and knowledge that we'll be sharing in this episode. So if you find it useful, we would really appreciate it if you would subscribe to our channel and to our podcast. Okay, let's dive in.

Sven Al Hamad (00:45)

kick off the conversation, let's talk about composability. What it means to be a composable platform. There's a lot of marketing terms and in a way marketing fluff when we talk about composability. Many vendors say that they're very composable, but they're only composable within their own ecosystem, within their own modules. They don't really compose outside of their solution to be truly integratable, or they just do something very simple like, hey, here's an API, that's all you get from the composition aspect.

which I don't think it's truly serving the term of what a true composable solution is. When we talk about Webiny and the way we made the platform composable, it's totally different. We compose, we add the composition based on plugins, lifecycle events, hooks, CI, CD, many, many other aspects of the platform. It's not just that, hey, if you use our headless CMS, you can also compose and use our page builder. We go way, way beyond that. But I'm curious, Pavel, to hear what are your thoughts on that? Because you...

are one of the main engineers building the whole architecture that has to deal with being a truly composable solution.

Pavel Denisjuk (01:47)

Right. So it's a very wide topic, but it's a very interesting one. And it goes all the way back to how you architecture your solution and what the end goal of your product even is. Over the years, we, even as Webiny as a product, we evolved drastically and our, the whole view on the problem changed over the years as we were working with ever larger companies and we were challenged to

Enable composability and bringing in third-party services and as you mentioned API integrations all that all that stuff and At some point you have to make some assumptions because you don't yet know what there is and what the requirements will be and so you start somewhere as We did back in what was it? 2019 I think when we started page builder and our only goal was let's build a page builder. We were not very much focused on

how it's going to integrate with third party services and so on. We just wanted to kind of tame serverless, right? That was our goal. As we brought on some customers, new requirements came in. And so we evolved through that process and started to refactor our architecture, know, enable certain parts of the system to be pluginable. And then sometimes we even had to rewrite everything because it just wasn't even ready to be integrated with anything. It was just a...

you could say monolithic product and that's it. And that's where you start. You start with an assumption and then you have to get feedback. And that's the best way to build your product. So when we get to actual composability, the way I think about it, well, you always have some kind of a product, which for us is a content management platform. We have a headless CMS, we have a page builder, right? This is what you get out of the box with our product. But very often,

And usually it's not even very, it's more often than not, you don't have some features or you're lacking integration with, I don't know, Salesforce or I'll just throw some names as an example. And how do you make it possible? There is no way you can just foresee every possible integration and even implement and maintain it. So the best way to approach it is to first design a very

Convenient public API. That's something we learned over the years that the first thing you design when you build a new feature or even think about a piece of architecture is how will third party teams Integrate with it. How will they customize it? How will they add their own? plugins

Sven Al Hamad (04:10)

So

Sven Al Hamad (04:11)

To jump in there, basically what you're saying is that people can't just build a solution and let's say add an API or multiple API endpoints afterwards. You need to design your solution from the API side. You need to think about how people will consume and integrate with your solution. And it has to be one of the starting points.

Pavel Denisjuk (04:30)

Yeah, that's what we learned through the years. Of course, we ourselves as a young company, we started the other way around as everybody does. You focus on your own product. You think that it's super powerful. And then as you get customers, you're like, it's not really that powerful because look, we have a blocker there. We lack integration points here. And so over time, you just completely inverse the approach. The first starting point.

of every software product should be, especially in open source. I'm even talking about, know, okay, fine. SAS is a different area entirely, but if you're open source and even self hosted like Webiny is, you have to start with the integration APIs first. And you do all you can to design a very convenient, you focus on developer experience, of course, you work on your APIs and then the challenge is how you.

integrated internally, so everything works nicely and is modular and testable and deployable correctly and all that. But your user shouldn't worry about it. So public API is the king.

Sven Al Hamad (05:32)

And when it comes specifically to Webiny, when we talk about APIs and composability, like a SaaS where the whole premise of composability, even if they allow it, is based on something like a GraphQL API or RESTful API, right? But when you're dealing with an open source, self-hosted solution, the composability integrations,

And when we use the term API, it has a much wider meaning because we're not only talking about the HTTP layer, but we're also talking about the code level. So how do you call a specific function? How do you call a lifecycle event or a hook? So those integrations are done at a much, much deeper level. And this is where I think we can use the true word and the true meaning of the word composability.

Pavel Denisjuk (06:12)

Absolutely. That's a great point you brought up because in the self-hosted environment where another engineering team has the full project under their control, the area that they can interact with is much wider than just a SaaS restful endpoint or something. You have CLI plugins, you have infrastructure plugins, there are events firing left and right.

before, begin, after, and all of that good stuff. People can connect, they can do their own validation before deployment, after deployment, trigger, cache flushing. There is so much more going on than just saying, I have a webhook when I save a form. That's what you usually get with SAS solutions. It's like, we have five events which you can hook into by registering the webhook, and that's all you get, period.

The self-hosted solution, there are many more layers because there is, as I mentioned, there is CLI, there is infrastructure, there is backend APIs, there is front-end applications. And very often, as you also mentioned, people sometimes even build an entire layer in front of your API to make it more suitable for their engineering team to build their business specific content and components.

So when I say public API, what I actually mean is actually each one of those layers has to have a defined and easy to use way of extending. So CLI, for example, there has to be a way to add plugins to CLI. So you have to define all those hooks and allow people to easily add code because the moment itself hosted, you have to deal with code. You have to be able to add code.

Sometimes you will even want to replace some of our, I don't know, NPM packages if you don't like something, right? So it has to go that deep. with our product, we learned it sometimes the hard way. Some things were designed the right way from the very beginning, but most of the things were just a process of iterating and listening to customers and just getting feedback and, oh, we are missing that thing, so let's go at it and...

Again, you don't just add stuff to your product, you have to really be strategic about it and think about not hurting the overall API design and all that.

Sven Al Hamad (08:19)

Yeah, that's kind of...

Sven Al Hamad (08:24)

I think the best way to design a product is to design it together with the customer. The customer need drives the product roadmap, right? But on the other end, when you're dealing with possibly a close-saw SaaS solution, it's very limited what we saw. It's super hard to have proper business processes designed the way you want them. Often people have to do workarounds and similar. And as a result, the business suffers, the performance suffers.

the overall experience is just mediocre.

Sven Al Hamad (08:51)

Moving on to another topic, like traditionally, yes, open source had this advantage of being highly customizable, composable, integratable. But the downside usually with open source was that, hey, you have to manage the infrastructure, have to scale the infrastructure. There's a lot of cost related to with that on the DevOps side, you need to allocate team members to do that.

That was more of a, let's say a traditional, in sort of a way, a legacy hold back for many enterprises to adopt open source solutions. Some did adopt it, but a lot of others are still holding back. Now, one of the, for example, the engineering decisions we made with Webiny was that we knew we wanted to be open source, but we had in mind, well, we need to eliminate

that downside of self-hosting an open source solution. And that's why we decided to pick an infrastructure type that eliminates a large part of that maintenance, security, patches, upgrades, and all of that. And we decided to build Webiny on top of the AWS serverless infrastructure. The serverless infrastructure allowed us, first of all, to offset all of that maintenance work to the cloud vendor.

It allowed us also to use services like lambdas, S3, DynamoDB that pretty much scale in and out within milliseconds or seconds to handle on predicted load because traditionally we saw enterprise customers usually provision their infrastructure for peak demand, which only happens like less than 1 % of the time purely because they need to protect themselves against flash crowds because if

even if you have a scalable EC2 instance, it doesn't work if you need to scale in and out really, really fast because they do take several minutes to scale. So with the choice of serverless, we brought down the cost, we improved the performance, we improved the security, right? But there's still some, let's say, hold back even today with regards to serverless where there's more...

Hey, you have cold start issues and things like that. What's your view on that? Are the cold starts even a thing anymore? Or do we feel like from our customer base that we had customers saying, oh, there's always a cold start, my customers are suffering. What was your view in dealing with our customers so far with having a solution built 100 % on top of serverless infrastructure?

Pavel Denisjuk (11:15)

That's true. A lot of teams are still kind of holding back from adopting serverless or even going into the cloud. And I think a lot of it has to do with just doing stuff the same way for many, many, many years. It's just a habit, basically. And not many teams have enough time to invest into actually experimenting, building a PLC on top of serverless, for instance. So it's kind of this area where not

that many teams still have experience with, so they just want to stay in the secure space where they know what they're doing. And even though it's maybe outdated, again, I'm saying maybe because there is nothing wrong with the old ways of spinning up your hardware and having data centers and everything, there are pros and cons to everything. But I think it has more to do with kind of just experience and knowledge.

about a specific technology that usually holds teams back. Cold starts, they were a thing back when we started Webiny which was five years ago, I think, maybe something like that, right? I mean, we suffered cold starts as well, but things improved so much over the years that over the past, I think, three years, we haven't heard about a cold start issue from a single client. And we have some really big websites running on top of Webiny.

We have yet to hear a complaint about a cold start. So I don't think it really is an issue. It's some of this, again, lack of information in this space, right? Where people just read an article somewhere, somebody mentions cold start and they just say, it's like a verdict. cold starts, they're slow. My API will be slow, period. Nobody even wants to investigate and kind of learn more. How do, because there are ways to mitigate it. You know, if you really need to push your lambdas to like to extreme performance, there are ways to do it. It's just, you need to

Sven Al Hamad (12:58)

Exactly.

Pavel Denisjuk (12:59)

dive in, you need to read the docs, you need to experiment, and as usual, you need to optimize for your use case. There is no silver bullet for just making the cloud super fast. It's always on a case by case.

Sven Al Hamad (13:07)

Yeah.

It's... It's...

Sven Al Hamad (13:13)

and especially if you see an article from like 2021 2022 cold stars big problem

Sven Al Hamad (13:18)

And you might think, that's fairly new article, right? So it's still a thing. Serverless has evolved so, so much in terms of performance in just last two years, that it's a day and night difference. yeah, I mean, as you said, we are not getting any feedback that Cold Start is an issue. And we run...

all of the workloads on the serverless infrastructure. So, but that, I just want to say like, this is kind of like one of the advantages that serverless brought to the market, specifically to commercial open source projects where now you have an open source self-hosted solution, which allows you to customize it, which allows you to retain your data, your privacy, the control of the data, where it's stored, who can access it. All of that stays within your organization.

But at the same time, you don't need to pay that premium of infrastructure maintenance, scalability, security that you didn't configure something correctly. Because with serverless, everything is configured for you. So there's tremendous benefits in that. That specifically unlock a lot of potential for enterprises and reduce significantly the cost. We saw some customers cost reductions up to 80 % of the infrastructure just by switching those same workloads.

from a legacy solution running VMs to a modern solution like Webiny on top of serverless infrastructure.

Pavel Denisjuk (14:39)

Yeah,

benefits of using the serverless and not just serverless. mean, any cloud infrastructure benefits are just tremendous. I remember back in the days when you and I were running a web agency. mean, you the amount of configuration we had to do on the servers, but it was what 2014, you know, there wasn't a better option back then. We were just crying day in, day out because I want to spin up a project and solve some business problems. I don't want to configure hardware, right? But you have to, period. You have to.

Sven Al Hamad (14:58)

Yeah, yeah.

Pavel Denisjuk (15:08)

Now there is this cloud which is really, it's still young. It's still super young, but it's at a level where you no longer have to worry about, will my server go down because Black Friday, right? It won't. You might pay some extra for hits, but again, there are ways to optimize stuff. But in general, you go to sleep and you know that your customers won't call you in the middle of the night saying, my web shop just crashed and nobody can buy my product.

So I think that is the single largest benefit. I mean, there is a huge list of benefits, but that one is the largest one. Every company, I mean, not just, but even small companies, especially small companies, because they don't have the benefit of huge surplus. They have to sell to every visitor they can get. And if your website just goes down because you have five...

more visits than you expected, it's just bad for everyone. You suffer as an agency or a service provider, the company might go out of business because they lost 200 customers that night or maybe thousands of customers. when people think about infrastructure, usually, especially engineers, they only focus on the technology part of it, but there is a much larger part above. It's like an iceberg, right? Where you see, infrastructure and...

engineers play with infrastructure, but then there is a huge iceberg under the water, which is business and people and, you know, jobs and companies that are trying to sell their super new products. And it's huge. When you, when you take a step back and think about what is, what is technology actually powering? Like, why is there technology? Why is there this cloud, right? Who needs technology just for the sake of technology? Nobody.

technology actually evolved from business needs, business requirements. So once you look at it that way, then you actually see huge benefits of using cloud and especially serverless where it just automatically scales and it doesn't cost, you don't pay when you don't use it, right? All those benefits that might sound simple and superficial, but they're not. you, the end of the year, when you do the math and you know,

The bottom line is the most important thing for every business and then they see the benefits of using Serverless.

Sven Al Hamad (17:16)

And what's in your view preventing more organizations from adopting building on top of serverless? Because it's so great in terms of performance, it's security, cost. Why isn't everything running on serverless? Because there was a big hype like a couple of years ago, serverless is the future. And well, we were part of on the hype train. But in our view,

The hype was real and we still see the benefits of doing it on top of serverless today. And if we needed to make that decision again, I don't think we would make a different one. We see truly the benefits serverless brings. So why didn't more people adopt it? There is an adoption and pretty much every enterprise is running serverless workloads, just not in the amount that everybody was expecting.

Pavel Denisjuk (18:01)

Yeah, you see, you said a very, very interesting key keyword, enterprises. Enterprises, many of them have the benefit of dedicating an R &D team to build some POCs or small products and explore the technology. Smaller companies and startups, they don't have the benefit, nor funding nor time.

to say, let's spend a month learning this new serverless thing and building a POC, seeing what we can do with it. There's just no time and money to do that. Enterprises are going in because, first of all, they have larger engineering teams. They can spare five engineers as a dedicated R &D team and say, hey, guys, let's build a POC. Here's a small product we want to launch. Let's play around with it. And first of all, learn the stuff.

explore, see what benefits there are. And secondly, if it's a successful PLC, we can then do cost analysis, know, cost efficiency, all the business related stuff that is super important for enterprises, especially, mean, their scale is something completely different. Until you work with enterprises, you don't really understand the scale at which they operate and what it means to have 15 minutes of downtime. It's just, you know, it's

completely different world. It was shocking given to me and we are working for many years with enterprises and I learned a lot and changed my mindset tremendously after working with some of these companies. back to the topic. It's I think first of all, there is a lot to learn about serverless. I mean, it took us ages to build a page builder which renders on serverless. Do you remember the amount of R &D we did and failed BOC and

Sven Al Hamad (19:33)

Yeah.

Pavel Denisjuk (19:35)

Without docs, mean, AWS has a lot of docs, but they're not the easiest to navigate. They're not the easiest to find the right information and some information is even outdated and so on. And a lot of it boils down to trial and error and just spending days and days and days and days until you learn something. So not many people have the luxury of time. Webiny went all in. We just said, we do serverless, period. We want serverless. We want to be...

Sven Al Hamad (19:55)

Yeah.

Pavel Denisjuk (20:01)

the experts in serverless, we want to build products which work and run on serverless. And so we just dedicated our whole time to that. So we just went through this tremendous learning curve and now we can consult, we can help our clients to not repeat the mistakes or just avoid them altogether. So there is a lot of learning that has to go into serverless and that's why I think many teams just...

Avoid it. They you know who has time for that. That's kind of the main argument in the engineering teams I'm too busy. I have too many tasks in my JIRA, know who has time to learn serverless so it always ends in the backlog and so people are Just losing the even the opportunity to to try it because once you get into it once you get used to it and learn all the quirks you learn how to avoid some of the pitfalls and

you can actually build really, really scalable things with it. And there is also some pushback from DevOps teams, because they think that they'll go out of business because, there won't be any more service. That's just not true. You still need DevOps because it's just the focus of their work is shifting slightly. They're no longer installing operating systems. They're focusing more on running the architecture, monitoring, all that stuff.

Sven Al Hamad (20:58)

Yeah.

Yeah.

But that...

Pavel Denisjuk (21:11)

I think

it's not enough information still, even though there are many great platforms to learn cloud and serverless. I think it's still not as widely available. The information, I mean, right?

Sven Al Hamad (21:22)

The barrier to entry is pretty big and the learning curve. That's, think, what you're saying and that's what we also see in a way. like, when we, again, coming back from our own experience of building Webiny, we knew that, well, even if we build Webiny on top of serverless infrastructure, people won't deploy it, right? Because like if we give them, hey, you need these 15 lambdas, these 20 SQSs and five...

DynamoDB tables configured in a specific way whatnot, it's not going to fly, right? So one approach we did there was we knew that we needed to automate the whole deployment, that people even don't need to go into their own AWS account at all. Everything has to be done for them. So this is why we stepped into the realm of infrastructure as code, right?

and making the whole thing declarative in terms of that you know what infrastructure is being deployed through code, that you can configure it through code. And in your view, how do you see this working out today? Do you feel like the infrastructure as code was the right approach, or do you feel like there's still in this industry more things that need to be done in terms of making lives even easier for large enterprises, or do you feel like

Hey, this is working out well today and like, yeah, it's the best practice. Like what are your thoughts on that?

Pavel Denisjuk (22:44)

Yeah, infrastructure as code was definitely a game changer for us. Even back when we just started, we were essentially writing CloudFormation templates and debugging it and you have to deploy, then you wait for 15 minutes. If something fails, you wait for 15 minutes for it to roll back. this deployment loop, the feedback loop is just so long. you waste, basically on every deploy, you waste half an hour of your life. So then luckily there was

Pulumi, which we discovered a bit later in our journey, which was a real game changer. I just love what they did with infrastructure. For those who don't know, Pulumi's infrastructure as a code tool, which has SDKs written in a variety of languages. So it's not just a YAML template, right? Or it's not a Terraform, you know...

proprietary syntax or language, call it whatever you want. It's, Pulumi is built on top of Terraform, but it really makes it great because you can work with your infrastructure as code. You can actually write functions and it's very easy to make the code run conditionally. especially for Webiny where we have, you know, free tier and we have some enterprise features.

It's super easy to enable parts of infrastructure based on your license. So you can have conditional templates for your deployments, which is very hard to achieve with YAML. I mean, it's doable to some extent, but it is the friction is just not worth it. So with, with Pulumi, was a real enabler for us. We did add an extra layer on top of Pulumi to make the whole process even more extendable because even though we, we, we

ship a huge part of the infrastructure setup for Webiny, which you can just deploy and you don't need to worry about what it is, which resources are deployed. As you said, we don't want our users to know about which lambdas we deploy. I mean, it's all in their account, but they don't need to bother with it if they don't want to. And so Pulumi allowed us to do that, but on top of it, it allowed us also this extendability, which is super important to us, where people can just say, I have this Webiny.

Pulumi program and then I can hook in and change something, maybe change memory limitations, add some environment variables, even replace code in those Lambda functions. So there is a lot of this that was given to us by Pulumi that we just, know, to tweaked a bit more to make a system extendable. And I would never go back to anything which is not controlled through code. mean, engineers love code because

then you have your favorite if statements, which everybody loves, and then you can build conditional templates. And that's basically what enables you to build whatever.

Sven Al Hamad (25:17)

And I think like this one other aspect that this unlocked, which is really important to enterprises is the fact that number one, you can run CI CD pipelines, but it unlocks the ability to have multiple environments, short lived, long lived, because well, in an enterprise space, you don't just go deploy to production, if you do, you're very brave. So, but here like,

Pavel Denisjuk (25:38)

Yeah, from your laptop.

Sven Al Hamad (25:42)

you now have all of your infrastructure designed as code. And what we did, for example, with Webiny was A, if you are doing production deployment, you can deploy much stronger lambdas and whatnot. But if you're doing other environments, you can just pause this flag and we'll deploy weaker resources so you don't spend more money there. But you unlock this multiple environments, preprod staging.

QA, whatever, and it's so much easier to manage. And I think this is also very important because no enterprise will adopt a self-hosted tool that doesn't give you out of the box management of these environments. I mean, there are many open source solutions that don't go this far as we do, but that just leaves a lot of room for mistake.

Pavel Denisjuk (26:26)

Yeah.

Sven Al Hamad (26:29)

for the enterprise to do things in the wrong way. That's why we give an end-to-end package. There's a CLI, there's a deployment, there's CI-CD integrations. You get the whole thing out of the box with all of the best practices built in. But some, like that infrastructure as code, I think it's so critical to the overall experience of hosting a self-hosted solution. Because if you need to figure out that piece of the puzzle,

it's gonna cost you a lot and you're risking big mistakes in that end.

Pavel Denisjuk (26:58)

Yeah, that's actually, I even forgot to mention it, but you brought it up, which is basically what you get with infrastructure as code is this ability to build configurable presets where you can say production true, let's say, right? Simple parameter like any other function. But what you get out of that preset can be completely different to what you run in development, especially in terms of VPCs, the size of your...

elastic search domains, for development you don't need to pay 500 bucks for a domain. In production, you might want to have the most powerful cluster deployed. So this allowed us to have these presets and when companies come to us and say, hey, can I bring in my own VPC? We just say, yeah, we have a parameter for it. Just either say VPC true or it accepts an object and you can give us your subnets. And why I'm mentioning VPC, because I think it's...

One of the most fiddly thing to configure when you are deploying to AWS cloud, and I think any cloud in general, is just a very difficult topic. And every service has different configs for VPC. So it's not just flipping a flag to true and all of a sudden you have your VPC. No, every service has to be configured differently. And that's what we abstract away from our users. We just give them the ability to either...

Sven Al Hamad (27:51)

Enjoy it.

Pavel Denisjuk (28:14)

opt in and say, I want VPC true, and then we create subnets, or you just give us your own subnets and we will configure the rest for you. As you mentioned, the products that don't come with these presets or deployment templates, users of those will usually spend more time building those deployment templates than actually using the product. And there is a huge risk of users eventually giving up and just saying, I'm not using this because it can...

My template can change or break at any time, and I don't want to maintain this.

Sven Al Hamad (28:43)

And coming back now to the very first topic of composability, right? Because for example, in our case, by utilizing infrastructure as code and having that example of, hey, we can create VPC for you, but if you have already a VPC configured, give us the subnets and we will deploy Webiny within that subnet. This is composability on another level. We are integrating Webiny within the existing

cloud setup that you have because usually in front of those VPCs, you're going to put different systems. You're going to put the different WAFs and security. And now if you put a system behind all of that, that system is also getting the advantage of all of that protection. So we're now adding composability on a totally different level. It's not

Pavel Denisjuk (29:17)

Yeah, observability tools.

Sven Al Hamad (29:33)

my webhook sends my data from my system. This is on so much deeper level that you can truly feel like this system is part of your ecosystem. Which I think is...

Pavel Denisjuk (29:43)

Yeah, the level

of customization is off the chart. I mean, from experience, we had crazy requirements. What you guys deploy, like I'm listening from the customer's perspective, they come to us and they say, yeah, Webiny is perfectly fine. It deploys, works. But we have our own Cognito user pool and you can't deploy your own. We are not allowed. Our company policies that you are only allowed to use that particular user pool.

and we only have those three cloud fronts that we need to wire up to your system. Like, man, we can do that because we actually allow you to customize our deployment and do whatever you want, add stuff, even load in existing resources using, I mean, that's totally Pulumi's feature, right? All the credit here goes to Pulumi, but we are using the tools that allow you all this flexibility, which also then translates into our product.

being more flexible and adoptable at the same time. So engineers are a bit, they're stressed less about the amount of work that they have to put in to wire up those constraints that they have.

Sven Al Hamad (30:43)

And you make a good point there because for example, we have Pulumi and then we have our own abstraction layer in front of it to make things much easier for the end user. But we benefit from having all of that flexibility and customer's ability that Pulumi allows. But then there's an extension to that because for example, one use case we often see with Webiny is that people go to the market, they have a specific product that they need to build.

And they look, hey, is there an off-shelf SaaS solution? There often isn't, or there is one that gets them like 60, 70 % of the way, but not 100%. And because it's a SaaS, it's a closed box, you can't do anything with it, right? And then they think, oh, I now need to go do it yourself route, where I need to build everything from the ground up. And that's a big hassle, big investment, time, maintenance afterwards, security to consider, infrastructure to manage.

It just blows the whole project out of proportions. But having an open source solution like Webiny, again, that sits somewhere in between. We are SaaS, but we're a commercial open source self-hosted SaaS. So we give you a bunch of tools out of the box. And we might also get you 60%, 70 % of the way. But because we're open source, you have the ability to build on top of Webiny.

those 30 % that are unique to your business, that are your secret sauce and make the whole platform fully tailor-made to you. And that's kind one of the other advantages of this is composability beyond. You're now using a solution as a foundation for your own product. And open source unlocks that.

At the same time, you don't need to worry about all of the security because we give you a security framework. You don't need to worry about the organization of your code, build mechanisms, infrastructure is good. All of that is there. Plus you get a super scalable headless CMS or whatever off the shelf stuff you want to use. And then you just add your own business logic on top of it, your own modules, screens, UI, whatever you want. And this is, think, a true advantage of like, yes, there's SAS, then there's...

composable solutions. And then there's this open source composable, which goes so much further than any of the others, Which is, I think, an awesome time today because you get a lot of these open source solutions, self-hosted and stuff like that. If they added this other end that we did with infrastructure and all of that, it would be much easier for people to build many, many great products on the open source or commercial open source.

and instead of using SaaS. But coming to another topic, switching gears here, we need to talk about vendor locking. What does vendor locking mean in terms of, let's say, an open source solution that's self-hosted versus a closed source SaaS solution? How do you see vendor lock-in? For example, from our customer base, do our customers feel like they're locked in and that in a way, we are

competing to other products in terms of how hard we can lock you in and how hard we make you to migrate, or do we compete on who builds a better product at the end of the day? Because if you make your system super open, you are vulnerable more for customers moving to a different solution, but the customer will move to a different solution if that solution has better features, better price point or whatnot. So you competing on a different playing field than just

having a hard time locking. What's your view on that?

Pavel Denisjuk (34:08)

So yeah, I mean, there is always some degree of a vendor locking, always. It just depends on kind of the area of the locking. With SaaS platforms, the locking is usually on the data side because all of your business data all of a sudden now lives somewhere. You don't even know usually where it's hosted. And some of the products, we won't go into names, but some of the products don't even allow you to.

to do a bulk export of all your data. It's that bad. You're paying monthly fees, yearly fees, whatever. At some point, the vendor changes their pricing because they know you don't have a choice. And now you want to move away from it, but how do you export your data? And they say, no, we don't have bulk export. Sorry, we have RESTful APIs, so write your scripts. And for companies that have millions and millions of records and...

like complex data models and stuff, that's a huge undertaking. So with SAS, lock-in is on the data side. I won't even go into data privacy. It's just a topic of its own. But the fact that it's difficult to access and extract your data and move it somewhere else is a big concern, especially for serious enterprises. Now with open source, you remove that, especially with self-hosted.

solutions like Webiny, you own your data because you deploy it into your own AWS account. So at any point in time, you can just download the whole Elasticsearch and just do the export of it or DynamoDB table, right? You own it so you feel safer from that standpoint. You know that your company owns that account. It will never go away. Nobody will be able to steal it from you. So you are safe from that perspective. Now, the lock-in can become a bit...

a bit more obvious on the code side of things because, well, there are always companies that don't even customize. They just run with the out of the box solution which you provide. It satisfies their business requirements. And those companies are usually the happiest ones because they don't have the burden of maintenance of customizations, of plugins, of whatnot. So those are like ideal scenarios where enterprises just come in, they self-host and they have all their data plus no customizations. So...

They just receive whatever features and patches we ship and everything is great. With enterprises which go into lots of customizations, they add tons of custom infrastructure, they add a lot of plugins for front-end or for their GraphQL APIs, locking starts to feel slightly in that area. It's no longer a data locking. It's kind of, if I can say it's a feature type of locking because...

For example, you build a headless CMS custom field type, right? And you build a custom renderer which is super complex and whatnot. And it's in React because Webiny is React. We use React for our frontend. And all of a sudden, let's say reasons are not even relevant, the company decides that they want to switch to a product which runs on Angular. Just as an example, you can't migrate your React components easily to an Angular product, right? So that's the lock-in I'm talking about.

Sven Al Hamad (37:05)

up.

Pavel Denisjuk (37:06)

But you can migrate your data because you have access to it. So the lock-in manifests differently. And I think it's less stressful to companies when it's just on the code level, because again, you can refactor that easier than when you don't own your data. Data is your business. It's like everything you own in the company is based on the data that you have in the database. You can write a new plugin. That's not a big deal. And so...

There is a bit of that in self-hosted products like Webiny where you have to kind of agree with us on the technology and you don't have much choice because if you say you want to do plain Terraform, you don't want Pulumi, you actually want to write Terraform or you want cloud formation templates, you're on your own, right? You have to write them yourself.

Sven Al Hamad (37:29)

It's a moribund.

It's more of a tech stack lock-in than a vendor lock-in. But with open source, you do own the data. And I think in today's world, where we have a ton of AI and ton of SaaS vendors building and training LLMs on their customers' data, you start worrying about your data bit more.

Pavel Denisjuk (37:49)

Yeah.

Sven Al Hamad (38:11)

Now data, as you said, data is your business, right? But it's also a raw ingredient that everybody's after, right? So I think there's gonna be more and more regulations, more and more privacy concerns with where's my data, who can access it, what can it be used for and stuff like that. And when you are a large enterprise, you often come with a large data set. Thus, yeah.

Pavel Denisjuk (38:33)

already, right? You don't build it from

scratch. You're bringing it in with yourself and it's just,

Sven Al Hamad (38:37)

Exactly. And

I think like in today's world, more and more companies will start self-hosting because, A, self-hosting is now easy, right? Especially with serverless, as we mentioned, where everything is done for you by the cloud vendor. It scales, it's secure, but you own it. Only you can access it. Nobody else can access it. Even in Webiny instances, we do not have access to our customers' data. Only customers have.

So the vendor lock-in, like it's, as you said, more in the tech stack slash features, but the biggest importance is where's my data? Can I easily move it? And with self-hosted solutions, you usually can. And that's a tremendous benefit. While on SaaS solutions, as you mentioned, like there's many big SaaS vendors and platforms with thousands of features in there. But one feature that a big proportion of them are lacking is

Give me my data. Is there an API point that says, give me my data? I want all of my data. Usually there isn't. They make it intentionally hard. it's by design. And it's a bad business practice. Because for example, our view is, let's compete on who has the better solution and allow the free flow of the market. It's like with banking. Banks don't have a lock-in on you. You can always switch a bank.

Pavel Denisjuk (39:36)

There isn't. Yeah, it's my design.

Sven Al Hamad (39:55)

because they're regulated by the government, right? And that means that the banks need to provide better services, cheaper services, better mobile apps, web apps, net bankings and stuff like that, which is where their focus should be, right? And doing that same thing on the internet in terms of building products, I think would just benefit the whole ecosystem in general. All right, any final thoughts from your end on that one?

Pavel Denisjuk (40:20)

No, I think we covered quite a lot of ground there.

Sven Al Hamad (40:22)

Yeah, I think we did. I think we did. And hopefully our audience will love it. Again, this was our very first episode, so we would appreciate everybody who was listening in to give us some feedback, subscribe both to the podcast and the YouTube channel. In future episodes, we'll have both some internal team members discussing some architecture challenges, feature challenges, but as well, we'll be bringing in guests who are industry experts to share their insights and knowledge about

what it is to work in an enterprise space, build features for enterprises, build products for enterprises. And our goal is just to bring back a lot of that knowledge back into the community and hopefully help everybody and have a more enjoyable time in this space and build better products for everybody. So cool, awesome. Well, I'll see you on the next one, Paul. Thank you for your time and well, I'll see you. right, all right, bye.

Pavel Denisjuk (41:09)

Thanks for having me.

Cheers.