Today’s episode features Khash Sajadi, cofounder and CEO of Cloud 66 and hardy DevOps veteran. Listen to us talking about how DevOps evolved and shaped the industry, the importance of getting past the hype, and what to look for when deciding on a technology stack.
Key takeaways:
- How DevOps technologies evolved over the last 30 years.
- What made Kubernetes win the container wars.
- How to sell DevOps services to companies.
- How technology choices impact business success.
Listen to our entire conversation above, and check out my favorite parts in the episode highlights!
You can also get Semaphore Uncut on Apple Podcasts, Spotify, Google Podcasts, Stitcher, and more.
Like this episode? Be sure to leave a ⭐️⭐️⭐️⭐️⭐️ review on the podcast player of your choice and share it with your friends.
Edited transcript
Darko (00:02): Hello, and welcome to Semaphore Uncut, a podcast for developers about building great products. Today, I’m excited to welcome Khash Sajadi. Khash, thank you so much for joining us. Please just go ahead and introduce yourself.
Khash: I work at Cloud 66. We founded Cloud 66 back in 2012. Primarily my background is in software. As you can tell, I’m an old-timer in our industry and I’ve started with electronics and then moved to software pretty early on. Most of my career, I spent in the banks, most investment banks, and then from there I immediately switched over as soon as the banks went down in 2008. I switched over to start my own company. And that’s been my story so far.
App Store for data centers
Darko (00:57): Great. Before we continue, can you tell us a bit more about what your company is working on and what’s next for you guys?
Khash: We started Cloud 66 because we had a problem ourselves we wanted to solve. We started with something that we used to call app store for data centers. The idea behind it was that we used to do the same thing over and over again at every job from authentication to cron jobs, to all those things that you keep doing every time you start a new job, you have to kind of take care of.
We thought, “Why don’t we build an app store, but this time for the servers?” You could go to our application. You would go to our application and choose your server and choose the apps that you wanted to install on it. We rolled it out with about 10 to 20 apps. And one of those apps was to install a full-stack Rails backend onto a server. So, like any other company that wants to look at the usage of the product, we looked at the metrics and that app was the only one that was taking a lot of heat and a lot of traction. So, we dropped everything else off and focused only on that. We changed the company to be called Cloud 66. And now what we do is exactly that: we deploy any application for you from your source code on your own servers on any cloud with us taking care of the DevOps for you. So, you can think of us as DevOps as a service.
We’ve been doing this since 2012. We rolled out our first Rails-specific product in 2013. And since then we added Node, then we went for containers, so you can put any application in there. Then we did support for Kubernetes. And now we are just, as you said, what’s next for us? We are now getting into JAMstack and static websites for latent deployment on your own buckets.
Separating hype from reality
Darko (03:31): You’ve mentioned that you’re in the industry for 30 years. So, regarding these technologies, what is the hype? What is real? What is practical? What is not?
Khash: We started, as I said, via Rails. Rails was very exciting in terms of a lot of decisions and how to build up scalable, reliable, and secure web applications. All of those decisions were almost made for you. All you had to do was just fill it up with business logic. And it was very exciting. Coming from other frameworks, you could see how exciting it could be for PHP or other things around that. And that’s obviously a long time ago.
As we started doing Rails more and more and rolling out a product for Rails, one thing that helped us quite a lot was the opinionated nature of this framework.
When we rolled out Rails, we have a lot of customers who had other frameworks, the JSON frameworks, I would say, using it. And back then, which is what? Seven years ago, Rails was primarily serving web and mobile. The backend of mobile was served with Node. As you can imagine, we had a lot of customers who had their Node deployed some other way. As you can imagine, everybody got their own framework that’s the best thing since sliced bread. And Node suffers from a great fragmentation of these frameworks.
We went out and we tried to replicate what we did for Rails for Node, but the challenge here is that you don’t have just one Rails. You have a lot of different Node frameworks each with its own very strong opinions. I think we did a good job in rolling out a Node product, kind of replicates our success with Rails. But in doing so, what we had to do was we had to put them into containers. We had to look for a solution that we could just get this whatever framework of Node that is, put it into a container that fits its own opinion, and then take anything that’s outside of the container. And why our Node product is not as popular as our Rails product, primarily because the popularity is moderated by the popularity of the underlying frameworks that it supports. We stumbled upon by accident almost the same way that we stumbled upon the Rails product, we found that containers can help a lot of our customers bring in pretty much anything they want.
So then you went on to rolling out our container product what we called Maestro. First version of a Maestro product which basically says, bring your code, you can tell us how to package it into a container, then we build the entire stack that you need to run this container in production, whether it’s storage, networking, firewalls, load balancing, everything that you need to get these containers out into production. That product became really popular. That is back in 2014 where we rolled this out. Back then, there was a big fight, as you can imagine, was going on with the two other non-Node, but yet still popular and somewhat controversial frameworks. There was Kubernetes, which was this project started by Google and they were trying to dump it onto a company called Docker. And Docker was not taking it. They were very excited about another thing they were working on called Swarm.
Then you had an open source project called Mesos and it was a company called Mesosphere that was trying to do their own thing. That was bigger than containers. It was about everything. I would say about maybe six months to a year later, HashiCorp rolled out Nomad, which was supposed to be the replacement for Kubernetes or something similar to that.
We looked at pretty much all of those. Obviously, all of them at the beginning and somewhat we decided that from a technological point of view, from a support point of view, it’s best for us to bet everything on Kubernetes. I think that was the right decision for us. With hindsight, we cannot claim that much credit for it. Back then, we did that based on technical merit. We didn’t know about the politics behind it, but somehow we were right. So, we replaced the engine in Maestro, which was homemade. We built the whole thing because, again, back then, there was pretty much nothing in common with Kubernetes. And that became Maestro version two.
After the explosion of all the containers and Kubernetes and everything else, we’re consolidating around putting Rails on top of Kubernetes. The past seven years kind of yielded into this consolidation of the very first product that we had on top of all the experience that we gained from Kubernetes and containers and all of that, with a flavor that delivers you the Node.js experience that everybody’s talking about. While React and Vue, well… those products are not in the picture anymore.
Kubernetes’ winning combination
Darko (19:13): How do you see that space in Kubernetes being the winner right now?
Khash: There are lots of good things about Kubernetes, both from a technology point of view. But I think when it comes to a winning technology, it’s not that much about the technology, but about what’s around technology. If I wanted to kind of step back and have a look at what we did, what everybody else has done, and what made Kubernetes win, there’s a lot of different things around it. A bunch of it is around the open-source nature of it. And not just the fact that it is open-source, but fact that the company behind it doesn’t make money directly from the project. If you look around the most successful open-source projects that you see are the ones that the biggest company behind it is not the one that makes direct money from it. And that was the sort of winning combination because you don’t have the commercial forces around that. It’s not open-source as a marketing tactic. It’s open-source because it just deserves to be open. And Kubernetes was one of those. There’s a lot about the design and the way that it looks at infrastructure. The way that it has a descriptive approach to infrastructure as opposed to a prescriptive approach.
And the third best thing about Kubernetes that happened was the governance. The way that Kubernetes put a very iron grip through CNCF, which is this cloud native foundation that they have. And through Google’s force to make Kubernetes a unique and uniform experience. Having certificates for the vanilla upstream Kubernetes. You don’t have multiple flavors of Kubernetes. So, even if Amazon rolls it out, they have to roll it out the way Google rolls it out, the way Microsoft Azure roles it out, the way DigitalOcean rolls it out. And that’s another great experience for people because you learn once and you apply it multiple times.
So, these are the good things about it. Bad things about it are not necessarily Kubernetes’ fault, but it’s just the nature of the beast. It’s a very complex piece of technology that is trying to revolutionize not only the way infrastructure runs, but also the way development is happening. You don’t just say, “get your code in this Kubernetes,” as we used to just put it into VMs.
Working with infrastructure on Kubernetes or containers makes a big difference in the way that I work as a developer. And what this means is that you have this new piece of technology that doesn’t just need buy-in and adoption from ops guys, but it needs a lot of buy-in from developers. What it has turned out to be is that because it’s so complex and it needs so many different people working together in harmony to make it happen and use it and benefit from it, apart from just the ego exercise for some CTO who wants to roll out Kubernetes, is that why consultancies thrive in a situation like this.
Well, I would say any company that is building a product that is around Kubernetes and is successful with one exception, security. Security is the only area that you can make money from Kubernetes because fear sells. You don’t know what’s going to happen. And when something happens, you can always say, “Well, imagine what would have happened if you didn’t have us.” So, you kind of end up with this kind of, you’re going to have to buy it just because if you don’t, something happens and your head’s on the stick.
What makes a business succeed or fail
Darko (29:03): Because of the ego of CTO, they want to deploy the Kubernetes. And to be honest, I also see that relatively often when new companies want to introduce technologies and there is in each, let’s say, technology stack, there is something which is shiny and looks the best. Maybe you have to say something about this area.
Khash: You’re looking up to a company that’s doing really well when it comes to engineering. There’s one thing to look up to and aspire to exactly what they’re doing as opposed to, what are the driving factors behind it? A lot of us, small companies or developers, we look up to Netflix, Spotify, Facebook, Google, multimillion, billion, trillion, sometimes, dollar companies. And we look up and say, “Oh, they’re running React. Facebook is running React, therefore…” And you might be able to pull it off. Good on you. But more often than not, what’s going to get you success as a business is not React.
It doesn’t matter if you use React or Kubernetes. What actually helps you is the simplest things ever possible. And that’s not about technology. It’s about how people behave. It’s like cybersecurity. What’s the most vulnerable point in your login? People just giving up their passwords for a chocolate. It’s like, “Whatever you do.” The weakest point is always something that, as developers, we are blindsided too because we are very much focused and obsessed sometimes with technology. And it’s the same thing. You use these technologies that are built for large companies doing great things at a scale that is nowhere near what we are up to, that’s great, but it’s not always in the best interest of what you want to do as a business
Darko (37:58): Khash, thanks for sharing all these. There is a lot of information and a lot of knowledge, but they’re also that wisdom part. Good luck with your product and the company!
