1. An Operations Service System That Has Piled Up Beyond Repair

Developing a corresponding operations service for a clear operations need, so that operations and business users can use it, is entirely reasonable. But if you are satisfied with only that, the following situation easily appears:

Users constantly look for the entry point of each system, jumping back and forth between systems, busy hunting for buttons and copying parameters.

Once there are many such operations services and they form an operations service system, it becomes even harder to turn around. Want to change it? The coupling is too deep and the cost is high; want to refactor it? There is no motivation and the risk is large.

Can you use it? Yes, you can!

Is it pleasant to use? Not really!

Such an operations system is very hard to save itself; it is almost impossible to complete an upgrade by relying on internal iteration. By upgrade I mean reaching the level of a more advanced operations platform.

What makes an operations platform more advanced? It can be considered from the following aspects:

• Can it let the business team be more productive than similar companies
• Can it reuse more of the domain experience accumulated in the past
• Can it avoid duplicated development and wasted manpower
• Can it replace more manual work with automation

Operations revolves around security, stability, efficiency, and cost. Cost is not under the control of the operations platform, security and stability are the passing line for an operations platform, and the only thing it can really exert force on is efficiency.

The ultimate goal of an operations platform is to support the business and gain a greater comparative advantage. The good news is that a company’s competition checkpoint keeps switching: last year it was VR, this year it is OpenAI, and this keeps putting new demands on the platform. What needs thinking about is whether the operations platform can quickly satisfy the current operations demands of the business.

If a competitor needs 3 months to go live and you only need 2.9 months, then the company has 0.1 month of first-mover advantage, and by accumulating this step by step you can go further.

There have been many discussions on platform building in previous blog posts, so I will not discuss it further here.

Back to the operations service system that has piled up beyond repair mentioned earlier: in this situation, the only way to break the deadlock is to rely on external force. Introducing an external operations system product, recruiting a group of people from outside who bring advanced generative technologies and ideas, and having a leader with great boldness — only then is it possible to achieve a leap for the platform.

2. Using an Event Bus to Break Down the Information Barriers of SaaS

When users switch and operate between different operations systems, what are they actually doing?

They are triggering events and routing events — it is just that all of this is done manually.

It is people that hold it all together, completing the information flow between the various SaaS. Under such an operations system, using it is tiring for users, who have to switch back and forth and learn all kinds of domain knowledge; developing the platform is even more tiring, integration between services is hard, security risks are large, and developers also have to teach users to use and transmit all kinds of domain knowledge.

But is introducing an external system, triggering the collapse of the internal systems, and rebuilding the operations system the only path?

Of course there is more than one route. If it is early and the volume is not large, you can actually consider developing based on some mature operations platform system. Once the business volume reaches a certain level, it will inevitably not accept an external product taking over the core operations system wholesale.

The other route proposed here is the event bus.

Users need a new workbench SaaS, used to generate the events each subsystem needs, publish them to the event bus, and then push them to each sub-SaaS system. Every operations system should connect to the event bus, both consuming events and producing events.

For this, besides implementing the event bus and its basic routing, filtering, and other functions, you also need to be able to quickly onboard old SaaS. As shown below:

To onboard quickly, two core integrations need to be implemented: one is the API Middleware each system needs, to make it easy to generate events; the other is the API Action, so that a SaaS can execute actions via API according to events.

In the end, under the integration of a unified event protocol (for example CloudEvents), loose coupling between systems is achieved, and you no longer have to consider all kinds of integration problems caused by changes to the interfaces of the SaaS you depend on.

3. An Event Bus Better Fits How People Work

Technology serves people; people should not be burdened by technology. If you are burdened, then you should reflect on whether it is reasonable, whether it can be improved, and whether there is an opportunity.

An event bus achieves separation of concerns, and it fits how people work.

Each system only needs to care about the messages on the event bus, and does not need to care about the availability and reliability of other systems. The developers of each system also only need to focus on the system they maintain.

For scenarios with high real-time requirements, the event bus can actively push messages; in other scenarios, each system can pull the event messages it subscribes to, complete its own tasks, and then write the result events back to the event bus.

More importantly, the event bus provides a suitable direction for the evolution of operations.

An operations system based on an event bus can satisfy both the manual demands of the early business and the automation needs of the later stage.

In the early stage the business volume is small, and in order to go live quickly there will be a large number of manual operations tasks. Through the event bus, tasks can be well classified and displayed to manual operators in the form of a TodoList panel.

Once the business matures, it inevitably moves toward automation of operations. At that point you only need to consume events quickly through any automated form such as scripts, command-line tools, or SaaS, and you can run operations efficiently.