How we made our Heroku-like cloud
Perhaps you had (or have) a need to deploy your IT project, be it a simple bot, website, application or a complex high-load service. And you may have used AWS, MS Azure, or other public cloud providers for this.
Then you know that in order to use such cloud solutions, you need to have very “deep pockets”. So, to deploy a regular speech recognition service for 20 streams, you will pay Yandex for virtual machines and for a DBMS 43,500 rubles. per month (calculated based on our ASR). And it’s still quite simple, albeit CPU-intensive service. It seems that cloud services should be more affordable from a financial point of view.
In this article, we will tell you how we made our cloud, what we encountered, and what happened in the end.
The idea of making your own cloud for business appeared a long time ago, but up to a certain point it seemed crazy to compete with IT giants. Everything changed in February-March 2022. It became clear that at least Western competitors were leaving the market, and companies remained on the market, albeit strong, but not covering all niches. The idea arose to try to ride the trend of import substitution. The plan looked attractive: to do a new, ambitious project in the PaaS market, which growing by more than 20% per yearincluding replacing classic data centers, and from which, at the same time, part of the competitors leave.
First, we did a small CustDev to better understand the pains and needs of the customers. Our survey included specialists who deployed services in public clouds both for their companies and for third-party customers.
CustDev summary (sometimes obvious, but useful nonetheless):
CustDev question #1. Why do programmers choose clouds over iron servers or virtual machines?
The main answer of the respondents is that there is no need to administer DBMS, servers, etc. on your own. This frees up the work of qualified developers. People want to invest their resources in working on a product, not in administering the environment for it.
At first, we thought the cloud was the choice because it could be cheaper for the customer due to cheaper space during peak times. But this hypothesis was not confirmed.
CustDev question #2. What are the criteria for choosing a particular cloud?
The most important thing is the availability of all the necessary services.
The second factor is the price. When choosing a cloud, consumers compare solutions with each other in terms of price. It is also important that education be transparent. There was a comment that AWS has non-transparent pricing.
The third is compatibility. It is important that all corporate services can be deployed in one cloud infrastructure and do not have to come up with “crutches”.
Our hypothesis that high-quality technical support is important was not confirmed. According to customers, support is not needed if there is clear documentation and the cloud is stable.
CustDev question #3. Services you really need
Our interlocutors mentioned virtual machines, storage, DBMS (including MongoDB) as a service, DNS, queues, Kubernetes. More rare cases were also mentioned, for example, different identification / authentication.
CustDev question #4. For what purpose is it used
According to respondents, these are backups, short-term projects (when you need to quickly deploy the infrastructure and, if necessary, quickly change everything), hosting the current infrastructure.
CustDev question #5. Distribution Features
From the survey results, we found out that clouds often “sell” various outsourcing companies to their customers.
After CustDev, the technology stack had to be chosen. The open source project, OpenStack, seemed to us the most promising. But not everything that seems optimal at the beginning is so later.
Even during interviews with potential customers, OpenStack was spoken of as software that needs to be “finished” a lot, dances with a tambourine are required, and it is quite difficult to administer it.
And that was exactly what we encountered. OpenStack, despite the developed community, documentation and other advantages, is really not the friendliest project. Some errors occurred for absolutely incomprehensible reasons for us, and, most importantly, we could not find documentation and examples of solutions for such cases on the Internet. Of course, there was nothing insurmountable. It’s just that such errors required too much team time and created a threat that during commercial operation critical situations could arise that could not be quickly resolved.
You also need to remember that by building a solution on OpenStack, you become dependent on it. The trajectory of your development will be based on the development paradigm of OpenStack itself. Namely, regardless of your own vision of the system, you will have to use OpenStack services. If its support by the community stops, you will either have to develop and maintain these services yourself, or switch to another platform. Although, in terms of functionality, OpeStack closes 90% of tasks for the public cloud.
As a result, we decided to abandon OpenStack, no matter how painful it was.
Having discussed the current situation – we actually do not have a ready-made open source foundation for building a public cloud – we decided that we need to enter the market not so “head on”. Classic clouds are a disruptive innovation for data centers with their own iron servers. What if we try to disrupt the traditional virtual machine hosting market first? Yes, the check is small, but there are more potential customers. Plus, you can make the cloud solution really affordable for users!
And I personally remember one phrase during the interview – “Why do we need virtual machines if there are containers?”. This statement is not entirely correct. Because there are tasks for which virtual machines are better suited. But this statement at that moment lay on the fertile ground of our reflections on a change in strategy.
And, indeed, containers have a number of advantages:
– Consume little hardware resource due to the fact that many software things are reused at abstraction levels. There is no need to deploy the conditional OC 100 times for each of the containers. More applications can be deployed on the same physical server using containers rather than virtual machines.
– Reliability. If your container crashes, the Kubernetes container orchestration system will simply automatically restart it, and if you use duplication, you will not notice the failure of your applications at all. This is true for virtual machines as well, but with a high probability you will have to restart the entire service, and not a single module.
– Scalability. Horizontally scaling your services is easy – you just need to add another container, and the load balancer itself will distribute tasks between them. This is also true for virtual machines, and the main thing here is that for containers there is such an opportunity and it is carried out quickly and simply.
Considering the advantages of this approach and our own experience in using cloud services, it was decided to make the cloud based on containers.
Luckily, the days of Heroku writing their own containerization solution are gone. The well-known Docker and Kubernetes were chosen as the base.
Additionally, to improve the convenience of the service and user experience, the deployment functionality was implemented by simply pushing a dedicated GIT repository to the master (yes, we spied on this mechanic from Heroku). After all, it is important for developers to focus on the code, and not on infrastructure administration.
As a result, by October 2022, we have made a cloud based on containers, in which it is easy to scale the infrastructure, and it is also possible to roll out updates via push to the GIT repository. It is worth mentioning that so far we have implemented only the basic part, and the cloud is not suitable for any projects. Namely, if you have a complex project that needs a DBMS in a cluster, this is not for us yet. But if you need to host a website, a bot, a small application, or something similar that can be wrapped in a Docker container, then the solution may suit you.
PS We invite those who wish to participate in a closed beta test our cloud platform Amverawhich we are running from October to December 2022. It’s free. To participate in the free beta test, you need to register in your personal account Amvera. After registration, 1 tr. will be automatically credited. to use the service. If you have a highly loaded project, write to us and we will allocate additional free computing power as part of the beta test. We promise that after the end of the beta test (January 2023), the service will be no more expensive than a simple virtual machine if you want to continue using it.
Link to free computing power for your project: https://amvera.ru/betatest
We will be glad if you leave feedback and, thereby, help to make a really useful and convenient service!
