Evolution of Backend as a Service: The Second Coming of Scorocode
We break the long silence and announce the release of the second version of Scorocode.
This is not even an evolution, but the birth of a new service.
Year of operation, Docker, Kubernetes, Yandex.Oblako, etc.
Warning the question “Why is the Go hub here?”, I answer - all Scorocode services are written in Golang , this is the language we have in the main stack of technologies.
For details, I ask under the cat.
History reference
Scorocode v1 was launched in the summer of 2016, collected about 20,000 registrations in 3 months, was a free tool for our public audience in 2.5 years, and was used to deploy private clouds, during which 8 systems of different levels were developed: service taxi to the production management system.
In the first version, there were self-written services for working with NoSQL MongoDB DBMS , its own database request parser, services that ensure the execution of JavaScript code on the server, and all this was a single entity in the cloud.
The main disadvantages of the platform v1:
- Resources were all flipped between applications, and it was impossible to get a guaranteed resource, which in our time already looks at least strange.
- There was no mechanism for launching a full-fledged node WEB server;
- As it turned out, for most of our clients, NoSQL MongoDB is not needed; instead, everyone asked for relational MySQL / PostgreSQL.
- The cost of the starting paid tariff was high, about 3,000 rubles / month, and there was no understanding what the user was paying for.
At the end of last year, our team, having understood all the achievements and failures, decided to get involved in the development of a new version, fundamentally reworking the architecture.
What's new in v2?
The logic has not changed. There is an account in which the user who owns the account can create applications. But the structure of the application has changed. It is now independent; it is hosted on dedicated resources (in a public cloud - on a dedicated virtual server).
Assessing the work done, we understand that we have gone a long way. For the beginning, we built a basic architecture, the bricks of which are services that live in docker- containers, which, in turn, are combined into dependent groups, and they live in the subsections managed by Kubernetes. In general, all of the classics of the genre.
From ready services are used:
The next step is to write and build your own services.
Auth
Authorization service of application users using the HTTP Authorization method (type Bearer).
Broker
Service for packaging your own services (sorry for the tautology). Today it is presented in the form of a server node, in which you can deploy either your complete application with source code, or the ready-made node assembly (for more details, see the description of scorocode-cli). We are developing the service in the direction of the possibility of packing both already ready services from DTR , and self-written services. The first experiments we do, of course, on services written in golang.
DBAPI
A service that provides work on a RESTful API with all PostgreSQL database tables.
That is, as soon as you create a table in the database, all CRUD operations are available by API.
WebSockets
When clients connect using the WebSocket protocol, it identifies clients, after which you can send named or broadcast messages from the server API. We will continue to develop the service in the direction of buffering and guaranteed message delivery.
FS
Work with folders and files of the application storage.
Push
Sending push notifications. Certificates Android / iOS are attached in your account.
Console utility scorocode-cli
2 years of user experience with the first version taught us that no matter how beautiful tools were presented on the portal in the user's personal account, after a period of "pampering" the developer wants to return to the familiar environment - to his local computer. Therefore, we could not do without a console utility.
Today, scorocode-cli (binary sc-cli) provides the developer with the following functions:
fetch
Connect to the application in the cloud, authorize, save the configuration in the folder .cli.
init
Getting the repository and the deployment of the base application, followed by building and saving to the cloud. The basic application is one so far, as the hands reach - we will write a few more, of different types.
pull
Synchronization of local project files with the cloud.
push
Save local project files to the cloud.
regdb
Register a database.
logs
Getting logs from the service.
bridge
Forwarding local ports to the cloud for all services. For example, after the launch of the bridge, you can connect any client to the cloud PostgreSQL as a local one.
serve
Local launch of the application. Used for local debugging.
Problems
There were many problems on the road. And there are still a lot of them. Basically they occur at the junction of open source products. Sometimes elementary actions were poured into weekly digging and, as a result, in a pull request to the product repository. It is difficult to cram everything into one article. I hope I will write more about private problems and solutions.
Development plans
First of all we will write services. Many services. But we will not write them in the abstract, but at the request of our clients. We will also develop application templates to enable users to write less code to enable new features.
About business
We changed focus from private users to B2B market segment. And we changed the base - now we are in Yandex . Cloud . More about this will be the articles of our product Korbut . It is because of this, in the new version of the public cloud, a trial period appeared - 1 month, after which we would like to understand if the user lost interest in us, or is willing to pay for the service (the cost of the basic configuration of the application is 990 rubles / month).
About tariffs
Now we have absolutely transparent pricing. The user sees the resources allocated for his IaaS application, for the cost of which we simply charge a percentage. The percentage of floating, depending on the volume consumed. This gave us transparency of pricing and the possibility, after launching the Yandex. Oblaka marketplace, to deploy private clouds to users with tariffing in the Yandex.Oblaka personal account.
And yes, we are cautious. Considering that we give allocated resources for each application, the application pool for the trial period is small, about a hundred. First of all, we sent an invitation to our users from the old version, but for the time being we continue to accept applications for connection to the trial period on scorocode.ru
Epilogue
I am very grateful to our team, which did not lose heart even in the most dead-end situations. By the way, about the command:
- Anya Korbut ( Korbut ) - product manager
- Zhenya Khramtsov - architect, go developer
- Levan Kiknadze - architect, go developer
- Roma Gayazov - js / frontend developer
- Tagir Khalilov - DevOps
- Dasha Golubeva - Systems Analyst
And, of course, a big thank you to the Yandex.Oblaka team for their promptness, support and participation in the problems that arise.
Thank you for reading to the end. That's all I wanted to say.