Best practices for migrating applications to the cloud Platform

More and more developers and companies choose to migrate applications to the cloud platform, and for real enterprise products, the process is not a simple one-click button. We need to start from the environmental characteristics of the cloud platform to make certain adjustments to their own products. IBM Cloud Platform experts Sheetal and Ashish summarize the best practices for migrating applications to the cloud platform, including support for silent installation, control of disk space use, settings that should be completed by APIs or CLI, tracking, and log information must be collected through API/CLI.

Sheetal and Ashish the migration into 3 scenarios, respectively:

Integrate your application into another cloud product-the current requirement is to enhance existing cloud applications and your application capabilities. The goal is to achieve seamless integration. Typically, when you need to introduce new functionality into existing products, you are involved in designing and developing new features from scratch, and another option is to integrate their functionality into the cloud by leveraging an existing product (in which case, you do not need to enable the cloud). In this case, you must make sure that your application can connect to the existing cloud product correctly.

Add your application to another device hosted in the cloud-a cloud device consisting of preinstalled and preconfigured software and applications, and sometimes as a self-contained server. When you plan to add an additional application to an existing cloud device package to enhance its functionality, make sure that your application can interact correctly with other applications and configuration files in the package as well as with device resource dependencies.

Hosting your application as a stand-alone cloud device-one way to use your application in a cloud environment is in its own cloud device, especially if you don't need to integrate it with another cloud application.

For how to achieve a smooth migration, they present several practices for the application's own tuning, including support for silent installations:

The installation process does not display messages or Windows installed as a silent installation. When you integrate an application into another application or a device, it becomes part of a single product, and a single installer is the preferred creation. If your product cannot be installed silently, information from the user is requested for your product during a single installation, and the device team may not want to show/ask its users. This is a hassle for users, and they don't need to know the details of these basic products. If a silent installation is not available, you will lose the efficiencies that have been achieved because, for users, it is like installing two different products.

It is also important to control disk space use: Your system resources should automatically reduce the disk space that it occupies to help control disk use. If the functionality and processes of your product generate logs and trace data to an output file, there should be a process in the device server that restricts the flow of memory to prevent the emergence of out-of-memory problems. Create a property file that defines the size and number of output files that will be generated. These values should be editable by your system administrator. Create a process to monitor these files.

You should set up and collect tracing, log information by API or CLI:

You must be able to access and manipulate all configuration settings through the API or command-line interface. Because REST WEB services provide loose coupling, lightweight, and interoperability, they are very popular and may be the one you most often encounter. If other processes need to manually change some property files or other files, use it to facilitate the CLI or API to complete those changes. Use these ACLs or APIs if you need to complete a specific setup or configuration during the installation of the overall functionality of the device or device part. The design should be this way, the device does not need to understand the internal design of the application can make any changes to the settings, you should be able to use the CLI to complete. In addition, no matter where you change this type of configuration or settings, no matter where you change, ideally, it should take effect in time, without the need to restart the application;

When a problem occurs in a product, it is important to fully diagnose and collect the log from the product. A command-line mechanism (or other) is used to perform a selective or quarantine diagnostic operation, and the operation will not affect the entire device. This includes the ability to collect log/trace information that can be used directly by the administrator.

High availability support is a good advantage: most IBM devices try to support high availability; If your product does not support high availability, the entire high-availability effect of the device will be compromised. It's a good idea to have your product complete a high-availability design early in the development or to have some space for future development.

In addition, it includes:

Provides lifecycle functionality-any process, thread, or daemon that runs as part of your application must have its own lifecycle capabilities. It should provide a common state for opening, pausing, and stopping, and there should be a way for the product to control these states by using the CLI or APIs themselves.

All configurations should be reconfigurable-any configuration that is assumed in the preinstallation phase must be reset (reset) when the device is created, or it can be reconfigured according to user requirements.

The ability to activate and disable applications in a device-a powerful advantage for your application-you can activate or disable an application by using a command line, API, or GUI, so that the product-related files still reside on disk, but they cannot consume the CPU and memory resources of their managed systems. This allows you to embed your product in another product and use it when needed, by turning it on or off. In the cloud, a device can turn off some of the services it offers, even when the application is hosting the initial product.

Commands should be run in any shell-try to ensure that all commands are not limited to any particular shell. CLI commands (at least the most important) associated with your application should not be limited to running on only one shell. Devices that are integrated into your product may run on different shells, not necessarily the one you choose; In this case, you will not be able to run CLI commands simply because the shell is different.

Enable version marking, it is also best practice to make data backup and recovery available, the application should be self-contained, and the API should be able to import or export applications, provide a programmatic way to manage users, minimize dependencies to the outside, and have an API that can terminate programs completely.

(Responsible editor: The good of the Legacy)