Regarding SaaS and Serverless, I believe that many readers who follow me are no longer unfamiliar, so this article will not talk about their technical details, but will focus on how much SaaS software can be brought to our SaaS software after Serverless is introduced into the SaaS software architecture. income.
Before starting the following content, you might as well give yourself half a minute to think about it: How much improvement do you think the introduction of Serverless will bring to your existing SaaS software architecture?
Let me talk about what most people can think of: thinking from the perspective of serverless simplification of operation and maintenance, standing on the operation and maintenance side of the software platform can reduce the complexity of operation and maintenance. This benefit is obvious. I only thought of this at first. It was not until I watched several lectures on SaaS architecture and Serverless in AWS re:Invent these days that I had some higher-dimensional thinking.
Let's take a look at what kind of sparks can be sparked when encountering Serverless in SaaS.
background
The development of SaaS software and serverless services in the country has always felt like a difficult brother. Although they do different things, their current user status and dilemmas are very similar.
Status: Similar user groups
At present, there are many SaaS companies in China. I am a user of SaaS software and a developer of SaaS software. I also subscribe to some useful SaaS (for example: online drawing tool ProcessOn, online form gold data, etc.) . Most SaaS software is based on the realization of low-threshold general functions, and it is very rare to have high-complexity function support. Because of this functional restriction, their main customers are currently mainly small customers, concentrated in start-up teams, small companies, and even individuals.
The status quo of Serverless in China is also very similar. Because of the promotion of serverless services of a certain factory before, start-up teams and small companies are more easily accepted at present. Because Serverless simplifies the understanding of the direct benefit of operation and maintenance, it is easier to be understood, recognized and accepted by everyone (including myself). Therefore, it will be a better breakthrough for teams or companies with weak operation and maintenance capabilities. Naturally, the user group also falls into small teams that lack technical capabilities or lack human costs.
Dilemma: Similar
Since SaaS and Serverless have similar user groups, their anxiety is also very similar. The characteristics of this user group are the core of the current manufacturer's anxiety: paying high, and the willingness to renew is generally . At this stage, the main means to solve this anxiety is continuous marketing growth, so we will always see a lot of new promotions or renewal promotions. However, no amount of marketing activities can change the nature of this anxiety, especially after more competitors of similar products appear, such pressure will become more and more obvious.
Therefore, in order to make breakthroughs, everyone has begun to focus on the blue sea of large customers. Medium- and large-scale enterprises may have strong spending power on software and infrastructure and renewal fees may be much higher than start-up teams and small enterprises. Several major customers reside on the platform, which is very beneficial to the long-term development of SaaS and Serverless service providers. The goal is very good, but it is not easy to support the entry of major customers, so there is a question that has been hotly discussed: , the cake of major customers, should I eat it? How should I eat ?
The nature of the difficulty
SaaS Difficulties
Why is it difficult to push SaaS software to large enterprises? There are many reasons for this. For developers of SaaS software, the needs of large customers are more complex, it is more difficult to implement, the cost will rise sharply, and the complexity of the architecture will also face huge challenges. At the same time, big customers still have the biggest worry about the business running on the SaaS platform, which is the SaaS .
If you are a heavy user of the SaaS platform, you must have encountered these problems: the failure of other tenants has affected your functions, and the upgrade of the platform version directly hangs up your service. Why is there such a problem? In fact, the essence is still the current domestic SaaS software goals and architecture design reasons. Since the initial goal is to serve small customers, in order to save costs, make good use of the scale effect, and obtain higher profits, a large amount of functional support is in the shared resource pool, and all tenants The use of may cause mutual influence. And the essence of the problem is that tenants does not meet the requirements of large customers , so if you want to broaden such customers, you must increase the level of tenant isolation architecturally.
Serverless is difficult
When Serverless is introduced to large customers, the difficulties faced by SaaS software are not the same. Since Serverless directly improves the efficiency of operation and maintenance, and large enterprises often already have mature operation and maintenance systems and team support, whether the introduction of Serverless can really bring improvements is actually not easy to say, because it is considered from a more comprehensive implementation perspective , Which also contains a lot of costs and risks that are easily overlooked, such as training. If it is based on the existing mature system to replace it is generally more difficult to promote. This is just like the fact that mobile payment is difficult to become popular under the well-established credit system. Therefore, for serverless to be accepted by major customers, it is necessary to find a more painful entry point to impress customers.
New ideas for SaaS + Serverless
After talking about the respective status quo of SaaS and Serverless and the difficulties of major customer applications, looking back at the combination of SaaS and Serverless, what kind of sparks will it bring?
First, let's take a look at the introduction of Serverless in SaaS. In addition to improving the efficiency of basic platform operation and maintenance, we try to shift our attention to the isolation of tenants of major customers. Does it feel a little bit?
Before the support of Serverless, how can we provide customers with a higher level of isolation? Do we need to write a lot of scripts to complete the creation of various resources, deployment of applications, initialization of data, etc.? Moreover, the complexity of such operations is directly proportional to the complexity of the system's dependence on other resources, so there are great challenges for a tenant's unique resource management (resource creation, elastic scaling, and destruction after non-renewal).
But if we use Serverless to complete the resource isolation required by tenants, the operation and maintenance level can bring great improvements, and the overall operation and maintenance complexity will not increase too much. Under this kind of thinking, we can also provide more flexible multi-tier tenant services to meet the requirements of users of various levels, such as: common tenants use shared resources to provide services, and silver tenants use part of shared resources + part of Serverless Independent resources provide services, and golden tenants adopt independent resource services that are fully serverless deployed.
The following figure shows the architecture diagram of using Serverless to deploy different levels of tenants. Tenant 1 and Tenant 2 have better isolation through independent serverless deployment. Such tenants are often higher-level paying users. However, some basic paying users still provide services externally through pooled resources.
Because Serverless has elastic scaling features, this makes the cost of all resources more economical. As shown in the figure below, when we use Serverless to build a SaaS service, the overall resource consumption can present an optimal state along with the tenant's usage.
For SaaS software vendors, building SaaS services through Serverless can not only do better in terms of multi-tenant isolation requirements, but also in terms of resource cost control. On the other hand, from the perspective of serverless suppliers, the difficulty of entering large customers may be to find an easier and faster path by providing multi-tenant solutions for SaaS software. Originally, both SaaS and Serverless faced major customers with a certain degree of difficulty, but with this combination, does it feel like it’s difficult for both brothers and sisters to bring major customers home?
How to build SaaS software through Serverless
Since it is so cool to build SaaS software through Serverless, what should we do? Several very instructive reference solutions were also given in the keynote speech of this conference. Among them, " in-depth exploration of the internal principles of the SaaS reference solution 161b2ecf87940a" topic has an example of using Amazon Lamdba to build, the following is a disassembly of the tenant creation and isolation resource creation process that everyone is most concerned about.
Let's take a look at the architecture diagram of this reference solution:
The Control Plane in the figure is the control center of the entire SaaS system. It is responsible for managing tenants, users under the tenants, and the resource configuration of each tenant. The Application Plane part is the core cluster for the specific operation of the SaaS business. In the Application Services part, you can see that there are two microservice clusters. This reflects the idea of isolation. You can use one of them as a resource pool for ordinary tenants, and the other Can be used as an independent resource pool for senior tenants.
Since we want to realize the resource isolation of tenants, how did this set of isolated resources be created step by step?
The above figure shows a series of detailed operations completed in Control Plane when a new tenant registers:
- Tenant configuration (determine whether it is a pool user or a silo user)
- According to the tenant type, create different user management services and create tenant administrator users
- Build tenant management service and store the tenant’s configuration
- If it is a silo user, build a unique service resource for the tenant (the following figure shows the specific process of this step)
How are the service versions and build deployments of different tenants mapped? The picture below is very clear. The table on the left records the tenant ID, code version, and stackName (I don’t know how to translate, it’s actually a different resource pool).
Therefore, through this realization, for some advanced tenants, in addition to resource isolation, software version isolation can also be achieved. This also eliminates the situation that the upgrade of the large platform version (maybe the tenant does not want to upgrade) affects a certain tenant.
The general steps of tenant creation and isolated resource creation are finished. There are some details of tenant management, user management, permission management, authorization management on API Gateway, etc. in the speech. I won’t go into details here. Interested friends can do it themselves Watch this special lecture: delve into the internal principles of the SaaS reference solution 161b2ecf8796d1 to learn more, there are some simple codes for reference. In addition, for students who are studying SaaS solutions, there is also a multi-tenant EKS SaaS solution presentation is also worth watching.
Of course, the content of AWS re:Invent is not limited to SaaS and Serverless, there are also many exciting cutting-edge content about DevOps, GraphQL and so on. Interested junior partner, can Click here to direct content Home .
Welcome to pay attention to my official account: Program Ape DD, to share knowledge and thoughts that can’t be seen elsewhere
java
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用。你还可以使用@来通知其他用户。