 Welcome to another session of Domains 21. I'm Jim from Reclaim Hosting, and it's a distinct pleasure to hand over, or how would I say, turn over the floor to Ruslan of Gelastic and Tim Owens, who I know quite well of Reclaim Hosting, to talk a little bit about our partnership together over the last several months. Awesome to get together with you, Ruslan. It's good to have a conversation. I don't know that we've ever had a private one-on-one chat, but it's great to talk with you. Hello, Tim. It's definitely a pleasure for me to be invited and talk about our cooperation and maybe about future plans, like, and share our plans with audience. You all recently celebrated a birthday, if I'm correct, and you're almost as... I think you're about the same age as Reclaim Hosting. Tell me a little bit about the history of the company, I guess, is a good way to get started. Yes, so I have a long history and shot one. I will try to do, like, in the middle of something. So the history started as usual, you know, like, I was a developer, like, you know, a normal developer. I was doing server-side and backend-side, by the way. And at some point, I realized, actually, 10 years ago, there are not so many tools that can help me to fight this, like, infrastructure and speed up my work on the infrastructure side. So we decided to build our own platform, as usually developers do, you know, like, they try to come up with new tools, like, you know. And we started to build a solution, which actually today people call backend-as-a-service. Backend-as-a-service. So we built, like, APIs, and at the end, when we got, like, first workable solution, it helped me a lot. Like, so I became much more productive. I started to build faster, like, websites, like, and, like, applications for my customers. I was working, like, a freelancer, let's say. And literally, it's speeded up significantly in my work, and I realized, okay, there is a power behind it. Then we tried to show this to people, and we got about 5,000 signups, which was a good number, let's say, trials, like, and people said, okay, it's nice. But it was the beginning of the story, let's say. So we're back into the service. Later, after we got attention from investors, and actually they found us at some conference, we had, like, a bright world, like, in our presentation, cloud platform, like, you know, like, cloud, cloud, and they started to ask more. Exactly, they started to ask more questions. But honestly, they did not really understand, like, what we built, like, we had, like, long meetings with technical engineers. It was hard to explain what we built, because at that time, people did not have this term, like, back-end-as-a-service, you know. And, but finally, they decided, okay, like, there are three guys, they built something cool, like, let's invest them, we believe in them. And they put money, and they put support from their portfolio teams, let's say, like, technologies. But during our, let's say, conversation with investors, and they opened doors to question-service providers, I visited many service providers and started to ask, like, okay, what is the problem? Like, how we can help? And you know what happened, like, we realized that what we built is not going to fly. Because, and the developers had to write for our APIs. And, like, at that time, like, you know, it was no way, like, for companies to build for proprietary API, or even if we go open source, like, nobody knows you, it was dangerous. Like, so we decided, honestly, to scale down to platform-as-a-service. So, and we started to work on containers because it was another problem as well. It was another way to solve similar problem. Like, so we decided, because I was working in another startup, and, like, we had the system admin guy. He was a great guy, but he was not so experienced, even, like, the system admin guy, how to build, let's say, availability, how to build scalability, and how to move from development to production. Like, you know, like, we pushed the changes directly to production, which is bad habit. Like, you know, you sort of not do it. I'm guilty, I'm guilty, I do. It's fine. You know, you know, uploading problems through FTP, you know, like, oh, well, what people do, usually in the old days. So, we decided, okay, like, let's build platform-as-a-service, and how we can build it. Okay, like, there is a Heroku, which is very popular, right, like, and we like the idea, but Heroku was only hosted on Amazon, and there are many other, like, service providers that just cannot join the Heroku, like, you know, with infrastructure. We said, okay, let's build Heroku for service providers. Like, and this is how Jelastic started then. And we discovered containers, because our investors had very good relations with companies that was one of the guys who created containers, let's say, like, system containers. Today, the company is called, like, Veer Shorzo. And after I realized, okay, containers, they're super cool, like, look, like we were working with containers from 2011. Like, from 2011, before containers became cool, we were already using them, because we realized, okay, they're flexible, they're scalable, we can introduce new pricing model, which is based on paper use, like, so it's opened a lot of opportunity for us. So this is how Jelastic started, like, we build the prototypes, and we cooperated with our partners in the United States, and then we found a partner in Germany, and our service were overloaded, honestly, like, so we got a lot of attention, like, okay, some things that people like, like, let's go commercial. And I think there's, you know, like, for some people, especially, you know, obviously, our user base is academics, and so, like, it's not necessarily developers, and so they hear these terms platform as a service, they probably don't necessarily understand, like, you know, like, are you all competing with Amazon Web Services or not? And like, where do you all fit in that overall landscape? Because obviously, as you know, the hosting industry has so many different players, and I think they all have a different role in a different space. You're not competing with AWS or Google Cloud Engine, maybe, although particular pieces may be so. And so I'm wondering what, in the overall landscape, where does Jelastic fit in? What does platform as a service basically mean for someone who might not be as experienced or understand that lingo? Very good question. So in short, there are similarities and differences compared to Amazon, let's say. We do provide cloud platform as Amazon, right? However, we have big differences. So you don't need to hire, like, the Wops team to set up complex environments and scalable environments. So Jelastic was built specifically for developers and the Wops teams that want to get rid of complexity for infrastructure management. And with Amazon, you still have to, you know, like, to hire and configure even specifically if you go with infrastructure as a service level. So we moved to the next level where we provision ready-to-go environments for you. We configure, like, complex topologies and then we can integrate and provide, like, continuous integration, continuous delivery tools. We have, like, built-in tools or, like, you can use, like, standard tools. And this is where we fit. But the best part, actually, what I like the most is that we do not provide our own infrastructure. We cooperate with partners around the world. So because there are so many great hosting service providers in the world, they own data centers or they rent data centers and they like what they do, but for them to go and compete, like, or at least, like, you know, to offer a similar service like Amazon, it's a lot of work, it's a lot of money, like, so it's a lot of NND efforts. And for us, as the developers, like, we like to focus on software, not on the infrastructure management. We do infrastructure management as well. But still, we prefer to cooperate with partners. And so today, we cooperate with many partners around the world in more than 40 countries already. And we help to transform more than 100 data centers. So in a short, I call it, decentralized network of independent cloud service providers. So it's very good for customers because they can come from different countries and see, like, okay, there's a Jolastic in Brazil, there's a Jolastic in the United States, or there are, like, several Jolastic partners in Switzerland, for example. So if one of them is not working well, like, there is an opportunity to migrate to another one, and there is a full interoperability. You don't need to redesign. There is no login to one specific provider. This is what I like a lot, like. And of course, please keep in mind there are two additional differences. Simplicity, it's much simpler and easier to work with Jolastic than with Amazon or with other, like, you know. And another one, pay per use. So maybe we will touch this later, but we invented very nice model where, like, you don't need to guess in advance how much resources you need to provision for specific instance, like. And if you have, like, hundred of instances, we just solve the right-sizing problem, like. So you don't need to guess any more in advance, like, you know, just set maximum scaling limits and pay for what you use. So it's very, very advanced solution. And when customers realize the power of the solution, they love Jolastic a little. Yeah, well, that was definitely our experience, you know, when I first came across Jolastic, it was actually as a application that could be installed on the DigitalOcean platform, you know, as a way to run platform as a service. And I thought, well, that's interesting. And then as I delved in more, that flexibility that you talk about that we could run it on dedicated hardware, whether that's hosted directly here in a data center or whether that's hosted by OVH or by any other platform provider that provides the actual infrastructure. So there was a lot of flexibility there. And we've been playing with containers for a long time as well. Just here and there, there was obviously people interested in doing it because it gave way more flexibility in terms of what you could run without having to think through, well, if I want to run this particular application, I've got to install PostgreSQL. I've got to install these things. I've got to make sure they're compatible. I've got to make sure the right ports are open and all this other stuff, whereas all these Docker files were showing up and it promised the ability to just spin up a container and it would all be set up for you. Developers loved it, but end users loved them too. But for our community, it wasn't necessarily going to be straightforward. They didn't know much about the command line. They didn't know much about how they would spin up a Docker container. And for us as the hosting provider, we wanted to provide a solution where if they wanted to do that, they could, but they didn't have to. How could they run something like the ghost blogging platform like Mattermost for Chat or something like that to provide sort of an open source alternative to Slack and other services? How could they do those things but doing it in a really straightforward way? And it was almost, it was interesting because I would always check the landscape and see what was out there. And I came across Jelastic right as we all went into lockdown at the start of the pandemic. And I'm at the house, we're just doing work for my house and everything. And then I came across and started playing with it. And it was just like, it immediately clicked for me. I felt like this is something that's easy to use. This is something that for someone like myself who's not a developer, I could still run really advanced stuff and feel like there was a lot of flexibility there. The ability to scale was huge. There were so many benefits for us. And so we hit the ground running and decided this could be a cloud platform for reclaim hosting to be able to provide so many benefits to our audience. Yeah, definitely. That's, thank you very much for all these great words. So it's very good to hear from you. Like I'm happy when people say something like this. Like definitely, thank you very much. But adding a little bit more, adding a little bit more you mentioned like digital ocean. So our model also like we try to be agnostic, like so not to look to infrastructure, not to look to cloud. Because even like Amazon, like look, we have service providers that use Amazon as well. So they get infrastructure from Amazon and they just install Jolastic on top of it and they can expand their infrastructure without messing into a lot into infrastructure. But at the end, they still offer us this simplicity, this elasticity, this availability, pay-per-use and interoperability. So and we have large customers that install Jolastic on top of Barometal, install on top of Amazon, Azure, and they can deploy like on any location with in the same way. It saves a lot of effort to them, you know. So that's what we do. I'm curious to hear from you, like because you have a sense of the general landscape of your other Jolastic customers, the other providers that are using you all, and even down to like end users. And so I'm curious to hear about specific use cases and things from you where you've found really like unique use cases. Obviously for us, we've got kind of a unique one because we deal primarily in the education field. And I'm wondering if there are other hosting providers who have found a particular niche where running Jolastic, running a platform as a service made a lot of sense for reasons other than just basic development, right? Yeah, so I hear very often this question, okay, where is your niche? Like, so where you're focusing? But the reality is the following, like our niche is there where people develop software. Like, you know, if they need to maintain infrastructure to deal with infrastructure, so Jolastic can help. Now, if we're coming to specific directions, like so, it really depends on a service provider because service provider, many of them are focusing on the different directions. It depends on them because they have own expertise and they bring own expertise. Because it's not only about software, which is great, but still it's about services and about your expertise, how you can help your customers. And our service providers are focusing on e-commerce, like some of them just doing like Magento, like e-commerce stores, like and so on. Others like on WordPress, and other guys like on DevOps direction. So even running Kubernetes on top of Jolastic or without Kubernetes, you can do same stuff, like maybe even weather like, you know, so. And it really depends on the expertise of service provider, I would say, yeah. Yeah, I also, I think, you know, like, scaling is a huge thing right now. I mean, another thing with the pandemic, right, is that like everybody got pushed online. And so all of a sudden, you know, for people who are providing services online and for people, you know, thinking back again to education, there was a big push for everybody to be online. So what platforms were gonna be able to be stable when you had thousands of people, hundreds of thousands of people hitting websites and things like that. We never had a good solution like that before because we ran, you know, independent servers with C-Panel on them. And so there was only a finite amount of traffic that you would run into. We were on digital ocean, so it was virtualized and that was great. But if you want to expand on digital ocean, you have to shut the entire server down, then you have to change some settings. You have to reboot it up. It's gotta resize it, which can take up to a minute per gigabyte. And so we were finding, while it's great for everything to be virtualized, it's not so great in terms of being able to scale for larger projects and clients that we were working with. Whereas now, you know, getting a little bit of your idea of like having cloudlets and the ability for a system to be distributed across multiple environments and be able to scale up with the needs of whatever they're running, I think it's really exciting. Yeah, scaling is one of my favorite topics, of course. Because this is actually why people are looking for clouds. Because if you run something small, like static website, like maybe VPS, like it's good for you. Like, oh, maybe share it constantly. But when you go to production and with big service and customers are coming, so you become a potter, definitely need something scalable. Otherwise, like, you just buy a lot of hardware, it's not scalable. You pay money to get for big performance. And scaling also, I believe we found, actually I know for sure, we found something very unique that nobody offered before us on the market. And it's called vertical scaling. Of course, people use it, but not in the way we offer. Because vertical scaling was underestimated, potential of vertical scaling. Because in the past it was, we didn't have big machines, like, you know, people run a lot of, actually specifically from Java world, they run multiple applications inside one virtual machine. And they put, like, a lot of big limits for virtual machine, Java virtual machine. And Java virtual machine was not scalable vertically at all. So vertical scaling was not very much useful in the past. But with containers, we realized, okay, containers are elastic and you can resize them on the fly and they can give resources on the fly and return back to operating system. So it's a lot of powerful, you can build a lot of powerful things behind it. And machines became bigger. So range for vertical scaling is huge. And we enable this vertical scaling for customers. So today, if you want to get performance, maybe you don't even need a horizontal scaling. So, like, you just increase limits, like, and you go vertically. And it's fine. Like, of course, it's not good for heavy ability because one instance is not highly available. But if, again, like, if you're talking about performance issues, it's super good, like, so. And then if you combine this together with horizontal scaling, your application becomes very flexible. So flexible vertically and horizontally, you become very efficient as then. And adding, adding at the end, like, third level of scalability, I call it like, third level of scalability, when you can change your topology easily, like, you know, like, okay, you started from, like, one database and one application server. Like, you did not have load balancer before, right? Like, so, but you can easily add load balancer now. So you change in third dimension, you change your topology now, right? Like, and then maybe you can add like cache server or like proxy SQL server, like to balance your SQL queries. Like, so we enable this LSTCT in three dimensions. And to your point, some, you know, there are some of these things that they were already out there, but they weren't easy to use. I think right back to AWS, and I think, you know, people said, well, AWS is really popular. All the big players like Netflix are using them and all that kind of thing. And you would go on there and the idea of creating a scalable application was like, well, I mean, okay, CloudFront, so that's gonna add a CDN, but then I've gotta drop this JSON file in and hope it matches up with an EC2 instance. It's very much made to be addressed by APIs and almost APIs only. Their GUI interfaces is almost useless. And so for someone like me, it was a non-starter. It was like, those tools are there, but it doesn't make a lot of sense. Whereas I found with the Cloud Platform, which Elastic, I was very easily able to say, drop it, load balancer on. And now that's suddenly working because the software would do all the work of knowing, all right, this internal IP needs to talk to this one over this port and everything. It plugged up all of those features and things like that. So it's really exciting. We talked to a lot of educators, you know, who were running programs at their school and they say things, going back to the idea of performance, like, well, we're gonna get a big load on Saturday because we've got this conference going on site and everybody's gonna be hitting the conference website or something. How can we make it work for that? But of course they don't wanna pay for the ability to do that all the other times, right? Like, you know, like Monday through Friday, nobody's gonna be on this website. And so they don't wanna pay for that. They wanna pay for it at the time that they need it or even worse at the time, they would say, well, we don't know when we're gonna get massive amounts of traffic. You know, it could be that somebody posts a link on a website and it goes viral or it could be that all of our students decide to wait until Sunday night to turn in their homework and they're all hitting it at the same time, but it's all variable and they have no idea. So the idea of elastic scalability, I think, is huge for them because they don't have to concern themselves with that. They can know that they're only paying for those limits when they need them and then when they're not, they don't have to pay for them. And it's great for us as hosting providers because then we can make use of our resources in better ways as well. I don't have to sell someone on the idea of buying tons of hardware to be able to fix that one time that their website is gonna get a lot of traffic and I can feel good about that as well when I'm talking with customers. That's what customers love, honestly. This flexibility is in us to use. By the way, if you go to Google and print right sizing problem, most likely you will find my article about this like I explained why it's difficult to guess in advance how much resources you need. And imagine now if you have web agency and you host multiple customers, usually you have several containers per one environment and you need at least two environments, production and staging or development, right? And you have 10 or maybe 20 customers. You have many containers after. How you can know in advance what is the size for a specific container or a specific customer? It's very hard to predict. So we call this problem like right sizing problem. With Jolastic, this problem just does not exist because this is like vertical scaling. It's growing up and down automatically but only vertical scaling will not work. This is why we invented and introduce it, paper use. So this is very unique model. I will call it like cloud native billing model. And you notice now many like other big vendors now because they say like we have paper use, you know, like for example Amazon introduced it for their like Kubernetes based service and Google recently introduced for Kubernetes based service as well. But please keep in mind like sometimes companies want to confuse you, you know, like, and if you compare like they're paper use and now paper use they're different because they say like paper use, but in reality they still charge you for the requested limits for allocated resources, not for the real usage. So be careful guys. So learn a little bit about this because it can save you a lot of money honestly. Yeah, you see it a lot with providers and it was the standard norm practice for the longest time where even if a server was shut down and it was virtualized, you still paid for all of the CPU, all of the memory and you know, the infrastructure providers making bank on that because they're not having to provide that to you and the server shut down but you're having to pay for it at the entire time. So I think that's really exciting. And it just makes sense. It's a fair, it's fair to the customer. It's fair to the hosting provider because then we can make use of those resources with other clients and kind of distribute things more broadly. I'll ask you. May I add something about this? Because it's very important point. Look like I like that we are in the middle between what service providers and then customers because like we are playing like neutrality, like, you know, neutral role. We don't want, you know, like to our customers, you know, to pay more like so, but we don't want our service providers to lose money as well. Like so we are in the middle like so, but we are for fair pricing. Like we fight over selling. So because we don't like over selling, like we should customer should pay for like, you know, fair price for what they use. But at the end for service providers, we simplified the work when they don't spend like a fourth, okay, like how to rebalance my cluster. Like, I don't know, like, you know, like, so we have nice features for rebalancing actually for distributing the lot at the beginning. We know where is the best place for each container at the beginning. So we call it like smart distribution. At the end, like if you want to do rebalance, there is opportunity to migrate containers in live mode without downtime or like offline mode. It's very unique functionality. So not many container platforms actually none other containers platform offers this functionality here. And yeah, at the end it plays good for service providers and point customers. That's awesome. Tell me, and of course I'm not going to ask you to reveal any secrets, but I'm curious, what's on your roadmap? Like what kind of things are you thinking, what comes next for you all? You've got the platform. I know that occasionally you're putting out new applications in there. So what kind of things are on your immediate horizon in the next year or so? Like what kind of things are you all focusing on? So honestly speaking, Jolastic is very powerful already. Like so there are many things like, you know, people working several years and they later realize like, is there a stuff like I can still do? Like, you know, like, and they are excited a lot. So we polish what we have. Like we want to, you know, to shine like every feature, like, you know, to be like super stable, like even more, but better use. Like so user experience is one of our focuses. Of course, we track demand on the market. Like there is demand for Kubernetes, let's say, because people just write for Kubernetes as the beginning and it's the responsibility to run Kubernetes top on Jolastic in almost the same way as you can do on Amazon or like on digital ocean or many other cloud provider. However, we apply extra benefits for customers because there is paper use. You don't need to gain like to overpay for your node. Like because just imagine you create a cluster with five nodes and you put like 32 gigabytes per each. Like, but in reality you use like, you know, like 30% of it. Like so you still pay for this on Amazon and as it's Jolastic, you don't, you don't. Like it's very good. And of course we like multi-cloud, multi-region, all this because like, look, recently the whole data center was burned. Like, you know, fire damage it, whole data center, a lot of customers. I do believe customers like with serious business, they need to have like at least two replicas, better three, like, you know, for availability for disaster recovery because disaster recovery in this case very easy. Like you just automatically switch to another location. And we want to simplify this for our customers to we build ready to go packages. We started with, you know, WordPress for example, very soon it's coming, like a distributed workplace cluster. We have already cluster for heavy ability, but it's running inside one data center. In the near future, it will be available. You just choose like multiple locations and we deploy clusters in different locations and interconnect them and do synchronization replication for you. Like, you know, this load balancing automated then CDN is automated, then DNS is automated. Like, you don't need to go and jump like, oh my God, like how to configure all of this. Like, you know, many locations, like maybe like I will skip it, like we'll go with one data center, because it's too much work, like I need to pay somebody. Like, so we want to remove this and you know, to give people this experience of heavy ability by default. Like, so this is the way we see our insufficient. Yeah, you always hope that, you know, that you never have to deploy your disaster recovery plan. You think like, oh man, we tested and we hope that we don't have to do it and oh, we've got the backups. We'll wear the backups. Oh, they're in the exact same data center just on a different server. And so, and this really proved to be, probably if there ever was a worst case scenario, I think it was that. And so it's exciting to be able to think, okay, well, we have a solution for people. We have a way for people to do that without feeling like they've got to hire a whole team of developers to rebuild their entire product to work in some kind of new environment that can use the tools they're already doing and doing it in a really exciting and easy to use way. So yeah, I think it's a really relevant example. Yeah, thank you. Yeah, we see the month of this honestly. We see the month because like we have something. Yeah, but when the month will actually come more when people realize, okay, it's easy now. Like so why not to spin up one more container even if I don't pay for resources, I don't can. Hey, I wish this conversation could go on, but I think we have to go back up all our data now. That's right. Everybody's going to go check their disaster recovery plans. Absolutely, I want to thank you. I want to thank you, Ruslan, for joining us today and talking about your wonderful product that is Gelast. And thank you very much for everything you do. And Tim, thanks for jumping into a Domain's 21 session. I am a big fan of both of you. Thank you very much, guys. Thank you. Yeah, thank you. Nom, nom, nom.