Third-party Service Definition
Third-party Service Definition
Services that run outside of the Kato cluster, whose operating life cycle is not managed by Kato, and can communicate with the Kato cluster on the network are called third-party services. For example, a standalone Oracle service or a .net service running on a Windows server.
Kato’s Original Intention to Support Third-party Service Management
Kato, as an open source product of a cloud application operating system, has two common problems when it is used in many enterprises:
The step-by-step migration strategy, how Kato’s service communicates with the legacy service and unified management.
Kato takes the application as the core, and the key of the application is the service. Kato provides a system of service registration and discovery mechanisms to maintain configuration sharing and communication between services. However, the services that have not been migrated to Kato in the past version are beyond reach. Whether users are in the process of transforming traditional application architecture to microservice architecture, or in the process of migrating from traditional operation and maintenance to Kato, we highly recommend that users proceed step by step.
In this process, there will inevitably be a phenomenon of coexistence of services inside and outside the cluster. For example: We have a traditional service-oriented architecture, which uses the same Oracle database. The Oracle database runs on a specific server. In the first stage, we will not change it. First, some services are migrated to the Kato platform. These services need to access Oracle services as well as other services that have not been migrated. In Kato, we recommend using environment variables to define the configuration. In the past, we needed to define the same variable information for each service repeatedly. If there are changes in the later period, we have to change all of them again. In addition, services need to access other services. In the past, only the IP address of the service could be directly defined, and the service communication management function provided by Kato could not be used. Furthermore, on the Kato platform, you can visually observe the service topology and communication status, but services outside the cluster cannot be managed uniformly in Kato.
Kato application gateway is easy to use, but the legacy services cannot share the external network port or domain name with the services on Kato.
Kato provides the ability for applications and services to provide services to the external network. More and more users hope that the Kato application gateway can directly face the external network, that is, the external network IP is bound to the Kato gateway node, and the service gateway occupies 80 and 443 port. But here is a problem immediately. There may be other services in the enterprise that need to be accessed by the same domain name. Therefore, in the past, we had no choice but to continue to add a layer of nginx service in front of the Kato gateway. The huge complexity of configuration. At the same time, services that have not been migrated to Kato cannot use the many out-of-the-box features provided by the Kato gateway, such as domain name access monitoring.
Based on the above-mentioned user demands, we put forward a new idea to support integrated management of third-party services based on Kato’s service abstraction definition.
The Dfference Between Third-party Services and Built-in Services
|Comparison item||Built-in service||Third-party service|
|Docking Application Gateway||Support||Support|
|Relied on by other services||Support||Support|
|ServiceMesh governance||Support||Support upstream communication governance|
|Service properties||All properties||Support port, connection information, health check, permissions|
Support static or dynamic add Endpoint
|Service Lifecycle Management||All Support||Only Health Check|
|Share application market||Support||Not currently supported|
|Backup, restore||Support||Not currently supported|