How we launched KaaS in the Reg.ru Cloud
At Reg.ru, we closely monitor trends in cloud computing and strive to provide our clients with stable and reliable services.
We use both databases and Kubernetes throughout the company, but in the context of a public cloud, these services have a special set of requirements. That is why we first launched DBaaS internally, and then for clients – this approach allowed us to meet our own scaling needs and at the same time test a number of solutions carefully, in isolation, collecting all possible rakes.
We have previously written about the structure of the DBaaS service, and now we will tell you about the next service in the line of platform services – KaaS.
Text navigation:
→ Where Kubernetes Will Grow and What We Will Do
What is KaaS
KaaS is a new product from Reg.ru Cloud, designed to provide customers with the ability to run distributed applications in containers without worrying about the fault tolerance of each individual instance and using all the latest development, testing and deployment technologies. There is no connection to any vendor solutions, since our service is 99.9(9)% built on the basis of free solutions. For customers, this means simplicity and ease of migration from Kubernetes deployed on their own or from another cloud provider.
The key feature of KaaS is a managed service, i.e. we take care of all the deployment and maintenance, monitoring of Kubernetes itself and its scaling, and the client gets a cluster ready for immediate use in three clicks. You no longer need to spend your time and energy preparing the infrastructure, within a few minutes the configuration will be available, which can be added to the CI/CD pipeline, for example, in GitLab, and you can start deploying applications.
In Runiti (not only in Reg.ru), we use Kubernetes almost everywhere, following the practice of eat your own dog food, that is, we try to launch services like KaaS inside the company first, and only then scale them to clients. Thanks to this approach, we unify platform solutions, get the opportunity to collect feedback from a larger circle of users and test cool features inside. It turns out that, in essence, our internal customer is the same business customer as other clients. And thanks to this, among other things, we can ensure the speed of launching services in the cloud and reduce service support costs, which ultimately turns into a benefit for the client.
Kubernetes is a mature and established solution on the market that allows you to place a large number of containerized applications on one virtual machine or physical server, isolated from each other, while maintaining all security measures. Applications can be unrelated either in terms of the network or in terms of the process namespace. Containers also allow you to easily scale applications. You can run multiple copies with an external database and get a fault-tolerant service: if one copy of the application fails, nothing will happen globally – the rest will continue to work, and our cloud balancer will automatically redistribute the load.
Almost any cloud is built on the pyramid principle, where at the lowest level there are solutions of the Infrastructure as a Service (IaaS) type, including the allocation of infrastructure resources, networks as a service, data storage services, services for the allocation of computing power and a number of others. In Reg.ru, IaaS is represented by virtual machines and networks based on OpenStack. Storage services are divided into Object Storage (for storing objects) and Block Storage (for virtual machine disks). Depending on the type of storage, they can be represented by different solutions: from local disks on hypervisors to our own developments – here I will hold back spoilers for the upcoming announcements of services being launched 🙂
The next layer of the pyramid is Platform as a Service (PaaS). Platforms allow using tools for building higher-level entities on their base. This level is currently represented by DBaaS and KaaS, but other services will be added in the near future.
At the very top level is Software as a Service (SaaS). This is where specific applications are located, such as GitLab, WordPress or any other software used by the end user and provided on a service model. This level is represented by an impressive, regularly replenished and updated list of images from which a ready-made application can be deployed.
How KaaS works
Remember the joke that Kubernetes is just five binaries? In fact, Kubernetes is quite complex in terms of requirements that must be met for its deployment while maintaining configuration flexibility. And in order to provide it to customers with high quality, it was necessary to carefully work out a number of details. One of the most difficult tasks is launching traffic into the application cluster. It would seem that everyone already knows how to do this, but if we are talking about a cloud service for the market, the task becomes much more complicated.
KaaS largely inherits the developments of DBaaS, using the Cluster API to ensure ease of deployment and scalability of client clusters, allowing you to launch almost any number of them.
Although it all sounds so simple, the path to creating this product was certainly not easy: we
tried and failed, started again. Three times almost completely
were reworked in search of the right approach for delivery and scaling. The key
the idea was to try to avoid being locked into our own development – just for
further availability to customers and maximum possible reuse
selected Open Source solutions.
Where Kubernetes Will Grow and What We Will Do
First of all, this is, of course, the development of the KaaS service itself. We plan to expand the capabilities for managing network traffic and storing data within the cluster. As our statistics show, this is extremely important for our clients. In addition, we are going to create new services based on Kubernetes to expand the PaaS and SaaS product lines. These are, first of all, new tools for ensuring development, data storage services and providing new opportunities to our clients.
All this is done so that clients can easily scale their services and applications without going beyond the boundaries of the Reg.ru ecosystem, receiving a single interface for interacting with the platform, single support, documentation and guarantees of availability and reliability of services, not to mention the close integration of services with each other.
A little about the team
Since the creation of the cloud services department, we have been able to assemble a very strong team, but its key feature is that these are people who are passionate about their work and are genuinely interested in and developing technologies.
We divide the entire large platform team into three, based on specialization:
Operations team. This is where they support services, respond to monitoring, deploy new services and scale them. These are people who know everything about the company's infrastructure and skillfully launch platform services in it, they always keep their finger on the pulse and know about all the key changes, closely communicating with the next team.
Architecture team. This is the development of solutions, market research and implementation options for features – ours or third-party ones. The team essentially finds solutions suitable for our goals and objectives from the entire variety of solutions on the market, describes how to prepare them, what needs to be developed and what to wrap them in to get that very platform service that can be used equally both internally and for external customers.
Development team. It deals with integration and infrastructure solutions. The task of this team is to implement everything that the Architects have come up with and transferred for development. These can be either some integration layers, for example, an API for implementing user scenarios for working with Kubernetes clusters, or complex solutions that are represented by dozens of components, for example, a backup service.
All three teams have common goals and work closely together, communicating constantly and planning their work periodically, discussing the challenges they face and looking for joint solutions.
Next time we will tell you about the architecture of our solution. Igor Shishkin was with you, thank you for your attention and see you soon!
