(Special cPanel Edition) – It was early 2009 and I needed a new project. It had been four years since I sold PSOFT to Comodo and I felt the need for change. Comodo had been increasingly focused on desktop security, a subject of little interest to me. I needed something new, highly technical and something I could get excited about. I needed a project I could call my own.
While I never had issues working for someone, I always enjoyed working on my own projects so much more. I could start from scratch and watch them grow. Once I realized it was time to move on, I spent some time just thinking about the next project. I knew it had to be technical and unrelated to security. I had spent the last 15 years working and developing in Linux or various flavors of Unix, so Linux kept appearing on my list of possibilities.
My first choice was an application store for Linux. The app stores were all the rage back then. With the Apple app store and Android app store gaining prominence, it seemed that a Linux app store was conspicuously absent. Buying third-party apps for Linux wasn’t that simple, so I thought, “Why not?” However, after talking with a few people about it I began to see that the idea was really limited. The desktop Linux market was just too small and fragmented. Yet as the idea of doing an app store faded from the forefront, the idea of creating a distribution for hosting providers started taking shape.
Having spent 10 years developing solutions for the shared hosting market, along with15 years of Linux experience, I had a solid grasp of how the market worked. I also knew that most existing distributions didn’t understand, or didn’t care what shared hosts really needed. There were plenty of desktop distributions, quite a few enterprise distros, security targeted distributions, distros aimed at the education space, DIY, media, and embedded…you name it. Yet, there was no Linux for shared hosts.
It was surprising! The needs of shared hosts were clearly unique in that no one else was allowing hundreds of people with no real vetting onto their servers. I had a clear idea of what shared hosts needed; better security and better stability. Of course everyone needs that, but stability and security for enterprises is not the same as that required by shared hosts. Enterprises don’t have to deal with rogue programs running on their servers, executed by valid users, nor do they have to deal with poorly written software regularly changing without prior warning. I thought, “Hundreds of customers sharing the same server with no effective controls,” this was the problem I would address.
So I started talking with people again. I had a lot of contacts within the business and I reached out to as many of them as possible. I spoke with people at cPanel and Parallels. I spoke with the owners of about 30 different hosting companies. The idea was met with interest, and frankly, some skepticism. Everyone saw the need, but most believed a new distribution such as what I was proposing could not survive. I knew there would be hurdles to overcome such as vendor support, adoption, resistance to change, and perhaps the most difficult of all, asking people to pay for something that they were accustomed to getting for free.
No matter, I began to write a business plan. It took about four months before I had something that I could believe in. I conducted an extensive market review, and given the current market share of CentOS/RHEL based distributions in the hosting market, I decided to base CloudLinux on RHEL. I felt that if we were to be accepted, it was important that people were as comfortable as possible with new OS when they made the switch. My goal was to deviate as little as possible from RHEL and I believe we achieved that in CloudLinux. Additionally, we wanted to assure that updates would be timelier than CentOS. Our sales strategy was taking shape.
I knew vendor support would be critical to our success. I could develop the best OS possible but if cPanel didn’t run on it there would be little interest from the hosting industry. cPanel had to run on CloudLinux from day one, so making the switch to CloudLinux would be as seamless as possible.
So that is how it started. By September 2009 I had a business plan and had hired a talented kernel developer. I had worked with him before at PSOFT and knew what he could do. His work exceeded even my high expectations and in a few short months things were taking shape. We keenly focused on developing an OS that would transparently limit CPU usage on a per account basis. Other resource limits would follow.
By November 2009 the company was fully operational; we had 5 people working on different parts of the system. By January 2010 we had our first alpha version and started to engage vendors and potential customers.
Initially the reception was lukewarm. Sysadmins showed little interest in trying it. They had production systems to run and introducing a new OS into the mix was something they were not keen to entertain. For most of them, dealing with abusive accounts was de rigueur. I suppose it was the known devil vs. the untested one. Load spikes and abuse were routine. It was the way it was, and the way it would always be. They just didn’t believe that anything could be done about it. It took a lot of persuasion to get anyone to give it a try but we remained confident and persevered.
We surveyed hosting providers to identify the primary cause of downtime. We asked about hardware and software upgrades, security-related incidents, hardware failures, network failures, and others, as well as excessive resource usage by a single customer. The latter proved to be the number one reason for downtime by a wide margin. We were solving the right problem! We just had to let people know.
The software was fairly raw back then, but it worked, and it worked well. The early adopters proceeded very cautiously. We released our first version at the end of February 2010. By the end of March CloudLinux was running on no more than twenty production systems. Yet it was a very important twenty. They offered a lot of feedback and I am grateful to them. The conversion process was simple and that worked in our favor. We further perfected our conversion scripts, making sure that hosts can roll back to CentOS easily if needed. Vendor support was still an issue. Due to the high level of compatibility between RHEL/CentOS/CloudLinux, all of the major control panels would work with us out of the box. R1Soft & Ksplice, however, work at kernel level and they had to agree to support our kernel. Luckily, we were able to persuade R1Soft to support us from day one. It was an important win for us. Then LiteSpeed embedded our resource limitation technology into their webserver and Ksplice started to support our kernel for their rebootless kernel update product.
By winter we had more than 400 servers running CloudLinux. By the end of summer we had close to 1000 productions servers running CloudLinux worldwide. We added more and more servers each month. We worked hard to improve our technology, adding memory limits, a web based UI to simplify management, and better statistics, all while polishing our existing technology to make sure it worked flawlessly and required little if any maintenance.
The next chapter in the CloudLinux story is improved security for shared hosting. We are adding tools which will help assure that a shared hosting customer’s files are the only files on the server visible to that customer. I feel this is the next logical step moving forward as we continue to focus on our primary objective: Developing the best operating system possible for use in a shared hosting environment. The world may not have needed a new Linux distribution, but it seems that shared hosting companies surely did.