ALTERNATE UNIVERSE DEV

Serverless Chats

Episode #57: Building Serverless Applications using Webiny with Sven Al Hamad

About Sven Al Hamad

Sven Al Hamad is co-founder and CEO of Webiny Serverless CMS. Sven has worked with the largest media and ecommerce customers in Europe as their trusted advisor on the topics of web performance and architecture, and has a proven track record of successful delivery of several multi-million dollar projects for large enterprises. Sven is also an experienced entrepreneur who has acted as a CTO in 4 different startups.


Watch this episode on YouTube: https://youtu.be/9TSmOcLBr0k

Transcript

Jeremy: Hi everyone. I'm Jeremy Daly and this is Serverless Chats. Today I'm speaking with Sven Al Hamad. Hey Sven. Thanks for joining me.

Sven: Hey, Jeremy. Thanks for having me.

Jeremy: So you are the CEO and co-founder of Webiny. So why don't you tell the listeners a little bit about your background and what Webiny is?

Sven: Yeah. So well, in terms of my background, I'm a developer. I started maybe 20 years ago, even more coding websites and many other stuff along the way, but also worked in the enterprise world for several years and decided to start Webiny about a year and a half ago, maybe two years back. But now I'm more focused on the business side. And what Webiny is, it's essentially an open source framework for building full stack applications that deploy to serverless infrastructure like AWS Lambda and similar. So it's all about creating serverless solutions.

Jeremy: Awesome. All right. So that's what I want to talk to you about obviously the Webiny platform, what you can do with it. And I'd like to start by kind of going through more of the details, right? Because I think we get confused with maybe what a CMS is versus what a application platform is versus what a cloud provider is. I mean, so I think it can get very confusing if you don't dive deep into the docks and even I was looking at the Webiny site and I was like, "All right, it's a CMS, but it also has a framework for building things." And so I'd love to go through that. And then we can talk about a couple of other things just to get your insight on serverless, but let's start at the beginning. So why did you build Webiny? What was the thing that triggered that?

Sven: So I started researching the serverless market in general. That was late 2017 and the more I dived deeper into the potential of serverless and serverless infrastructure, I kind of understood that serverless has such a big potential that actually it can become the standard, how we are building all applications in the future. Essentially, if you want to build an application five years from now, you're going to build it on serverless infrastructure. Serverless is going to become that standard.

And at the same time, I looked at the market, in terms of the solutions that are available today to help you do that. Well, there was nothing that I could use out of the box to help me build an application. There are tools to help you monitor and deploy serverless applications, but there are no tools to help you build actually a full stack serverless application. So I saw a big opportunity there, but also at the same time, I had a web design development agency many years back where we were all testing different CMSs and different solutions on building things. So from that learning and that experience, I decided, "Okay, let's take that. Let's take the serverless market, which is new and has great potential. Let's build a solution for that market that also is open source at the same time, so it benefits the whole ecosystem and the community as a whole."

Jeremy: Yeah. And who among us, hasn't owned a web development company in the past? I know I did for about 12 years and honestly it's funny because we built a CMS. I mean, CMSs were, this was before WordPress, right? So I mean, WordPress comes along and it changes a bunch of things. But one thing that was always a pain for me, and I know we can get into this as part of what the tool offers. But it was things like building forms. If I had to build one more HTML form in my web development company, I mean, I was ready to just, I don't know, go stick my head in a closet or something like that because it was just, it's so tedious, it's so repetitive. And as one of the things I think we've done really well or we've done a good job of is we've abstracted away a lot of these things and tried to make it so that where we make the undifferentiated heavy lifting, much easier.

But a big part of that, and this is something that always scared me, every time you build a new project, it's less about the interface, it's less about, maybe the backend, it's a lot about the data, right? We want to make sure that our data is secure, that our data is backed up. So I'd love to just talk about the data model that you have built into Webiny, because again, it supports a bunch of different things. But could you explain that?

Sven: Yeah, so well just handling data in a serverless environment comes with its own challenges. We found that really early on. So we decided to go with a MongoDB, particularly MongoDB Atlas to store the data, but how you actually talk to a MongoDB database from a Lambda function it's not the best today. If you don't use some specialized solutions, but you also find a similar problem with MySQL. That's why you created the MySQL library to help you do that. But essentially, what we did with Webiny, we have this notion of multicloud in our minds and we didn't want to get locked into specific databases. And we built a data library, a library that handles how we talk to databases and how we model the data models actually inside Webiny.

And that library is also open source, it's called Komodo and through Komodo, we built pretty much all the data models that you see in Webiny today in all our applications. And the beauty is that with Komodo, on the other side, you have these adapters for MongoDB. We also have an adapter for MySQL that's not published there, but we're planning on also building an adapter for DynamoDB and things like that. So we had to kind of also put some constraints on the data model. We didn't want to make it fully no SQL because we also want to support SQL in the future. So we put some constraints there but Komodo is kind of lifting off all the complexities there for us as a user. And on the other side, what we found is another challenge with handling pretty much TCP connections to the database. So we built, if you look at our architecture, we built something called the database proxy, essentially a Lambda function to which all our Lambda functions, talk to.

And only that Lambda function has the actual connections to the data, but it's like a funnel. So you can kind of limit how many connections you send to the actual database, reducing the number of zombie connections and so on. Some database have really, really smart abilities. So you can programmatically tell it, "Kill this connection or open another connection." But MongoDB doesn't have that. So it's pretty much kind of a, just having that funnel really low and then queuing up all the requests there. So but yeah, the data model has being a challenging topic for us there was a lot of iteration, a lot of work we did in Webiny, but now we've got it into a place where we're certain you can build really big business applications with it and it's going to handle any type of a use case.

Jeremy: Right. And then the other piece of it is the access to the data. So you mentioned that proxy that you've built, but in order to get that data back down to the website components or to interact with it in the admin, that's all built with GraphQL?

Sven: Yes. So everything's done via GraphQL and there's a bunch of scopes. You can pretty much control who can access what, which service can talk to what. Also when you create users, there's hundreds of different scopes and settings you can control in terms of securing your data and what you want to expose and so on. I mean Apollo server helps greatly there, but you still need to put quite a lot of logic in front of it. And also if you look at our architecture, it's all micro services with the central Apollo server through which everything goes to. So there was some also engineering there. How do you connect everything? How do you deploy everything? When you deploy something, how do you update the Apollo server? But again, this is something that Webiny just handles for you under the hood. And if you're just putting a new microservice, the Apollo server will know about it and it will just update your schema and the new scopes will automatically be visible to you in the admin section, under the security module.

Jeremy: Right. And so another choice that was made was to use React and not just on the back end, but also the ability to deploy these as components on the front end. And I want to get into that deeper, but just what are some of the basic reasons for choosing React?

Sven: Well, the whole story, when we decided actually, just to take a step back, when we decided to build Webiny, it was like, "What stack do we want to use?" Right? So we then looked at the market, looked at the market surveys. What are the trending technologies people use, trending stacks and libraries, right? Because we wanted to kind of tap into an existing ecosystem of developers, but also make it easier for the majority of the market to adopt Webiny without having a really steep learning curve. And we found React being one of those libraries that a lot of people in companies and organizations were adopting. So we just figured, "Okay, that's kind of a direction we want to go with and when we did adopt React, when we started to learning it, it was a really pleasant experience, what I want to say. But also some people asked me, "Hey, can I use Vue or Angular or other bits with Webiny?" Even like, "Hey, can I build an interfacing Python for webinar?"

And the answer is, yes, you can. Because how we architected Webiny is we've got these notion of stacks. We have an API stack that holds all your backend logic, done in Node, fine. But then the app stack is done in React and you can replace our app stack with yours and then you can code the interface in any language or stack you want and hook in to the existing GraphQL, API endpoint, essentially.

Jeremy: Awesome. All right, well, let's get into the CMS part of this because I think when you originally built this, this seemed like that was the original intent. I know it's grown beyond that, which is awesome. But let's talk about the CMS. So there are a couple of different components let's start with the admin.

Sven: Yeah. So we started with the CMS because that's the area we knew the best and the admin is kind of the core of it. So when you install Webiny, you get this what we call an admin app. It's a whole user interface where, where you can expand it. It has a menu. It comes with bunch of ready-made components. And everything that you see on the screen in the admin side is expandable. You can change the logo, you can brand it, white label it, do anything you want, but essentially a starting point, if you want to build a new app, you would just add a new plugin to register your new app with the menu in the admin side. And then admin, when you click it, admin will do the routing and everything, but it's essentially the core through which you build in all other apps and then hook them in.

Jeremy: Right. And then you have the standard serverless use case of taking images and converting them and that sort of stuff. And that's all through the file manager?

Sven: Yes. So file manager comes, as a built in module together with the admin app. And handling files, we thought it's always, you just place an S3 bucket and then it works. So it doesn't ... So if you look at the architecture of just the file service, it's even more complex than the API and the front end together. So essentially we had to build a whole solution on the backend and the front end side. And that solution is called the File Manager. But essentially when you upload files into Webiny, we do this post data token exchange with S3 so that you don't upload files through a Lambda function, but they'll upload them directly to an S3 bucket and that bucket is private. Only that token allows you but also when you request the token, it goes through our security module, ensuring that you have the right to request a token.

So you can upload the files. When you upload a file, we detect if it's an image, if it is, then we have separate Lambda functions that create thumbnails out of it, or any other dimensions you want. There's also some DDoS protection behind that in place. And also when you delete a file, there's a trigger that invokes other Lambdas to clean up all the stuff there. So, yes, there's a lot of stuff behind it, as you can hear. But the beauty is that we built a solution and if you upload one image works great. If you upload 10,000 images, it still works great or even a hundred thousand. So it scales and that's the beauty that serverless brings. So ...

Jeremy: Yeah. And that's all stuff by the way, you do not want to build yourself. I've built little file upload managers and things not for commercial use or not for to share with other people, but just for my own internal projects and things I was working on. And that process of connecting Lambda functions and doing all of that post-processing. It's straightforward, but it is not easy. So it is definitely something that you can get wrong. So that's great that that's built. All right. So then another thing you have is a page builder. What can you do with that?

Sven: So a page builder actually, it's a simple drag and drop page builder for building landing pages. But the cool thing is that the stuff that you drag and drop are not static HTML widgets, but actually full blown React components. And it's all pluginable. So technically you can build a React component that holds your business logic and you can drag it and drop it, and it's going to get rendered. And that business logic is going to work. But also when you publish pages with the page builder they go through a service side render, a snapshot gets created, that snapshot gets automatically pre-populated on to the CDN. And when a user visits that page, it doesn't hit a Lambda function, but actually get served all for CDN. But in the background, what we then do is we rehydrate the application, meaning we asynchronously load all the JavaScript and then do the dirty checks if the page has been changed or not via an API call that goes through a Lambda function, but that's all in the background.

It doesn't slow the first paint time. It doesn't slow the user experience and so on. So the page builder might seem like, "Hey, you can build landing pages with it." It is a really powerful tool. You can build dev dashboards, business logic with it and so on. So yeah, essentially it's a piece of really powerful technology there. So ...

Jeremy: Right. And that does server-side rendering, right?

Sven: Yes. So every time you publish a page, we do the server-side rendering for you. That's a separate Lambda function, separate user flow, it happens all in the background. It's not server-side rendered on demand, but when you publish a page, you use the server-side render to create that snapshot because if you will do it on demand, then you might have bigger cold starts because the Lambda function that does server-side rendering has a lot of stuff in it. So you never want to do it in the main thread, in the main user flow, you want to kind of have snapshots stored on S3 or in the database in case of Webiny and just pull it really fast there and populate it onto the CDN. So ...

Jeremy: Yeah, love that. That's awesome. All right. So then the other thing is this form builder, and I love this because, I mean, even when ... What was the name of that form company? There was a couple of those places that just gave you simple drag and drop forms, things like that. But it was always kind of a pain because again, you're plugging it in and you're trying to do form validation and some of these other things. But you've got a very cool form builder and I know every time I have to build a form, now I just go find something else to do because I don't want to build a form, but this makes it super easy.

Sven: Yeah. So like you said, earlier, building forms is something nobody wants to do. So we wanted to make sure this is kind of the ultimate solution and we never have to build another form again but essentially yes, with a form builder, you drag and drop fields. You can select the field types and stuff like that. But then we also got really powerful validation features, set patterns, pre-made patterns, custom patterns and stuff like that. But also at the same time, how you building, dragging and dropping fields, you also can control rows and columns. So you have also how the layout is going to look like it's all fully mobile responsive that what you get at the end. And then you also provide you with a set of triggers, web hooks. There's a plugin for recapture, there's a plugin for accepting terms of service and stuff like that.

So we really wanted to kind of build a solution that works well. And then finally, there's also GraphQL API through which you can pull the data off Webiny from all submissions. So you don't need to kind of export them manually. Also, you can export the manually, but you can have a programmatic access to who submitted the form and then do additional processing if need be.

Jeremy: Yeah. That saves you so much time. It's crazy. All right. So then the other thing you just launched was a headless CMS, which is pretty cool.

Sven: Yes. So that's the last product that we just launched. As you can see, we have a lot of products and they're all open source, which is a cool thing and that they can be combined together. You can take the headless CMS and build a Gatsby site, right? But then you can also take the form builder and render the form inside Gatsby. Right? They can be combined together. But the headless CMS is one that first of all, it allows you to model your content like any other headless CMS, but it's also has multi language support, support for multiple environments. It supports aliases. So if you switch from production or version one to version two, you don't need to change anything with the client. The switch has done on the backend in Webiny and if you need to roll back, it's instantaneous and things like that.

And it's all done again on top of serverless infrastructure. So it scales really, really well. And if you're not building anything and you're not sending any requests through the headless CMS, well, your cost is zero. There's nothing that you need to pay for but it's got all the features that you can expect from your typical headless CMS.

Jeremy: Right. So another thing that is super important to everybody or should be super important to everyone is security. And that's another thing that this platform just has completely baked in.

Sven: Yes. So security comes in many flavors in Webiny, but also what we found is, especially when it comes to enterprise clients, they want to bring part of the security that they already have. For example, a lot of enterprises, they are locked in, in their user identity providers like Okta, Active Directory, things like that. So when they take on a new solution, right? That solution has to work with their existing security user pool providers and so on. So when we designed our security layer, we had that in mind. So out of the box when you install Webiny, Webiny creates a user pool using AWS Cognito, that's the default behavior. If you have an existing Cognito pool, you can use that as well, but you can also bring in something like Okta or Active Directory, as I mentioned. It's just a matter of fact of writing one or two small plugins and say, "Hey, my users are actually located there."

And then Webiny will automatically talk to that process, to that API, see if the user with the same email exists. If it does, it's going to do the token exchange, do the JWT token as well, and then pool all the roles and permissions from within Webiny. But if that user leaves your company, you deactivate the user in that user pool and Webiny will automatically deny him access. So that's kind of your starting point from the security. And then from that point, it's our standard ACL with all the scopes access to the API and everything that is kind of ...

Jeremy: Right. And you can use those identity pools and you can mix and match for doing things like backend access to the admin. If people want to do page management, or if you build other types of interfaces there, but then you can also use it on the front end. If you wanted to do an intranet or maybe a permission-based or, SAS that people can log into or something like that as well, right?

Sven: Exactly that. So we just had a big enterprise that adopted Webiny for their enterprise intranet solution. And of course they want to protect the public site from the actual internet, only that employees can access it from within. And they are looking to do that with Okta, actually putting Okta in front of the ... They're using the page builder. So in front of the page builder pages, and they can do that. So if a user accesses ... It doesn't have a single sign-on token, it will deny him access there. So everything you see in Webiny is either a plugin or a module, and you can, as you said, mix and match and combine things to work in any way you want.

Jeremy: Right. So speaking of plugins, I mean, that's an important piece of projects like this or products like this, is the ability for it to be extensible, right? And so, I mean, you can plug in all these different security providers and you have some of these internal, or these other things like the form builder and some of these other plugins. But what about more of a general plugin system? I mean, something like a WordPress plugin system, is that something that is happening with Webiny?

Sven: Yes. So it's a good question. It's definitely happening. It's in plan to have a plugin repository that other people can contribute fully open and free and we want to build essentially a community around the whole product and having a plugin repository is really important for us. We just haven't gotten to that stage that we have resources to invest in that area, but it's coming soon. And at the moment, if you want to expand Webiny with plugins, we already have a documentation for that. So later on, once you build those plugins, we've built the plugin repository, you can publish them there. And we also want to give exposure to people. If you've contributed to a plugin, when you click on it, it's going to go to your site, to you so that we also help our contributors get extra visibility there.

Jeremy: Right. And you already have a couple of plugins. I know you have the Google Tag Manager one, I think Facebook integrations, things like that.

Sven: Yes. So we've got couple of plugins already. The Google Tag Manager that you mentioned, so you can embed third party scripts into Webiny. But we also have MailChimp subscribe form. In the page builder, you can just drag and drop your MailChimp subscribe form. We're going to ask you for your MailChimp API key, then you're going to select the form and it's going to be rendered there. We also have the recapture plugin for the form builder and things like that. And if you look at the source codes, which is all public on our GitHub for those plugins, it's the identical way, how you would build any plugin that you need for your site.

Jeremy: Awesome. All right. So moving beyond the CNS piece of this, because again, I think whenever I see Webiny I just see Webiny CMS. I guess what I think of it's a serverless CMS, which is awesome, but you have the serverless web development framework. Explain what that is.

Sven: So you can call it a bad copy on our side in marketing Webiny as too much of a serverless CMS, but essentially yeah, I know. We were worried just to explain the backstory here. We were worried if having a serverless development framework would be too abstract for people. Having a saying a serverless CMS is something that it's much easier to wrap your head around and already picture what you can do with it, but actually where Webiny as a product is, it is that framework for building applications and actually all page builder, headless CMS they're all just example apps, what you can do with our serverless web development framework. And that is the service web development framework is actually our core product. So that is essentially the bit that you take as a foundation for building any type of a serverless web application.

Sven: And that foundation solves many of the serverless challenges and pitfalls like managing files, security, handling database connections. So that is what is in that framework. But also that framework gives you a really good structure for your project, regardless if you have a small project or really big project, it works both ways. And that framework also handles the deployments, the creation of serverless resources, the state files, it has a CLI to bootstrap projects. So that is essentially the core of Webiny. You install the framework, you can pretty much start your project right away, focusing on the business logic. You don't need to kind of do many configuration and bootstrap and stuff around it.

Jeremy: Right. And that's all the stuff that you likely do not want to do anyways. It's just going to slow you down-

Sven: Exactly.

Jeremy: Every time I start a new project, I just am like, "All right, I know I have some, sort of bootstrap templates here and I can and do some of this, but yeah, that's amazing. So that is again, similar to the CMS portion of this, it uses React UI components. You can build your own. You've got that login component, right? It's just drag and drop and now you've got that login that ties into all those other things. Yeah, I mean, that is just that, it's just a very cool tool.

Sven: Thank you. It took us a lot of time to actually build it, but also when people approach this, they think, "Oh, I can do this by myself." Sure, you can, but do not underestimate the challenges and pitfalls that come with serverless. It is so, so, so hard to get some of those components right. It took us over a year and a half to get some of those things right, right? They might seem trivial, but they are not. But also-

Jeremy: They're not.

Sven: ... what people think is, especially developers within organizations, they build a serverless solution on their own, right? But suddenly now the organization wants to do many more serverless projects. So how do you scale the knowledge? Right? How do you kind of do many different teams with many different projects that all run on serverless? Unless you have a solution that has documentation, that is proven that it can scale, it's not going to work. So yeah. I mean, that's kind of the pain we want to solve.

Jeremy: Yeah. And I totally agree. I mean, that's one of those things that if you can certainly build this out yourself and you can go through that process and spend all that time and learn all that stuff but if you don't document that learning and understand why X works better than Y or whatever it is, if you don't do that, then you're right. Passing that knowledge on to somebody else is really, really, really hard. So having that all encapsulated in one project where again, you can divert from that too. If you have to kind of eject and go a different way or whatever, there's still a lot of capabilities in there. But yeah, no, I think that's hugely important. And the other thing I'll just say is proof of concepts or a proof of concept in serverless is typically very easy to create.

And in most cases, depending on the complexity, that'll just scale, right? Which is one of the nice things about serverless but it might not be the most efficient way to do it. It might not be the smartest way to do it. The most secure way to do it or whatever. So again, having those best practices baked in and sort of done for you is amazing.

Sven: You touched on a really good point. I think that easiness of serverless is one of it's greatest virtues, but also one of its greatest pitfalls, right? So you don't get a problem right away. You don't see it now, but the moment there's more pieces to it, suddenly now I have to refactor a microservices application that's humongous. It's you don't want-

Jeremy: Yeah, exactly.

Sven: ... to get tangled in that, yeah.

Jeremy: Right. All right. So I want to move on to multicloud because that is something that the website for Webiny talks about and the ability to deploy to multiple clouds. So what is the multiple or multicloud support like in Webiny right now?

Sven: Yeah. So today, Webiny, you can only deploy to AWS and that's intentional. But when we started building Webiny, we had this requirement of multicloud from the beginning. But we didn't want to kind of make it available to all cloud providers at the same time. But what we did, we built these abstraction layers towards cloud providers but behind those abstraction layers for each cloud provider, you would need to kind of build a driver for it. Let's say it like that, but we only build the drivers for AWS now, but if we want to move to GCP or Azure or somebody else, we can just add additional drivers. The actual core code doesn't need to change. So the multicloud support is built in, but without the deployment drivers for other clouds at the moment, purely because having those deployment drivers takes a lot of effort and we figured, "Okay, let's go with AWS. It holds 75% of the market today." So that's where the biggest user base is. Let's get it running there. And then if we see a lot of requests or ask for, I don't know, Azure, for example, then we're going to focus on it. But until we see that need, we will kind of just let the community to decide on it. And we will waste our effort to where the community tells us they need us now."

So it's just kind of that's the train of thought, but also why we were approaching multicloud is it's likely, from a different angle, it's not about resiliency or technology or things like that. I've worked in an enterprise and I've learned that at the end of the day, who you're going to choose is all about money, right? But often how, for example, you start using AWS today and your bill is a hundred dollars, but if your business grows, you might pay a hundred thousand dollars to AWS and suddenly you want to move away, but you can't. You super sticky because you didn't have those abstraction layers, right. But the other thing you can do is try to negotiate your pricing with AWS, which unless you can't move away, they won't budge, right? But if you have that possibility to move away, suddenly your business has a leverage to negotiate and some businesses pay millions if not billions, to AWS. And having that opportunity to do multi-cloud is really, really important.

Jeremy: Yeah. No, I love to believe that the negotiation and the leverage of having a huge AWS bill would be helpful, but there was just that recent article that was sort of about, you get companies like Dropbox moving off of AWS because the bill's too high or whatever. And maybe AWS loses a hundred million dollars from a giant customer for a $4 billion run rate or whatever it is. It's a small fraction of that. I do agree with you though, that I think that having the flexibility if you're not compromising the underlying services is hugely important, because you don't want that lowest common denominator ... So if you did want though to do let's say I am on Azure and I say, "You know what? I really want to use this Webiny CMS, can I ... I mean, there's hooks in there, right? Aren't there hooks? I could build that in. I mean, it'd be a lot of work, but I could build that in and be able to connect to those other things because of the way that this is architected.

Sven: Exactly that. So you can literally hook in into any part of Webiny, but also if you look at just how the AWS components for deployment are done, it's pretty much just using the native SDK. So if you want to not use AWS Lambda, but to deploy it to the Azure functions, you would just write a small adapter that creates those resources the same way. But also Webiny doesn't kind of lock you in, even if you do use AWS, if you have certain services from Azure, you can combine stuff, right? You have access to the code, you have access to the deployment hooks. You can pretty much customize it to fit any needs. So ...

Jeremy: Yeah. So another question about multicloud because I think if you're paying a hundred dollars a month to AWS that if you're thinking to yourself, "Whoa, this could get expensive. I mean, I really should be thinking about trying to be cloud agnostic or some way in which I can move things around." Your thoughts: should small businesses, startups, things like that, should they really be thinking about multicloud at this point?

Sven: Not at all. So that is a concern for what I would say for enterprises and larger organizations. If you're small, I mean start with being sticky, that's fine because your priorities are about building your business, not controlling the cloud cost, I would say. But be wary that controlling the cloud costs will come at one point. But don't let it constrain you in the beginning, especially potentially just constrain your iteration cycles, making them slower because you're suddenly working on multicloud while you don't need it, right? So at this scale, at the small scale, don't waste your time there. But have it in mind if you plan to go big at one point. So, but only invest those resources once you have those resources and that is a priority.

Jeremy: Right. And I would say if you're building a serverless application and it gets to the point where that gets to be really, really expensive, you're probably doing something right there. So hiring a few extra engineers, if you need to start diversifying clouds probably wouldn't be that difficult at that point. All right, so I want to talk to you though about this idea of just why serverless, right? So let's say I'm a regular everyday person and I'm trying to figure out how to build something for a client, or I'm trying to build something for myself, why not just WordPress on WP engine or something like that? What's the underlying benefit to building my site or my service on serverless, even if I'm not expecting a ton of traffic, maybe.

Sven: I mean, how I see it. First of all, building on serverless might seem slightly complex at one point, comparing to VP engine because it's two mouse clicks right? But the thing is with serverless, first of all, your cost is way more efficient. If your service is not having any traffic, why should you pay for it? With serverless, you will essentially stop paying for stuff you don't use. It's an important thing for especially small businesses, being efficient at how they spend their money, but also imagine your site suddenly gets on the front page of Hacker News. By the way, we were, with Webiny on front page of Hacker News.

And that sends a ton of traffic. And it's a really big spike. And that is when you need your servers or whatever you're running on the most. You do not want to go down when you have 50,000 eyeballs on you. That's when you want to deliver. And that's where VP engine and others will fail short on you. They won't scale to those demands while serverless doesn't care about it. It just works. Of course be prepared for a bill shock, but hopefully it's going to be worth it for you. So ...

Jeremy: Right. Yeah. I mean, and I think that if you think about something like DigitalOcean, for example, I mean, it's very easy now. They've got these engines in place where, you just go on and say, "Oh, I want to create a WordPress site and you click a couple of buttons and it's magically there, but Webiny is getting pretty close to that, right?

Sven: Yeah. So at this stage, Webiny requires you to kind of put in API credentials for AWS, connect to database, in one command deploys and creates all the resources. But we're also preparing another offering, which is going to be one of our commercial offerings where essentially you're going to get those two buttons and you're going to have a Webiny site deployed to your AWS cloud. So we won't be hosting anything, but we will be providing a user interface to make it really easy for you to deploy Webiny sites, have multiple environments, multiple projects everything would just kind of mouse clicks. Make it super, super easy.

Because no matter how advanced a certain technology is, if it doesn't get to that level, that it's really easy for even non-developers at one point, because a lot of people ask us, "Hey, I really love your page builder, but I'm not a developer. With WordPress is just two mouse clicks." Serverless is not there today but Webiny we're maybe one step behind that. We are going to be there pretty, pretty soon and hopefully that the serverless market would kind of benefit from that and the adoption will also grow.

Jeremy: Right. So the other thing that I'd love for you, sort of get your input on, or your perspective is I often see arguments saying, "Oh, serverless is great for spiky workloads, but if you don't have spiky workloads and you have steady traffic, it's just easier to put it on a VM or something like that. But I always find that serverless has benefits, whether you're a small business or you're a huge enterprise. What are your thoughts on that?

Sven: So what I'm seeing is, so when you're a small business, it's the cost of infrastructure that really matters to you because it's really efficient. You don't pay if you're not using it. But for the big guys, it's a combination of factors. And sure your bill might be slightly higher in some cases running on serverless, the cost of infrastructure. But the cost of managing infrastructure will go way down. You will have to hire less people, or the people you have will have to spend less hours working there.

But also what that does, it releases a big chunk of the budget or resources or man hours that you can now focus on product iterations. So your product can grow faster. And if your product grows faster, you can out innovate potentially your competitors, which can't afford that same level of innovation. So what I see with enterprises is that they see serverless as a competitive advantage, and that's why they moving to serverless. Although, you see all the blog posts about cost savings and stuff like that. Yes, that's true, but there's that agenda of outpacing my competitor, which serverless actually unlocks. And the moment you migrate to serverless, you can use that potential.

Jeremy: All right. And then what about the big business? So what are the benefits for those larger enterprises?

Sven: Essentially that. It's just having to spend less on managing that infrastructure. Sure, the infrastructure costs might be higher, but the cost of managing will be drastically lower because there's way less things to manage than if you had a fleet of hundreds of thousands of servers or containers, that all requires man hours, and you as an organization, you should strive towards autonomy, putting the resources where they really matter and managing servers well matters if you have to have them up and running, but if they suddenly go away you can focus on other bits.

Jeremy: Right, yeah. And I mean, I think it's crazy to have all of these people who specialize in running data centers and building software for the data centers and managing that for you and then say, "You know what? We're going to not let you do that and we're going to have other people work on managing that and installing patches and trying to figure that stuff out." I mean just the amount of effort and time and energy that goes into that, just backing up databases, just having a DBA that does your database backups and optimizes the database and migrates data. It's just all taken care of for you, if you choose the right tools.

Sven: Exactly that. And especially, I believe the younger businesses that are starting today and building their technology have a tremendous advantage because they have such amount of brilliant tools in front of them that they just need to kind of piece together and starting maybe five, 10 years back, it's just networking load balancers. For me, mentioning that, I just get depressed-

Jeremy: Gives you flashbacks. Yeah, I totally agree.

Sven: But not positive ones so ...

Jeremy: Right, yeah. You can only wrestle with security groups to an RDS and since so many times before you were just like, "You know what? I don't want to do this anymore." All right. So let's talk about this idea of who you're targeting because this is something for me that was I think the first question I asked you when you ... I think you and I started chatting maybe a year ago or two years ago, whatever it was, and I was like, "Well, who are you targeting with this?" Because if you ask the average developer, they don't even know what serverless is. I mean, even the average cloud developer, they're like, "What's serverless? And again, it's probably not the best term. We know that. You ask somebody off the street, maybe some small business owner or somebody who's like, "Oh, I'm going to start a little side business."

And they want to create a website. I mean, the first thing they're going to do is they're going to go for WordPress. So who are you trying to target with this? And is this, I guess maybe the question is, is this trying to be a competitor to WordPress or is this taking a different angle?

Sven: So there's two answers to this question. One is that is about the short term mission and vision. And one is about the longterm. Short term, yes, if I ask many of the developers out there, what serverless is, they won't know about it. And those users are not our target users. We are letting the big cloud providers educate the market about serverless and let them spend millions and millions, if not, billions, on educating the market. But once the market is educated, that's when those users will start looking for ready-made serverless solutions. And that's where they're going to find Webiny.

At this stage, we're targeting developers that understand what serverless is because educating them just takes too much resources for us, but the moment an engineer or developer and knows what serverless is, and you show him Webiny, he just gets super excited because he knows serverless comes with certain challenges that with Webiny they just go out of the window. And suddenly I unlocked the potential, just writing business logic and all gets deployed into microservices. And I don't care about how it all works under the hood, but I still utilize all the power of serverless.

So those developers are people that we're talking to today. But in the future, how I see the future in five or 10 years as I started, as I said earlier in the session is I see serverless as being the standard of how all web applications are built. But don't get me wrong. The traditional servers won't go away, but they will be used for specialized purposes, machine learning and things like that but for anything that's event driven that runs on the web, serverless shines there. So I see a clear future where serverless is that future, where it's the standard of how we build the web.

But that standard it's not enough to solve it on the infrastructure orchestration layer. You have to solve it also on the application layer because people are after, when they say, I want to build a serverless solution, they're after. They're thinking in their heads, the application layer. And that's where we with Webiny come in. We're providing the tools on the application layer to help them build their business logic. And de facto, a CMS is one of those tools out of the box, but they can innovate other tools. But if you think about WordPress for a second, WordPress powers 34% of the internet, maybe even more at this stage.

And there's two reasons for that. One is they made it super easy to install and run and integrate with many other systems. But secondly, WordPress, although like a lot of people perceive it as a blogging platform. If you open their documentation, it's going to be clear. It's not a blogging platform. It is a foundation for building applications, but those applications run only on virtual machines and those traditional architectures. With Webiny, we want to be something like that, that foundation, but for the serverless world, for when the serverless is that standard. So will we replace WordPress? I would like to do that, but I think that's a mission for the next 30, 40, 50 years because Matt did an amazing job with WordPress but the mark is going to change because if you think about it, the Nokia phone, everybody thought that that's never going to go away. And then-

Jeremy: I mean, playing snake on your Nokia phone was amazing.

Sven: Yeah, but-

Jeremy: I mean, the graphics were intense.

Sven: It looked so real. That is the perception of the virtual servers and containers today. And then serverless is that smartphone. It's going to have a slightly longer adoption curve, but that's how I see the market. That's how I see this evolution coming.

Jeremy: Yeah. And I think we'll see even sites Wix and GoDaddy, I think they use, maybe they use WordPress, but WordPress and other platforms like that starting to migrate to more serverless technologies on the backend anyway. So I think that's great because if the Webiny can help influence that and set those standards and help sort of drive that ecosystem, I think that is absolutely amazing. So all right, I have two questions for you from our Serverless Chats Insider. So this is a new thing we're doing. So I'm going to throw these at you. They're pretty easy. They're softball questions for you, but if anybody wants to ask questions, join the Serverless Insiders email list and you can ask questions.

So the first question is from Michael and they said, on your website you say that MongoDB is serverless, as long as you don't have to manage it yourself. And they said they haven't fully defined the term yet. I don't think anybody has or try to. And they're curious whether or not, where you would draw the line, would you consider a COBOL mainframe to be serverless if somebody else is managing it for you?

Sven: So how I perceive serverless is if there's a service I'm consuming and I don't need to worry about servers, patches, networking. If I'm locked out of the thing that the service runs on, but I can only interface with the service via an API, that serverless for me. And what we say on our website is it's specifically targeted for MongoDB Atlas. So that is the cloud offering that MongoDB has. And there it's a mouse click. I need a Mongo database that is, I need the Mongo cluster deployed to this region and they manage everything. They update my MongoDB, they scale it, because it has an auto-scale function. I don't need to do any load balancers, any networking stuff there. Backups are just a one checkbox. So its essence, if you look at MongoDB Atlas, and if you look at Aurora serverless, it's not very different. And this one has even serverless in the name. So as long as you don't worry about the servers and all the bits that connect to that, that's how I perceive a serverless.

Jeremy: Right. And I've been trying to define serverless for many, many years, and I have not come to it either. So don't worry about it, Michael. None of us know what it is. All right. So another question, this one's from Mark and you kind of addressed this in the beginning, but when do you think Webiny will fully support DynamoDB as a data store?

Sven: So we get that question asked a lot. So we would like to have DynamoDB, and it is one of the items really high up on our priority list. We're looking at it, we're working on it. That the challenge with DynamoDB is that although they say they're no SQL database, they are so different than a no SQL database. It is a third category. You have SQL, no SQL, and then you have DynamoDB. Purely because they're so different, we have to work around some of its quirks and challenges and we're working on it. We hoping to get DynamoDB support sometime this year because a lot of users have asked for it and we personally also would like to use it. So stay tuned.

Jeremy: Awesome. All right. And then he had one followup question as well. And that was about the business model for Webiny. And you had mentioned, some sort of business where you'd be able to deploy it for people. But the question sort of says, because serverless is so cheap to host yourself, or do you think that there's any way that there could be a managed hosting service that you provided that would be profitable?

Sven: So it would be really hard to do a profitable managed hosting service there because if you look at for example, Netlify, they're a managed AWS hosting service. Sorry, but they are. And I don't see us going in that direction. So what we are providing is, where we're going to probably call the ... It's not yet a full name yet, but we call it for now Webiny Control Panel. Essentially, you would hook in your AWS API user. And that interface would be one-click deployment of Webiny, but to your own AWS cloud. So you can kind of create 20 different Webiny projects and there's going to be reporting, monitoring, audit logs, and bunch of features in there that compliment to the features you have in AWS, but simplify it and scope it to your Webiny project.

Because the problem with AWS is, "Hey, this region has costed you 500 bucks." Yeah. But what is the cost per project? Good luck finding that out. So that's what we're going to be providing with this commercial offering and it's going to also have a free tier and there's going to be a really cheap tier and bit more expensive tiers for more enterprise business users. And I understand the background of this question. A lot of people approach us, "Hey, you're just open source, giving everything for free. You're going to go bankrupt in three months." We have a plan people. So ...

Jeremy: Well that's good to know. Well, that's awesome. So Sven thank you so much for building Webiny and for everybody that's contributing to that project. I think this is the right direction that we're going, trying to abstract that away. Get to a point where it's just more approachable and like you said, thinking at that application level. So again, thank you for that. If people want to find out more about Webiny or contact you find out more about you, how do they do that?

Sven: So you can find everything about Webiny on our website, webiny.com and on our GitHub, which is also github.com/webiny. And you can contact us on Twitter, on the Webiny platform. If you want to reach out to me personally, sven@webiny.com is my email and you can find me under @svenalhamad at Twitter. And again, I also want to kind of thank you Jeremy for having me as a guest here, it was a pleasure. And I also want to give a shout out to the whole Webiny community. That is kind of what keeps us going and why we're putting all this effort because we really love our community and our community helps us grow at the same time.

Jeremy: Awesome. All right. Well, we will get all of that contact information into the show notes. Thanks again Sven.

Sven: Thank you, Jeremy. Thanks everyone.

Episode source