1. Work Scenario

The team I am on has 20+ people and carries the responsibilities of both PaaS and SaaS development.
The people who develop PaaS, the PaaSer, are mainly responsible for developing and maintaining the PaaS platform, with the goal of providing the SaaS developers with the APIs and documentation they need.
The people who develop SaaS, the SaaSer, are mainly responsible for developing Web applications on top of the above PaaS platform, with the goal of delivering SaaS applications to users.

What connects them is the Developer Center, the development framework, the Restful-style API interfaces, and the API Gateway.

• Developer Center, which provides entry points for creating, deploying, and managing SaaS applications, querying logs, configuring permissions, getting started guides, development documentation, and so on.
• Development framework, which uses the Django framework. It mainly adapts the three runtime environments — development, testing, and production — enhances security against certain common vulnerabilities, and also integrates some commonly used decorators and component modules.
• Restful API, an important part of extending SaaS functionality. The enterprise service bus mainly connects through this, providing services for SaaS to use, and the functionality provided by components also falls into this category.
• API Gateway, based on a microservice architecture. Communication between services and services requires a gateway to control the access policy. These APIs include APIs with sensitive permissions, APIs not provided by native systems, and APIs provided by certain SaaS that need to serve outside parties. Finally, the API Gateway can also record call logs and count the number of calls.

2. Working Style

The current working style is that the PaaSer is responsible for maintaining the basic functionality of the platform, and also responsible for developing new functionality, such as login and platform components. Login issues a credential to each user, valid across the PaaS platform within its validity period. Components provide services to SaaS through APIs, such as SMS, email, and file access.

The services provided by PaaS are aimed at SaaS application developers. A clear API call logic and concise, easy-to-understand documentation are the key to the success of a platform cloud service provider. The PaaSer provides a large amount of documentation to guide the SaaSer in using the platform’s functionality.

In practice, the API functionality of PaaS often cannot meet the needs of SaaS. For example, when you need to send a verification code. At this point you would use the SMS-sending component functionality provided by PaaS, but SaaS still needs a layer of encapsulation to meet development needs. Another example: when you need to manage business permissions. At this point you would use the interfaces provided by PaaS, but they still cannot directly meet development needs.

Over time, SaaS developers start to frequently copy code they have written before — part of it encapsulation of PaaS functionality, part of it functionality that is common across the business but that the PaaS platform does not provide. This is not meant as a criticism of the PaaS platform developers for not integrating these features. I think this reflects the lack of a functionality-selection mechanism. Such a mechanism should be able to select from the SaaS feature items the functionality that the PaaS platform ought to provide. For the whole team, although what is finally delivered to users is a SaaS application, as development needs grow, SaaS development will be moved out, and the accumulated technology and experience should be solidified into PaaS. There is also one more point: do not forget the original intent of doing PaaS: lower the development barrier and make SaaS agile.

What I am thinking about is how to build this kind of selection mechanism?

3. How to Build an Effective Positive Mechanism

Positive in which direction? See the figure below.
IaaS, PaaS, and SaaS have a certain dependency relationship. IaaS comes first, then PaaS, and finally SaaS. Today both IaaS and SaaS have relatively successful cases: Amazon and Salesforce.

This is a dynamic circle. When an IaaS provider can offer mature host services, it will consider breaking through into PaaS. And the breakthrough point here is the most commonly used feature items in PaaS. For example, the storage service provided by Amazon. Providers that start directly from PaaS without providing IaaS services succeed very rarely — GAE, SAE, XAE and others have not achieved much success, with high platform dependency and large migration costs. Salesforce is a successful case, and Salesforce started from SaaS CRM. The expansion of the SaaS circle is easy to understand: as more and more requirements are connected, SaaS grows larger and larger.

PaaS is a very good direction. PaaS can stick to its users and has the potential to automatically produce SaaS. IaaS providers have a low barrier to entry, but need a sufficient user base and huge infrastructure investment. Services like BaaS, on the other hand, cannot guarantee reliability and cannot be monitored, so they will be a strong complement to PaaS.

The function of the PaaSer is to output various APIs and documentation, while the function of the SaaSer is to implement concrete functionality and deliver it to users. The difference in job function, to a certain degree, isolates the PaaSer from the SaaSer. Thinking from the perspective of technical staff growth, the SaaSer, under the constant pressure of completing the PM’s KPIs and doing business requirements, realizes that the technology will eventually be solidified into PaaS, and feels very uneasy. The PaaSer, meanwhile, is racking its brains thinking about how to provide better and more platform functionality, but the source of ideas is also limited to other cloud service platforms and internal research.

Without data, it cannot count as modern science; refined operational development needs even more data support. So what I thought of was to record feature items and usage frequency. In the Django framework the team uses, a Project is composed of a number of Apps, which divides feature items very well.

Define a SaaS feature item: an independently runnable, integrable small project. First it must be able to run independently, and second it must be integrable, with an independent identifier. So the following aspects of work are needed:

• A registration and numbering system for SaaS feature items is needed. - Deploy a Django App registration system
• Count usage frequency; it is not necessary to refresh remotely on every use — a fair strategy is enough. - Statistics strategy
• A unified Django App style. - Django App creation template
• Build a star-rating and comment system for Django Apps, for timely feedback and to select high-quality Django Apps. - Evaluation system.

4. Opportunities

• The work results of the SaaSer can be accumulated very quickly. Shared SaaS feature items can be integrated into larger SaaS feature items, and the SaaS application delivered to the user is just one integration link within it.
• SaaSer can divide the work and cooperate. Each SaaSer implements their own feature item, and then it can be integrated.
• PaaSer has a platform functionality goal. Based on the counted SaaS feature items, optimize the implementation on the platform and then compete with the SaaS feature items — this can motivate the PaaSer.

5. Risks

• Some feature items are too tightly coupled with scenarios, which affects the independence of the feature item and still requires modification before use. For example, sending a verification code also requires recording a foreign key to the personal information table.
• Under one project there may be many feature items. This tests the developer’s project organization ability.
• The learning cost of a feature item VS developing it yourself. The granularity is hard to get right.