🎬 You can watch the video of this episode on the Life on Mars podcast website: https://podcast.marsbased.com/
🎬 You can watch the video of this episode on the Life on Mars podcast website: https://podcast.marsbased.com/
Awesome, Then welcome to the show. How are you doing Khash Good? Thank you very much for having me. I don't know if I got your name correctly.
Khash Sajadi:That's that's close as I ever get.
Àlex Rodríguez Bacardit:Awesome. So you're based in London. I assume it's probably business. I don't know. It's business or personal that keeps you traveling from San Francisco to Europe, or yeah.
Khash Sajadi:It is a mix of both. So I have I kind of technically live in both places. I'm split my time 50, 50, 50, 50 percent of my time is in London, 50 percent of the Bay Area, and I have two bases, so I don't know where we're home is, I think, both. So today I happened to be in the UK for another month or so.
Àlex Rodríguez Bacardit:We will be reviewing a little bit of your background before going into the history of Cloud 66. But I like to kind of like weave that into the conversation. So take me back to the early beginnings of Cloud 66, because one of the things that usually when you start a company, it is because you have an idea of a pain that you want to solve that you had in a previous company so I don't know whether that was Lehman Brothers or not when did like deployments and DevOps suck in your previous companies?
Khash Sajadi:Well, they always suck. But, interesting enough, cloud 66 started as a different company under a different name with a different promise, and then it could have changed over time. So I started doing computers as real since I was 14. And I've been a developer for a very long time. I've worked in many different places as a developer and every time I go somewhere and start working, there are certain tasks that, as a developer, you're familiar with, you have to do, and it's not just about setting up workstation and you're finding the favorite ID or whatever the code styling and the flavor of the month is. It is mostly around. I find myself building the same thing over and over again, whether it's scheduling jobs, like a cron job essentially and if you're familiar with Java, you have these frameworks like Quartz and other things or whether it's building something around backups of database and data, transferring files and everything else. So these are building components that we constantly, always do authentication, authorization we always do those. So when I left finance and IT for finance, I was frustrated with that and basically that's what we started.
Khash Sajadi:We started a company called Cloud Blocks, started with that name, and the idea was this is 2013, 2012. So we are about four years maybe, into App Store idea for phones. Iphone is probably six years old and we wanted to have an app store for data centers. That was the idea that you go to this website and you have different apps and you click on this app and you install it on your servers. That was the idea. Now this is the time that pretty much the only similar thing I would say around it was probably the Amazon images from Bitnami maybe. So we started kind of that idea and we put out for the first iteration.
Khash Sajadi:We selected 12 common things that we used to do. One of them was deploying the rails as a stack, because we were running the rails stack ourselves and, like any good startup, we started measuring and looking at the metrics and we started to see that that app most of the 12 or 11, was getting a lot of traction. So what we did was we dropped everything focused on deploying rails and we changed the company name because there was another trademark issue, to Cloud 6 and 6. And that's the rest of this history. So we didn't set out to fix deployment. We kind of stumbled upon that as like 12 of the problems that we wanted to solve and then we realized that the framework on its own can be a business and it's a big problem for customers. Later on we added other frameworks on top of rails and other things. None just Ruby, not just rails. But that's how we started it. So you were absolutely right. It came from a frustration.
Àlex Rodríguez Bacardit:It always is. You know, I'm ex-the-loid, ex-a-big consultancies and we were like, oh, this sucks Like if these people can make millions and work like terribly we should be able to create a consultancy ourselves and we did it.
Àlex Rodríguez Bacardit:Of course, we're never going to be as big, but at least we can sleep at night. You mentioned rails. Is good that you bring it up, because I think, like, as time goes by, we will become the last man standing in the Ruby on rails world. You know, like 10 years ago, every bootcamp was offering rails, teaching the new developers rails, and eight years ago, or seven day transition to doing Nodejs and React right, there's no more rails as in like, rails has always been dead for many people.
Àlex Rodríguez Bacardit:Yet we see, you know, we see another big wave of rails based startups, because back in the day, you know, rails was super popular and it was used by many companies the size of GitHub, stripe and whatnot. But now we're seeing the people being laid off from these companies or Shopify, you name it. They're creating the new companies in rails. So we got a ton of deal flow, but most of the agencies have shut down or they have stopped doing rails right, and so there's like oh, there's too many rails projects. I don't know. Is this something that you're seeing as well, because obviously you have a great overview of what's going on in the tech stacks of the companies that you guys help to deploy right. So what are the particular strengths you're seeing in terms of tech stack and the new company?
Khash Sajadi:That's an interesting question. So you're right that we have some sort of vantage point that we can't have a look at what the overall makeup of different things is and our data might be slightly skewed, because we started with rails and we've got a name and a brand in rails community, so we kind of get a bit more skewed data around that. But you're absolutely right, we're seeing a revival I need to say that, but in a different way. I think this revival has arrived at from two angles. One is, I would say, a sort of a frustration with the plethora of different things that you can find in Nodejs and JavaScript. So React's been a big, huge framework. It's pretty much won the game off the front end for many Nodejs. We've had Meteor, we've had like other things, and even if you look at technologies that are more nascent, like spelt and other things, even if you look at attraction in a React by far is the most popular one. I'm not getting into the religious world or whether it's the best one or not, it's just about the trend. And the reality is that, while it addresses a lot of the front end problems that are about responsiveness and everything else, it does two things that, in my opinion, have defrostrated the developers. One is this whole idea of single-page applications, which suits some use cases and some doesn't, and the other thing, it doesn't have much, at least until now, about the back end. So what is feeding these things? That's hence the popularity of things like Firebase and now Superbase and other things that will just wrap up your back end for many aspects and then feed it, but that's not necessarily for everyone. So there's been this kind of search, if you will, from developers to have something that works for the back end, and if it works for the back end it might as well just work for the front end.
Khash Sajadi:Now, companies or communities like React, for example, they're now kind of going back and this is a second angle of the kind of popularity resurgence of rails. Is that these communities going back to server-based components, rendering things on server, kind of as if we're going to full circle again, just that consuming API and building a DOM front end. They'll be going back all over again and it's kind of like, if you stand by the river long enough, you see, it's kind of like that If you hang around long enough in the Nodejs community or you hang around long enough in pretty much any web developer community, you see that the same pattern starts to kind of reemerge over and over again. And I think we are at that point and, given the point in the cycle that we are, rails is a very strong contender in taking care of both the front and the back. But I think if you look at other communities outside of rails and these communities tend to have some sort of silo kind of integration in that sense that if you are a rails developer you're less likely to be involved in sale like Laovall or other communities around that.
Khash Sajadi:If you look at PHP, for example, it's also having resurgence in the sense that they are trying to kind of get PHP's older than rails and still it's having a good day. And I think it's because of this approach that they've taken about hybrid, so kind of adopting to the idea of that I can have a backend that feeds the API and is powerful and has data accessors and all that sort of stuff. But if you want to plug it into React or whatever is that your front end developers fancy, you can absolutely do that and I think to an extent this resurgence of rails is going to lead to a hybrid approach where rails going to take care of things that are more difficult on the back end active record, authentication, security, all sorts of things that people want to get right and then front end, probably Nodejs of some flavor will be there. So that's what we are seeing. We're seeing a hybrid thing emerging from the back end and front end.
Àlex Rodríguez Bacardit:Yeah, actually I was trying to recall what was the last pure rails project that we've done and we're a rail shop mostly, but we've been doing React now with Nodejs and Python on the back. But the typical pure project in rails is both back and front and it was typically more like inwards, facing applications like back office and internal tools and all of that. I think it's been like three years that we haven't done any of this. So today, with the popularity of stuff like Prime React, with build components and design systems, you just plug it in and it's good. Developers like it, designers sort of like it as well, uxui people are not hating it. So it works well and the clients love it, because then the front end doesn't take away a big chunk of the budget.
Àlex Rodríguez Bacardit:But what we're seeing is rails is being just moved back to the back end, if you will only, and we're seeing less and less rails front end stuff, which I think it's OK. It's a sign of the times. Like not a big deal. Actually, that's a perfect segue to comment on your tech stack. So I seem to recall that you guys building with the Ruby and Rails back in the day, but I'm not 100% sure. So what's your tech stack and why did you decide to build it this way? Sure, absolutely so that's right.
Khash Sajadi:We started as a rail shop. We like the wire stack is by far still very rails heavy Over the time. As you can imagine, rails is a very good and opinionated framework when it comes to building web application. I think its strengths are a lie around active record and the whole gem community around the ecosystem that's around that. But the things, the kind of things that we do, like talking to a cloud APIs or dealing with Linux APIs and things around firewalls and network manipulation and configuration, having metrics collected, all sorts of things that is not necessarily part of a web stack, a traditional web stack. We started to kind of break it apart into different things. So now our stack is primarily we have a monolith of Rails where it serves the API and the web.
Khash Sajadi:At the front we tend to stay on the top of the Rails or edge Rails. We can upgrade and patch all the time. We don't want to leave things lingering on all the version of Rails for a long time. And on the back we run and we hosted on Kubernetes ourselves. So it's deployed with Cloud 66 kind of inception. And then we have my SQL at the back and I think it's my SQL memcached in and Redis. So those are kind of the backend major centers. And then we have a lot of go as a system language. Yeah, system programming language. Essentially, we found go to be a very good tools to build things that communicate internally or talk to Linux or call back over as a state to get to other systems. So we have that and they sometimes talk to each other through a kind of an API or sometimes they run the group around the database. So that's primarily our stack right now. On the front end it is, as I said, rails, but with JavaScript.
Àlex Rodríguez Bacardit:So we built Is it vanilla JavaScript? Or have you been kind of transitioning from something like Angular and then React, or going through what was the other one?
Khash Sajadi:Ember, ember, yes, so no, it is vanilla JavaScript, it's vanilla JavaScript.
Khash Sajadi:Yeah, so we have. We've been kind of I think we at some point we forward into using View, but that didn't work out really well because not nothing against View, but because we just had it partially in the system and it was just like a whole asset pipeline and a whole webpack and everything was kind of went then really overly complicated for unnecessary reasons. One thing is that we've built internal applications as well. Like we have a big system called Mission Control, which is our kind of window into operations and it's used by our support team to collect data. We use it for business analysis and everything else, and that is also Rails, but it is Rails with all the new stuff like hot wire and turboframes, and we also adopted the view components from GitHub into Rails. I think combined a combination of, especially for internal tools, that is very appealing. When you combine it with things like tailwind, view components, hot wire, I think it works in a way that primarily allows our developers internally to build something really fast but consistent and coherent for internal consumption.
Àlex Rodríguez Bacardit:Yeah, exactly, and it's great hearing this from you for two things. One is you can tell that you build something like if not most of it yourself, because you're so on top of your tech stack that you still have it super fresh in your memory. And the second is it's good to hear because it resonates with pretty much everything that we do when we're building Rails applications, so it seems that we're on the good path. You mentioned this hot wire turbo. That are the things that we are experimenting in some of our recent projects and right now, one of the things that confirms the theory that Rails is on the surge is that we have seen other tools being built for developers Like.
Àlex Rodríguez Bacardit:We're using AVO I don't know if it's AVO or AVO as a replacement for Active Admin. We are using MacLev, which is the Locomotive CMS. I don't know if you ever heard of it, but yeah. So the new iteration of Locomotive and these tools are really good. They're up to nowadays standards and it helps people build with Rails much more easily, like we used to do 10 years ago. But somehow along the path we lost these tools because people transitioned to freaking React and Elixir and whatnot and Rails lost its scope. But it's good to be back in the center or it's good for these people to be back? What are the pros and cons of these tech stacks that you have experienced over the years? I mean, I know them, but our audience might not know.
Khash Sajadi:Yes, so, if you're talking about the entire tech stacks, I think the cohesion and I tend to. You mentioned that our tech stack is very fresh in my mind Because, yes, you're right, in 10 years ago we started. Obviously we were involved. I was involved very much with the tech stack. Right now I'm not really allowed to touch things because I tend to break more things than I actually fix, so I've resigned to building. I feel you.
Khash Sajadi:Yeah, obviously my job when it comes to tech is building reports and getting data out For business purposes, so that's basically my focus at this point when it comes to the code base. But a couple of things here is kind of interesting. So and I look at frameworks not purely from a technical point of view, but from a business point of view as well it is about the talent on the market, the community, the size of the pool that you can drop from if you want to hire someone, and a lot of those things play. So you might have someone who's a good, say, rails developer, but they just don't want to do Rails anymore because they want to have exposure to I don't know, like spelt, and those are the things that I look at primarily from that point of view. So when it comes to something like Rails, for example, specifically, I think it's a very good framework when it comes because of the whole, the fact that it covers the entire stack in the front and the back, and that helps with getting things done really fast, because you don't have the different teams that you have to split the work across and say, you know, okay, my backend part is done, but I don't know what about the front end. And then you get to this contract around the APIs and are you using it right or do we have validations for it and all sorts of things and dances that come with it, and so from that point of view, it's kind of like an interesting one.
Khash Sajadi:But one interesting kind of flavor, if you will, of frameworks that we are seeing quite a lot of is around what's being popular as a jam stack, but it's not necessarily in a JavaScript involved. It's been like JQL, for example, and things that generate static sites. So I think a combination of the fact that you can build a fully functioning web page during a build side. From a tool chain point of view, then you have things like containers, which will allow you to do that pretty much anywhere in a uniform way. It's not just like works on my machine and then you take it to a server and all of a sudden one dependency is missing or something. So containers help with that and at the same time, things around cloud, which is like S3 and serving web directly from the bucket with high availability All of those things together I kind of have lent itself really well to building, you know, really content heavy things that don't necessarily need to have a database at the back, and so you know you look at things like WordPress, for example, where you had to, you know you wanted to just serve a web page and you go to my SQL and pull out the content and render it as a single page.
Khash Sajadi:That just does that. Now you know you can just build it during the build time, and even things around like web-based status pages, where are seemingly dynamic but you only need to update them during an incident can have this ability of just re-rendering and rebuilding and pushing into S3.
Khash Sajadi:So your status page is highly available because it's hosted on something like S3 or the flavor of that, so all of those kind of interesting things. But then the downside is that as soon as you have a dynamic part to it, then you know, okay, so where is that going to come from? So this is, like you know, the two parts, if I got the question right. This is about like different frameworks of kind of thought. I kind of see those as the two kind of main things. I think there are still glitches around the combination of those. If you have a backend that's running on, say, rails and you want to have a front end that's running on something else, you know, there's still that kind of fluid stage. I don't think we've settled on anything yet. There's still a market score.
Àlex Rodríguez Bacardit:But it's good, because very rarely I get to have this or these very informed conversations with a CEO. With a CEO is normal, right, because they're much more in the mud and they're still keeping up with the technology, but the good thing about being a super technical CEO like yourself is that you get to understand certain concepts that have a direct implication on business, like technical debt. Right, I'm seeing a trend whereby some companies are starting to measure technical debt and have it as a KPI for business and the company. Right, because at the very end it's you know, it's time to deploy to production, it's time to hire people, it's a cost in operations, effectively speaking, but non-technical CEOs don't seem to get it right. So it also.
Àlex Rodríguez Bacardit:There's a. I don't know if that's correlation or causation, but the technical CEOs don't seem to go as often into the future. They're going as often into the let's rewrite the entire application every five years, you know. So you've stuck to Ruby and Rails for 10 plus years now, right, I don't know if you've ever considered moving, or like refactoring, rewriting the entire application with another back-end language. Yeah, no, we have not, not under any circumstances. Like it wasn't, even like a passing thought. Okay, no, that's good.
Khash Sajadi:Sometimes you have. So here's the kind of the thing. It's like trading you know W-N-W, you don't. So you know a lot of times you know if I were to think fresh and go, okay, you know what I want to build a business that is going to do deployment of Rails and non-Rails, containerize and non-containerize, jamstack and dynamic sites and all the services. So what would be my technology of choice today? I might make different choices, but there are two things here. Is that, first of all, this is today. That was 10 years ago.
Khash Sajadi:There is about the availability of talent. There is a availability of like, how fast can we give things to the market? Because it's a business, after all, we cannot be all technical professionals. But on the other hand, it's about what you know is what you've done.
Khash Sajadi:So there might be a case that we stumble upon a problem that multi-threading in Ruby is not known for its strength, or multi-threading it does have support for that and the fibers are coming along and all sorts of things. But if you were to say what is the language of choice if you wanted to write something super multi-threaded, probably Ruby is not the top of it, maybe AirLanguage, maybe Go, you know, but Ruby probably is not that. So a lot of times we get to the point that we have to solve a problem that involves heavy multi-threading and erase conditions, and you know mutuses and weights and whatever else, and we go. If we wish that it was written in AirLang, right, and you go. Well, what else would? So at that point in time, when you have that specific problem, you might wish for a different thing and you know, as a passing thought you might say I wish my stack or something else. But what I'm at this point ignoring is like a line of 99 things in my stack that are actually working perfectly fine because they're running on Rails. So I don't know the implication of that. And if I were to run something on Go, then my web you know active record would have suffered quite a lot. You know my interactions with database would have been probably a very different kind of beast. So you know, it's easy to make those assumptions when you're like you know, like you know when you wake up in the middle of the night and you think I'm going to solve that problem, I had Go or like Rust or something, but realistically that's not the end, because you know you have that kind of in your top of your mind. I've never we never thought about you know what. Let's just like rewrite the whole thing.
Khash Sajadi:As I said, you know, the only foray that we had into some sort of split between the front and the back was when we did view, and I think we suffered from two things. One is that we were also learning view it was a very new framework was while back. And the second thing is, you know you don't want to halt business, you don't want to stop everything and, just like you know, hire customers. I'm sorry, I'm not going to roll out any features, new features, I'm not going to fix any bugs because I'm busy reacting my front end view. So you have to, you know, roll it out piecemeal, and so that involves a lot of complexity with the tool chain, compiling deployment methods and assets and CDN and everything else, and you go. Is it worth it Really? What are we going to get at the end of it? So you know we are still running rails.
Àlex Rodríguez Bacardit:Yeah, because it was 2016 or sometime around that when we were seeing everybody was migrating, everything to go. Go was supposedly the rails killer back in 2016 and then, like Sir, came around and guess what? None of them really killed rails, right, and I don't think anything will kill rails for the time being. I like, maybe, maybe Python if we keep seeing so many people moving into Python nowadays and AI and big data but definitely, like, rails has got this. What you mentioned, right, it's like super. It's super strong, super cohesive. 99% of projects are built with rails. 99% of Ruby projects are built with rails. There's no dispersion of frameworks, right, and other strengths that it has. But you briefly mentioned that you have got something in Go which you know we all assume. It's like a microservice and what you mentioned on a concurrency and whatnot.
Àlex Rodríguez Bacardit:We saw that it was a trend that we have sort of suffered as a service provider, because I remember, like 2017 was got like the explosion of like people going into everything is serverless and most people went into serverless just because it was a trend and we were actively advising people. But you can only go. You can only go so far as a service provider. Right, you can counsel, but if the client wants it to build it this way, you got to go fucking do it because they pay you to do it right, but anyway. So we were seeing that the case with new startups and people less, maybe lesser experienced people were opting for a super complicated technology like serverless, and it was definitely over engineering in 90% of the cases. None of them got it right.
Àlex Rodríguez Bacardit:And now what we're seeing nowadays is that mostly this kind of architecture is built inside of something bigger, but like the whole architecture is not serverless. It's just like this part that deals with the IoT messaging, this part that deals with, you know, concurrent deployment. So with not, this is something that you can. You can probably explain a little bit, a little bit farther.
Khash Sajadi:Yeah, that's true. So you know again, it's kind of the same thing. If you think about the front end technologies, you know you wait long enough and you see the resurgence of the same kind of concepts. And you know just an example on the front end, if you remember, you know, during the dot net kind of popularity on Windows side of things, there was the whole Windows front end or Windows framework, front end framework or something that was exactly like what like react components looked like to a great degree. It was not for web, it was for desktop applications on Windows. But you know WPA and WPF, I think it was called, and all those sort of things around, that kind of the same thing and they just died down because web and who builds desktop applications. Then you know all that kind of thing.
Khash Sajadi:But when it comes to back end applications kind of like the same thing you have this kind of micro services versus what it was, service oriented architecture. Like about 20 years ago, maybe 15 years ago, everything was about service oriented architecture. You had in a Java, developers coming in with beans and you know having you know a spring framework With configuring an application was basically you had like these mile long XML documents that would configure your application with your services, factories, repositories and the domain driven design and all sorts of things that would just glue these tiny pieces of code together. Now it would compile into a single model. It, but from a developer's point of view, just writing on this, working on this service which is then configured, and dependency, injection in version of control, all those concepts that we were looking at 15, 20 years ago, kind of where around that. And with that comes a bunch of challenges right. So you have configuration challenges, you have traceability challenges you know, trans distributor transactions when it comes to database logging, all sorts of things that you have to sort of. It doesn't mean it's impossible, it's not. It doesn't mean it's necessarily a bad thing, it's just these challenges that you don't have when you deal with a monolith. Now, on the other hand, when you're dealing with a monolith, you have other challenges, but in a different challenges. Now, going with one versus the other, because the old way is just bad and the new way is good, and the same way that we go object to this, bad, functional is good or, like you know, it closes a good part versus, like you know, go to is a bad, like just different, different paradigms, each suitable for one thing, and you know, microservices.
Khash Sajadi:On the other hand, with the reset, we know, with the rise of containerization, kubernetes and everything else seem to kind of created the hype and a wave that people kind of really wanted to jump on. And I think go was a beneficiary of that in a way that you know, if I want to run microservices, if I want to run serverless, then I'll end up writing something that can be independent, self compiled, small and go is a good candidate, so it's rushed and you can, you can create that, so go benefits from it. But then you get into well, hang on a second, I have no server, I have no persistence. So what am I going to about persistence? What if I want to store file where we're like oh, you put it into S3, but there's latency and all sorts of things around that. That just gets into this kind of cycle that we see now.
Khash Sajadi:Everybody goes back out of microservices, back out of Kubernetes, and goes like you know what? I'm just going to build this super solid monolith. So I think this thing the sweet thing, you know like any good question. The answer is it depends. So you know, you take the problem, look at it. You know in depth and you choose the right technology. And you know, I don't think you can see there was a time that you and I remember it was like everybody wants to put their grandmothers into a container. Now you know, it's kind of like yeah.
Àlex Rodríguez Bacardit:So what is your prediction for the future? With regards to serverless deployment? Right, because back in the day, you know, lambda was the US, all the hype. It seems it's called down. Like you know, we got big players like Verso and cloudflare like pushing for developments at edge and you know, shopify has partnered with with cloudflare to bring that as well. So I don't know like what is. We want to know the opinion of an expert.
Khash Sajadi:I'm hardly. I have my my crystal ball with me today, but I mean that's a very good question. So I think none of those technologies that we've seen is going to die anytime soon and a lot of those have these tendency of having the hype. Remember what is that Like? A form of that? Was it like the WASM? Was it like WASMOL or WASP or whatever these protocols that GRPC were to replace, all that kind of everything around that? So I think we will settle into a phase. It doesn't mean that we're not going to have new hypes, but with the existing technologies that are coming down the hype hill, we will settle on serverless, having its own space for stateless, just question and server functional things like IoT, things like personal assistance, voice recognition, that kind of stuff. When you have a problem, you have a question, it needs to go away, think about it, come back and that's basically the end of the transaction. There is no accounts, there's no logging, there's no persist my data, upload my files, or there's none of that. I think that's one part From a database technology.
Khash Sajadi:I think we've seen already the resurgence of our DBMS, albeit in different forms, more distributed, as opposed to the wall of MongoDB hype where everything was kind of schemaless and nobody cared about joins and nobody wanted to talk about indices and also everything was queried through MapReduce and JavaScript. So I think that kind of settled down, but it didn't mean that document database of MongoDB died. It doesn't also mean that we put everything in reddish. We now started using reddish for what it is, which is a very good, robust, key value store with a wide range of data structures that it supports. But we know, don't go around and put our customer data in there. We have MongoDB or document-based databases for a lot of cases like truly schemaless data, and we still have Postgres, which is going strength through strength as a normal old-school, 40-year-old technology on the line coming back from 1980s and 70s in Berkeley University, where you have RDB methodology, essentially being bored, asset transactions and all those crazy arcane ideas which are working perfectly fine and are very suitable for building scalability. So all of that means is a long way of saying that.
Khash Sajadi:I think technologists have a tendency of settling down to what they are very good at and people tend to use them for that. So to me, containerization is here to stay. It doesn't mean that we've got to put everything in containers, but I think it's there to create what it's good for and that's a separation between devs and ops, and that's what it does. And if you need separation between your devs and ops containers, they're probably a good thing. Functional programming and FAS, mililanda and serverless again have appeal in two cases. I want a security when people don't want to think about their servers and patching and restarting. The second thing is when you don't have any persistence. Everything is very short-term. Transactions and all of this have their own kind of merit. So I think we're settling down on those things. It doesn't mean we're not going to have new hypes Tomorrow. There's going to be a wave about God knows event-driven container lambdas, whatever that means, but I mean WASP.
Àlex Rodríguez Bacardit:With AI? Yeah, exactly.
Khash Sajadi:Now you want to run everything in a browser. I'm sure there will be a complete database that you can only run in your browser. But is it going to replace Postgres? Probably not.
Àlex Rodríguez Bacardit:Yeah, which brings me to the question Because, while we're seeing a lot in, I'm also an investor myself and, as it is in the startups, I try to advise them technologically. And it is a very heart-free company to not give in to some of the really strongly opinionated developers that want to change technology and adopt this new hype. How do you deal with this internally? Like, say, we're very strong in Rails, we're really strong in React, but somebody says we could build this in Go. It's like we don't do a freaking Go or this technology that is not sufficiently proof, it's not bad, I'll test it. And in some companies we've seen this is a recipe for failure. Sometimes it can work out, but that's more the exception rather than the rule. And so how do you deal internally with the expectations and how frameworks and libraries decide it? Is it like a grassroots movement or is it like a top-down in your company?
Khash Sajadi:So this is a challenge and it's a very good question. This is a challenge that we also have and I think the way we do it kind of goes back to your point about technical, technically experienced leadership. I think that kind of helps a lot. So I think we've, at least at Cloud 6.0.6, when it comes to user interface and UX, our lead UX person is a very experienced developer and he's the guy who holds the fort. When we have a new hype in the market, let's just rip everything out and replace it with some React-based flavor next to it Nox or whatever. He would just say OK, let's just wait, let's just see how it plays out. It has these issues. What are we going to do with this? And that's kind of a good thing.
Khash Sajadi:You can think of it as a kind of like a technology conservatism, in a way, where you, when you're experienced and having seen these trends come and go and settle into their own places, can you hold and wait until things play out. Or you see something as a vision and you go this is not going to play out where you think it's going to go, and it might be wrong, and you kind of hold that and because of just the nature of the thing that you are seeing your position. You can have the veto. Most of the time you end up being right, not because you are right, because you're just biased towards your decisions. But there is a danger there, as I'm personally speaking for myself. As I get older and I become more conservative in my decision making as all human beings become, because we have more investments to protect, I am exposed to the bias and danger of not listening to new ideas, being more conservative and more closed off to radical change and not being open to having those accepted in workflow in my life. When we hire a new, fresh talent who is extremely intelligent, very good at what they do and are very much in touch with the new technologies, then here's the balance that comes with that management. They come to you with an idea and you don't want to constantly push them back and say, no, that's not going to work. No, it's a business, it's not a lab, you're not a research facility, you're not a charity. You don't want to do that because that discourages innovation and also it plays into your own biases, it makes you more closed off. But so you have to have that thing that you sometimes give in, sometimes experiment and you have to have a structure for that, like how much are we allowing experiments? What is the scope? How do we roll this out? Are we rolling it throughout the whole thing or we have in a different areas One of the things, for example, just an example that we've done with our code bases.
Khash Sajadi:We have risk areas within the code base. There are areas that we are very conservative about the technology. When it comes to security, networking and firewalls, we are extremely conservative. Making a change that requires so many different code reviews and so many approvals, let alone technology changing there, probably is not going to happen because that's an extremely high risk area for us. But we have very low risk areas around our code base as well. You can just make changes and you can experiment. So if we want to even at some point say, maybe we should experiment with this new way of doing things, maybe we should experiment with new technology, as old guards, old people, as conservative kind of dinosaurs of technology I'm speaking for myself we have areas that we can let people play. We have areas that we can let them experiment, and I think that is how we balance balancing. I don't think it's the best way. It might not be, it's not the only way for sure, but it kind of works for us that way.
Àlex Rodríguez Bacardit:It's actually very interesting. While you were explaining it, I could see the whole code base being painted in different colors and I was like this is red, don't fucking touch it. This is green Marketing pages. Not very important, right, you can play around here. We actually have.
Khash Sajadi:I don't know if that's how you do it, but I know we have one file in our code base that has a very big old caps comment. At the top it says do not touch this unless you actually know what you're talking about. As a great man said, with great responsibility, with great power comes great responsibility, uncle Ben. So if you touch this, you need to know what you're doing. So there are files that even are super red.
Àlex Rodríguez Bacardit:Be prepared to face the wrath of our CEO. Yes, if you touch this file.
Khash Sajadi:It doesn't mean that I am a very big advocate of simplicity over cleverness. I really don't like clever, because I'm not a silly clever person myself. I don't like clever code. I don't like regex that much. It's like somebody comes to say, look at this, I consolidated 20 lines of code into one. I'd be like, no, I want 20. Because I can't read it and I can't understand. Even if I write it, I'm sure six months down the line I wouldn't be able to. What was I smoking when I wrote this? It works, but I cannot check it. I cannot test it, I cannot change it. So a lot of times it doesn't mean that we have this code that's super fragile and super complicated, that we just put a big comment and said don't touch Because you've got to break something and you wouldn't know. It's more about look, it's simple, it works and it's super sensitive. It's not about fragility, but it's about sensitivity. So that's why we have those kind of code parts.
Àlex Rodríguez Bacardit:Spot on. That was really good. Thank you for sharing. We had a couple of questions. Our CTO has sent a couple of questions Because obviously, I think throughout the years of using Cloud 66, it's like I've noticed a couple of things that are relevant maybe. So one of them, with regards to the pricing, seems like you guys have been experimenting with different pricing plans and tiers and whatnot, and from charging by server to charging by CPU core and all of that. So other platforms like Heroku, they have been more conservative, and so what have you learned with all these pricing changes over the years?
Khash Sajadi:Pricing change is probably the most scary thing that I have done and I will ever do. I don't think I will ever get to that and the reason for that is that if I were to go to market and sell I don't know this cable for $100 and all price it for $100, right, I don't know if I'm going to sell it or not. And when it comes to startups, when it comes to a new idea or new way of doing things, there's a lot of cases that you don't know whether you have a product market fit or you actually priced it wrong. It's just too expensive or it's too cheap, so it attracts the wrong audience. So pricing is one of those things that you cannot really be sure until it's out. You cannot say you kind of rely on gut feel until it's out you go.
Khash Sajadi:I think 20 is good because I kind of feel that's good. Or you look at your competitors. And when it comes to SaaS, pricing is not based on the labor and the cost of material. A lot of that just goes away as your scale. So you have to kind of price mostly based on the value you add and what you add in terms of value to developers. Life, daily life is a subject to think. You cannot measure it by hours you save because it's spread across a long time with a team of different shapes and forms. So when we roll it out, then the other challenge with pricing is that you pretty much can never lower your price, Because if I start selling this, I mean a lot of companies do it, we just don't want to do it.
Khash Sajadi:If I go to my phone company, mobile company, cellular company and I pay $20 a month for a phone line and then tomorrow they reduce the price to 10, I cannot go back and say hang on a second. I just signed up yesterday and now I'm on the hook for 20 for a year. Can you give me the deal? No, no, no, that's with new customers only With SaaS you don't have that. If I were to go, I'm going to start with 100, and then I realize it's too expensive and then I reduce it to 80. All my customers who are paying 80, 100, are going to come back and say, well, what about me? And if I say no, it's new customers only, they go and say, screw you, I'm going to cancel my account. I'm going to sign up another account. It's just as good as the next one or the old one and I'll just benefit from that.
Khash Sajadi:So always, you see that companies, especially SaaS companies, they start very low and they can increase the price as opposed to the other way around. But the danger in that is, if you give away something too cheap or subsidized by VC company, VC money, which is a lot of companies do you do that? You're in danger of undervaluing your product market fit. If I go around the corner and just give hand out $1 bills to anybody who compasses by and say I have hyper-growth, like sure, I mean, if I give up, yeah, sure, yes, I'm going to give you a dollar.
Àlex Rodríguez Bacardit:Until money runs out right.
Khash Sajadi:Exactly that's exactly what a lot of companies do. They just go and subsidize a dollar bill with $0.90 because the VC pays the other $0.10. And they go. We have hyper-growth. Look at the stars we have on our GitHub account.
Khash Sajadi:Ok, so pricing is kind of. That's why it's such a challenging thing. So what we've done is that we wanted to. We rolled out our original pricing, which was per server, and for a long time we always charged per server because we thought that's a true reflection of the value we add to a customer's life. If you have a, we don't want to have a contract that locks you in for two years at a level that you might be using to experiment with your own startup and your own idea. So we thought server is a good measure.
Khash Sajadi:But recently we changed that for a very simple reason. We changed it to usual. It's kind of a traditional fast buckets of $29 and $49. And it gives you a bundle of those. The unit price for servers is still the same. We're not increasing or decreasing that. It's a still per server, the same, but you buy it in a bundle and the reason is predictability.
Khash Sajadi:That's another thing that people really care about, it seems, and I understand why? Justifiably so, because the last thing you want is to think about your bank account every time you click a button to say scale up and those two things are not necessarily interlinked. You might want to scale up for some other thing that actually brings you enough revenue to justify that cost. So as you go and say I'm going to add five servers because it's Christmas time and I'm getting more customers to my Christmas shop, I don't want to have that conversation with my CFO or my CTO or whoever signing the check to say, by the way, this month we're going to pay $200 more because I just clicked this button 20 times. So the reason we did that was because of this predictability, trying to add some visibility into your cost. That's kind of the reason for what we're doing and the other thing is for us.
Khash Sajadi:The other reason was feature distinction. The biggest cost that we have is engineering and we spend that engineering hour on building new features. Now, if you look at our usage for the feature deployment is by far the highest. Then we have other features around debugging, like logs and metrics and other things, which uses, and then the rest of the features, and we have hundreds of features that are very, very long tail.
Khash Sajadi:Not everybody uses failover groups, for example. Not everybody uses database replication. Some people do, some people don't. Not everybody uses some sort of extreme security paranoid mode like 2FA that we have. Some people do, some people don't, and every one of these features that we build cost us a lot of money. So I don't want to charge everyone for the money that we spend on something that only a few people use. So you want to distinguish between those. So if you're one of those people who wants super locked down to a fair with two keys and a backflip, then you pay a little bit more per server than somebody else. It's not that the value of that server has gone up, it's just that you want to make the product cheaper for people who don't use everything you have and get the other ones to pay for what they use.
Àlex Rodríguez Bacardit:Yeah, awesome. So we got time for only one last question. I want to be very, very, very serious with your time and you've been extremely generous, so this is signature question of the podcast. So what's been your biggest technological fuckup? And if you can't quantify it with money, something you've done yourself, I mean you got your own app to it.
Àlex Rodríguez Bacardit:It's not something I've done. Most people try to give me the crap of I hired the wrong person. No, it's just like something technical, something that you have coded yourself Wipe out the data, something like that.
Khash Sajadi:So, if it is, about Class 66, I have done a lot and I cannot measure even the cost, but in my career I've done also a lot. You know, this is kind of a function of time. I'm going to blame it on my age, it's like you know.
Àlex Rodríguez Bacardit:I've done bonus points if it's Lehman Brothers related, because they're not going to come around.
Khash Sajadi:Yeah, I brought in the whole financial industry.
Àlex Rodríguez Bacardit:That would have been awesome. Thank you for doing that.
Khash Sajadi:No, just kidding. I know that what I did was I did what. It wasn't a Class 66, but it wasn't another financial kind of company. I was responsible for building a caching framework for storing very expensive calculations and the idea was that you know, you have these calculations around financial instrument that takes a lot of time to calculate. So we would calculate a lot of them and warm up the cash and put it into cash and I was responsible for the caching framework.
Khash Sajadi:One day I come to the office and I see a giant toy donkey sitting at my chair and I realized that I won the Donkey of the Week award and the award was given by our CTO to the biggest fuck off of the week. And it turned out that I made a tiny change in the caching framework that meant our cash hit went from like 80% to zero and it went into production because caching is one of the hardest things to test. So it went into production and that every customer's account went into a halt because we had to calculate these things. It was a cash miss every time. So yeah, I guess that would. How much did it cost? Luckily, it cost me only a donkey, but the company probably paid a lot more.
Àlex Rodríguez Bacardit:Yeah, I don't know if they were compensating people on downtime or whatnot, but probably a few dollars. I mean that donkey was a bargaining price.
Khash Sajadi:Well, thank you.
Àlex Rodríguez Bacardit:That's a really good one. Thank you very much. Khash. Thirty seconds for you and rolling out the carpet, so what can we do to help your company, cloud 66, or yourself? Oh well, thank you.
Khash Sajadi:For me it was an honor to be on your show and thank you very much for giving me the chance and the time. We are here to help software developers so, as your audience, I also support developers. I hope that we can help and thank you very much for giving me the opportunity to present what we do and hopefully we will going forward, help together, help a lot of software developers and fellow developers of our community. We will.
Àlex Rodríguez Bacardit:Thank you very much.
Khash Sajadi:Thank you.