Every cloud service consists of several components. Therefore, the functionality accessed by the end user is just the tip of the iceberg. There are also a lot of infrastructure-related features that are invisible to the users but crucial to getting the solution up and running. Under the hood of the cloud service Registration of a new tenant of a cloud service is a perfect example of such a feature. If we are talking about a CRM system or accounting software, the user cannot just log in to the system. Usually, before this, they land on a website, sign up for the service, confirm registration via email, log in to the site, choose a pricing plan, pay for it (or chose a free demo plan), and finally get to the application. Once the plan is chosen, we need to create a tenant for the user within which all interactions with the service engine are performed. This tenant entity should be filled in with the relevant data. Several user accounts may use one tenant, so if the tenant admin wants to open such access with different permissions, we should enable them with the features to do it. All these things like registration, premium plans, backup scheduling or data sharing with access management have nothing to do with business management or accounting. However, they are essential for the overall user experience. Why this is bad For the developer this means thousands of lines of code to write aside from programming the solution itself. Managing the infrastructure-related features often takes more time and resources than writing the code for the core cloud service functionality. We have experienced this ourselves while working on the cloud software. The development team was finally split into two different groups — one continued developing the core functionality while engineers in the second team dedicated their time to the support of front-end solutions like billing and registration modules. AccountingSuite Such an approach leads to a number of problems. One of the biggest is inconsistent development. Back-end development requires the use of different platforms, programming languages and frameworks which are utterly different from the tech stack used for the development of the core functionality. This is inefficient, and the distance between the core stack and the infrastructure grew continually. How to fix this problem What if we could create features for both the core service and its under-the-hood components simultaneously using the same technologies? It would save us a lot of time and resources. This is why we decided to implement this approach in reality. To do this, we have introduced a new entity to our infrastructure. It is called the Service Manager, and it is a database of all infrastructure-related data for the specific cloud service. We store there the number of tenants of this service, a list of the users with their permissions, payment details and subscription information, and so on. This database is developed using the platform. Using the Service Manager we can register new users, send them email invitations, apply a different set of databases/configurations for each user, etc. 1C:Enterprise So, we have finally moved to designing the cloud service’s server side using the same technology it was built on. The Service Manager tells the cloud app what degree of access each user should have or when the access should be terminated. Final thoughts The first advantage of this approach is the reduction of the overall number of code lines written. If you already have large chunks of the server-related code that you can apply to the new cloud app, it makes everything much easier and faster. The second advantage is flexibility. Using the same tech stack for the front-end and back-end parts allows you to make maximum use of functionality.
