1. What I Am Thinking About

At a big company, you get more opportunities to learn about industry trends and take part in industry change.

A large platform does not run on the strength of one person or a few people. If it really could, it would not deserve to be called a large platform. One person to a post, each with their own division of labor, coordinating with one another — that is the modern way to manage.

When a platform does well and gains influence, the individual gains something too. But it is easy to fall into a cognitive trap: mistaking the platform’s capabilities for your own. In reality, you are only responsible for one small module. If you do not proactively learn, think about the platform’s architectural design, and recognize where the value density lies, then the platform’s capabilities have nothing to do with you.

I am very fortunate to have had the chance to take part in a ToB IT infrastructure technology transformation. While the platform product was succeeding and gaining influence, I kept thinking about where the platform’s core competitiveness lies, and how to keep expanding and export that influence to other industries. The following is my answer to those questions.

2. Characteristics of SaaS

SaaS is internet software that directly provides services to users in a way that is always reachable. Common SaaS products include online email, note-taking, office suites, CRM, ERP, and so on.

2.1 From the Product Side

Multi-tenancy. SaaS is usually a single piece of software serving all users. The multi-tenant model compresses the SaaS provider’s operating costs. But to keep tenant data safe, the data needs to be isolated. Different tenants use different database instances, or the data is filtered through a foreign key on the tenant ID.

Customizable. One general-purpose SaaS cannot satisfy every customer’s needs. SaaS providers usually offer some configuration for customers to use, and may even do custom development directly for a customer.

Enterprise-oriented. Although there is SaaS offered to individuals, SaaS mainly targets enterprises. A ToC SaaS has difficulty charging money and usually can only earn a certain amount through advertising. A ToB SaaS is born with a profit-making gene and can easily break even. This is because SaaS usually provides tools and productivity services, and enterprises are more willing to pay to improve production efficiency.

2.2 From the Development Side

High quality requirements. When a ToC product has a problem, you can only complain through official channels, and then it fizzles out. But ToB is different. The enterprise will go to after-sales support, and if it is not handled well, it will directly affect whether the partnership continues.

Stateless. In order to scale out horizontally and meet tenants’ ever-growing performance needs, SaaS should be stateless. By deploying SaaS instances on multiple machines in different locations, the access requests of different tenants can be shared. Caches, persistence, message queues, and other state are all stored as clusters that provide services to the SaaS.

Development framework. SaaS needs a unified development framework. The common modules provided by the development framework can reduce the amount of development, lower the learning cost, and speed up custom development.

Functional APIs. Through API calls, the boundaries of SaaS capabilities are expanded. Sending notifications, online payments, querying geographic location — if SaaS had to implement all of this itself, it would consume a large amount of time and still could not guarantee quality. So the platform the SaaS depends on should provide the corresponding APIs. These APIs directly affect how sticky the SaaS is to the platform.

3. Why Use PaaS

For the past two-plus years, my main job has been SaaS development, and I have also taken part in a little PaaS development. It is more fitting for me to describe what PaaS can bring from the perspective of a consumer.

Development framework. As said above, to improve development efficiency, SaaS developers need a development framework. But the development framework provided by PaaS is actually mainly meant to solve the problem of consistency. When PaaS deploys, it compiles and packages the SaaS, and the SaaS has to tell PaaS some necessary information, such as environment variables, log format, startup parameters, and so on.

Stateful services. Because SaaS is stateless, PaaS needs to provide public services such as MySQL and RabbitMQ, and between different SaaS products these services are isolated and invisible to one another.

API SDK packages. Through an enterprise service bus (ESB) or a gateway (API GATEWAY), PaaS provides a large number of third-party services. If developers call APIs directly through HTTP requests, it is easy to get parameters wrong. The API SDK package approach wraps the remote API as a local function call, which is friendlier to developers.

Compile and deploy services. After committing code, the whole CI/CD process can be completed with the click of a button.

Monitoring services. PaaS provides monitoring services such as log querying, and process and service monitoring. These metrics are usually what developers care about, used to locate problems and optimize performance.

Enhanced services. Basic monitoring services are usually non-intrusive and have no impact on SaaS, but their functionality is weak and cannot meet development needs. In that case, enhanced services can be used, such as Sentry, APM, Ceph, and so on, which need to be configured before they can be used.

It is precisely because PaaS provides these public services that SaaS developers only need to focus on the code and implement the functionality. What PaaS brings is an overall improvement in development, operations, and business efficiency.

4. How to Migrate PaaS Across Industries

SaaS can connect to scenarios and is directly tied to revenue and cost. But if the scenarios cannot be narrowed down to few enough, PaaS would be a good solution.

The image above is a general-purpose PaaS solution.

For PaaS platforms, Gartner divides them into two categories: one is the application deployment and runtime platform, aPaaS (application platform as a service), and the other is the integration platform, iPaaS (integration as a service). When people talk about PaaS platforms, they basically mean aPaaS, such as Force and Google App Engine. It has even spawned a large number of container-as-a-service companies that directly provide container deployment services.

I believe the core value of PaaS lies in the iPaaS layer.

In the PaaS technology transformation I went through, at first we deployed with local directory isolation, then switched to Docker + Slug deployment, and now we directly use K8S + buildpack deployment. In fact, these mean little to SaaS developers and users. Instead, it is the PaaS developers who gained more: the platform is easier to maintain, resource utilization is higher, and it aligns with industry standards, and so on.

The aPaaS layer is heavily commoditized. A good aPaaS can be used across all industries. I even think the aPaaS layer can be connected with DevOps — aPaaS can simply execute the DevOps process.

But the iPaaS layer is different. iPaaS is a layer dense with domain knowledge.

In the operations domain, configuration management and job execution are concepts only operations people come into contact with. iPaaS needs to abstract them into products and provide services externally through APIs.

In the e-commerce domain, iPaaS provides platform services such as payment, logistics, and product management. These subdivided domains require professional people to abstract and make them compliant, and in the end they export the domain capabilities to the SaaS layer only in the form of APIs.

Being able to effectively transmit capabilities that require long, high-intensity training to master, through iPaaS, to SaaS developers and customers — that is the core competitiveness of PaaS.