Evolution of Backend as a Service: The Second Coming of Scorocode

    Hello, Habr.

    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:


    1. Resources were all flipped between applications, and it was impossible to get a guaranteed resource, which in our time already looks at least strange.
    2. There was no mechanism for launching a full-fledged node WEB server;
    3. As it turned out, for most of our clients, NoSQL MongoDB is not needed; instead, everyone asked for relational MySQL / PostgreSQL.
    4. 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.

    Tags:

    Also popular now: