Abstract: The disclosure herein describes using a monitoring tool and a management tool from a cloud native system to monitor and manage an application executing on a legacy system. Network addresses of services running in the application on the legacy systems are discovered. Based on the discovered addresses, a probe is configured for execution on the legacy system by a monitoring tool deployed on the legacy system to obtain metrics data associated with the services running on the legacy system, the metrics data representing execution loads of the application. A management tool deployed on the cloud native system receives the obtained metrics data. The management tool compares the metrics data to one or more performance thresholds associated with the application. Based on the comparison, the management tool adjusts a quantity of instances of the application running on the cloud native system, enabling the cloud native system to share the execution loads.

Abstract: The disclosure herein describes managing multiple clusters within a container environment using a control cluster. The control cluster includes a single deployment model that manages deployment of cluster components to a plurality of clusters at the cluster level. Changes or updates made to one cluster are automatically propagated to other clusters in the same environment, reducing system update time across clusters. The control cluster aggregates and/or stores monitoring data for the plurality of clusters creating a centralized data store for metrics data, log data and other systems data. The monitoring data and/or alerts are displayed on a unified dashboard via a user interface. The unified dashboard creates a single representation of clusters and monitor data in a single location providing system health data and unified alerts notifying a user as to issues detected across multiple clusters.

Abstract: The disclosure herein describes automating runbook operations associated with an application within an application host on an application platform. A runbook definition associated with the application is accessed by a processor, wherein the runbook definition includes trigger events and runbook operations associated with the trigger events. A runbook operator is executed on the application platform based on the accessed runbook definition and a runbook sidecar container is added to the application host by the runbook operator, wherein the runbook operator is enabled to perform the runbook operations within the application host via the runbook sidecar container. Based on detecting a trigger event, a runbook operation associated with the detected trigger event is performed by the runbook operator, via the runbook sidecar container, whereby the application is maintained based on performance of the runbook operations from within the application host.

Abstract: A computerized method and system for containerized application deployment is disclosed that includes: receiving an identification of a containerized application; generating parameters for the containerized application; based at least on historical performance data for a previous deployment of the containerized application, optimizing the generated parameters for the containerized application to produce optimized parameters for the containerized application; validating the optimized parameters for the containerized application; committing the optimized parameters for the containerized application to a repository; and deploying a selected number of instances of the containerized application with the optimized parameters for the containerized application. This advantageously brings operational data into deployment optimization in order to permit optimization based on actual historical performance data.

Abstract: The disclosure herein describes deploying an application cluster based on a cluster definition and service templates. A cluster definition is obtained from a repository and a cluster is created on a cluster platform based on the cluster definition. A cluster type of the cluster is identified based on the cluster definition and a service set is determined from a service map based on the identified cluster type, the service map including at least one cluster type mapped to at least one service. A service deployment template of each service of the service set is obtained and each service of the service set is deployed on the created cluster based on the obtained service deployment templates, whereby the cluster is configured for use according to the cluster type. Using service deployment templates mapped to cluster types enables efficient, flexible automated deployment of clusters with a wide variety of configurations.

Abstract: The disclosure herein describes using a monitoring tool and a management tool from a cloud native system to monitor and manage an application executing on a legacy system. Network addresses of services running in the application on the legacy systems are discovered. Based on the discovered addresses, a probe is configured for execution on the legacy system by a monitoring tool deployed on the legacy system to obtain metrics data associated with the services running on the legacy system, the metrics data representing execution loads of the application. A management tool deployed on the cloud native system receives the obtained metrics data. The management tool compares the metrics data to one or more performance thresholds associated with the application. Based on the comparison, the management tool adjusts a quantity of instances of the application running on the cloud native system, enabling the cloud native system to share the execution loads.

Abstract: The disclosure herein describes automating runbook operations associated with an application within an application host on an application platform. A runbook definition associated with the application is accessed by a processor, wherein the runbook definition includes trigger events and runbook operations associated with the trigger events. A runbook operator is executed on the application platform based on the accessed runbook definition and a runbook sidecar container is added to the application host by the runbook operator, wherein the runbook operator is enabled to perform the runbook operations within the application host via the runbook sidecar container. Based on detecting a trigger event, a runbook operation associated with the detected trigger event is performed by the runbook operator, via the runbook sidecar container, whereby the application is maintained based on performance of the runbook operations from within the application host.

Abstract: A computerized method and system for containerized application deployment is disclosed that includes: receiving an identification of a containerized application; generating parameters for the containerized application; based at least on historical performance data for a previous deployment of the containerized application, optimizing the generated parameters for the containerized application to produce optimized parameters for the containerized application; validating the optimized parameters for the containerized application; committing the optimized parameters for the containerized application to a repository; and deploying a selected number of instances of the containerized application with the optimized parameters for the containerized application. This advantageously brings operational data into deployment optimization in order to permit optimization based on actual historical performance data.

Abstract: The disclosure herein describes using a monitoring tool and a management tool from a cloud native system to monitor and manage an application executing on a legacy system. Network addresses of services running in the application on the legacy systems are discovered. Based on the discovered addresses, a probe is configured for execution on the legacy system by a monitoring tool deployed on the legacy system to obtain metrics data associated with the services running on the legacy system, the metrics data representing execution loads of the application. A management tool deployed on the cloud native system receives the obtained metrics data. The management tool compares the metrics data to one or more performance thresholds associated with the application. Based on the comparison, the management tool adjusts a quantity of instances of the application running on the cloud native system, enabling the cloud native system to share the execution loads.

Abstract: The disclosure herein describes managing multiple clusters within a container environment using a control cluster. The control cluster includes a single deployment model that manages deployment of cluster components to a plurality of clusters at the cluster level. Changes or updates made to one cluster are automatically propagated to other clusters in the same environment, reducing system update time across clusters. The control cluster aggregates and/or stores monitoring data for the plurality of clusters creating a centralized data store for metrics data, log data and other systems data. The monitoring data and/or alerts are displayed on a unified dashboard via a user interface. The unified dashboard creates a single representation of clusters and monitor data in a single location providing system health data and unified alerts notifying a user as to issues detected across multiple clusters.

Abstract: The disclosure herein describes deploying an application cluster based on a cluster definition and service templates. A cluster definition is obtained from a repository and a cluster is created on a cluster platform based on the cluster definition. A cluster type of the cluster is identified based on the cluster definition and a service set is determined from a service map based on the identified cluster type, the service map including at least one cluster type mapped to at least one service. A service deployment template of each service of the service set is obtained and each service of the service set is deployed on the created cluster based on the obtained service deployment templates, whereby the cluster is configured for use according to the cluster type. Using service deployment templates mapped to cluster types enables efficient, flexible automated deployment of clusters with a wide variety of configurations.

Abstract: Temporal transaction locality in a stateless environment may be provided. First, a current message having an identifier may be received. Next, it may be determined, based on the identifier, that the current message is associated with a transaction. Then, in response to determining that the current message is associated with the transaction, the current message may be sent to a target service instance corresponding to the transaction.

Abstract: Techniques for tracking microservices and facilitating rollbacks in response to exceptions are described herein. In an embodiment, a server computer system receives, from one or more sets of microservices program instructions, digital data identifying a plurality of tasks and a sequence of the tasks, the digital data specifying a particular computational workflow for execution by a computer. During execution of the workflow by the server computer system, the system identifies a particular failure in a first task of the plurality of tasks. The system causes displaying on a client computing device, a graphical user interface comprising a plurality of nodes, the nodes corresponding to the tasks. Within the graphical user interface, the system further causes displaying, with a particular node of the plurality of nodes corresponding to the first task, a graphical indication that the first task failed.

Abstract: In one embodiment, a sequence of microservice steps may be performed according to a programmed microservice workflow, while determining which executed tasks within the performed sequence of microservice steps have an individually corresponding rollback defined within the particular task. As such, a rollback path is stored corresponding to reversing the sequence of those executed tasks having an individually corresponding rollback, and, for each executed task having an individually corresponding rollback, a current status of the microservice workflow is also stored as a respective rollback status within the rollback path.

Abstract: In one embodiment, a sequence of microservice steps may be performed according to a programmed microservice workflow, while determining which executed tasks within the performed sequence of microservice steps have an individually corresponding rollback defined within the particular task. As such, a rollback path is stored corresponding to reversing the sequence of those executed tasks having an individually corresponding rollback, and, for each executed task having an individually corresponding rollback, a current status of the microservice workflow is also stored as a respective rollback status within the rollback path.

Abstract: Techniques for tracking microservices and facilitating rollbacks in response to exceptions are described herein. In an embodiment, a server computer system receives, from one or more sets of microservices program instructions, digital data identifying a plurality of tasks and a sequence of the tasks, the digital data specifying a particular computational workflow for execution by a computer. During execution of the workflow by the server computer system, the system identifies a particular failure in a first task of the plurality of tasks. The system causes displaying on a client computing device, a graphical user interface comprising a plurality of nodes, the nodes corresponding to the tasks. Within the graphical user interface, the system further causes displaying, with a particular node of the plurality of nodes corresponding to the first task, a graphical indication that the first task failed.

Abstract: Temporal transaction locality in a stateless environment may be provided. First, a current message having an identifier may be received. Next, it may be determined, based on the identifier, that the current message is associated with a transaction. Then, in response to determining that the current message is associated with the transaction, the current message may be sent to a target service instance corresponding to the transaction.

Abstract: A system for identifying a print service provider including an input module to receive a requested print product intent and an identification module. The identification module collects production job data regarding a plurality of successfully produced print jobs and compares the collected production job data to the requested print product intent to identify matching print jobs and its associated print service provider. A reporting module reports the matching print jobs.

Abstract: A system and method is disclosed for imposing a print job. In one example, the system discloses a computer programmed with executable instructions which operate a set of modules, including an imposition sequence module 104 which calculates a time to process the print job 102 relative to a processing operation 117, and an imposition module 114, 116 , or 118 which variably imposes the print job 102 based on the time to process. In one example, the method discloses how to balance a print job 102 workflow relative to a processing operation 117 , and impose the print job 102 based on the workflow balancing.

Abstract: A system for identifying a print service provider including an input module to receive a requested print product intent and an identification module. The identification module collects production job data regarding a plurality of successfully produced print jobs and compares the collected production job data to the requested print product intent to identify matching print jobs and its associated print service provider. A reporting module reports the matching print jobs.