This article gives some best practices for designing and packaging an application for cloud consumption so that it can be:
- Integrated into another cloud product so the other product can leverage its capabilities.
- Integrated into an appliance already hosted in the cloud.
- Hosted as an independent appliance in the cloud.
If any of these scenarios of are interest, read about some experiences we've distilled into best practices to achieve one of these goals.
First, let's talk a bit more about these scenarios.
Again, the scenarios we propose involve integrating an application into an existing cloud product, deploying an application as part of an overall appliance package in the cloud, or integrating the application into an existing cloud appliance.
The need is that you are enhancing the existing cloud application with the capabilities of your application. The goal is to do it seamlessly.
Often when there is a need to introduce new features to an existing product, it involves design and development of the new functionality from scratch; the alternative is to take an available (in this case, non-cloud-enabled) product and integrate its capabilities into the cloud product. In this scenario, you have to make certain your application can "connect" appropriately with the existing cloud product.
A cloud appliance consists of pre-installed and pre-configured software and applications; it can also to be used sometimes as a self-contained server. When you're planning to add an additional application to an existing cloud appliance package to enhance its functionality, make sure your application interacts correctly with both the other applications within the package and with the configuration files and the resources dependencies of the appliance.
One way of taking your application to the cloud is within its own cloud appliance, especially if you don't need to integrate it with another cloud application.
Before continuing, it helps to understand what we mean by appliance, application, and virtual machine:
- Virtual appliance: A pre-built software solution comprised of one or more virtual machines that is packaged, maintained, updated, and managed as a unit. Developers create virtual appliances by developing self-contained and optimized application stacks that are customized for their workload and embedded with an operating system of choice; appliances can be more secure and reliable than traditional software; by simply copying a set of files and powering on the virtual appliance, an application can be made available.
- Application: A cloud-enabled application; it performs a function or a range of functions. It is a component of the application stack within the appliance.
- Virtual machine: A tightly isolated software container created to run on virtualized platforms. It contains four key virtualized resources: CPU, RAM, storage, and networking.
In this article, the word "product" is used to mean "application" or "appliance" depending on the context.
Now let's look at best practices to help make these scenarios a reality.
Installation that does not display messages or windows during its progress is called silent installation. Silent installation is not unattended installation. An unattended installation is one that does not require user interaction; a silent (or quiet) installation is one that does not display any indication of its progress.
You must support silent installation in your product along with interactive/GUI installation so the user can choose any of the two methods to install the product. For silent installation, the required user inputs should be given in a response file that needs to be edited only once in the beginning, at the start of the installation. Once the installation begins, user data should not be required and progress/windows should not be displayed to the user.
When an application is integrated into another application or into an appliance, it becomes part of one single product and a single installer is preferred and created. If your product cannot be installed silently, information is requested from the user for your product during the single installation, at which time the appliance team may not want to display/ask its users. This is an inconvenience to the user and it's not really required for them to know these underlying product details. If silent installation is not available, you lose the effectiveness you've gained because for the user, it's like having to install two different products.
Your system resources should throttle down automatically to help control disk space usage. If the functions and processes in your product write logs and trace data into an output file (and how many of them don't!), there should be a process in place to restrict this data flow to prevent an out-of-memory situation in the appliance server.
Create a property file that defines the size and number of output files to be generated. These values should be able to be edited by the system administrator. Create a process to monitor these files.
If the output file's size or number exceeds the limit mentioned in the property file, one of the following steps can be taken:
- Old files can be deleted and replaced by new ones.
- The sysadmin can be alerted to the situation.
- You can stop writing new data to the log file.
You should also provide a configurable and programmatic (on-the-fly) option to do following:
- Redirect the logs to any desired location: In an appliance environment, the sysadmin may want to have all logs in one place for ease of monitoring and collecting logs. Have an option in your product to choose the location where logs are stored.
- Name and rename the logs: Along with location where logs should go, the file name of these should be specified by the user according to his own standard and convenience. To provide more flexibility, the ability to rename the log files should also be supported, keeping in mind that your product can be part of a big, advanced appliances in the future.
- Embed the logs to any other logs by providing the option of log output streams: This advanced feature means having the flexibility to embed your logs into another log, provided the appropriate output stream is allowed by the appliance environment.
You must be able to access and manipulate all configuration settings by APIs or a command-line interface. Thanks to the loose coupling, light weight, and interoperability that REST web services offer, they are very popular and probably be the most common ones you encounter. If any process requires manual changing of some properties file or any other file, it should be adapted so those changes can be done by CLI or API.
If a particular setting or configuration is required to be completed during installation of the appliance or as part of overall functioning of the appliance, use these CLIs or APIs to do so. The design should be that the appliance need not understand the internal design of your application to make any changes to the settings — you should just be able to use CLI to do it.
Also, wherever such configurations or settings are changed, ideally it should take effect on the fly without requiring the restart of the application; that way, it won't disturb the functioning of the entire appliance.
When a problem is reported in the product, it's important that logs are collected from the product in order to diagnose it completely. Have command line mechanisms (or any other) in place to perform selective and isolated diagnostic operations; operations that won't affect the whole appliance. This includes the ability to collect log/trace information that can directly be used by the sysadmin.
Most of the IBM's appliances try to support high availability; customers demand this. If your product does not support high availability, then the overall high availability capabilities of the appliance becomes less effective. It is a good idea to have high availability support design done for your product at the beginning of the development or leave some room to do such development in the future.
Any process, thread, or daemon that is running as a part of your application must have life cycle capability of its own. It should serve such common states as start, suspended, and stop and there should be a provision to control these states by the product itself using the CLI or APIs.
Any configuration assumed during pre-load must have the option to reset at the creation of the appliance. It should be able to be reconfigured at the customer's request also.
Your product might work under certain settings as an individual — for example IP address, port settings, or network settings — but when it is integrated with another product, those parameters might need to be changed due to customer's work environment or the overall product's requirement. Any such settings must be resettable and changeable during product integration, appliance creation, or customer deployment time.
This feature is an optional one, but an important one. It is a strong advantage to your application to be one that can be activated or deactivated using a command line, API, or GUI such that the files related to the product still reside on the disk but will not consume CPU and memory resources of the system it is hosted on. This way, you can embed your product into another one and use it when it is required by turning it on or off. In the cloud, an appliance can shut off certain services it provides by deactivating the corresponding feature even while it is continuing to host the initial product.
If there is an update or patch available for your product, you must be able to apply it in the integrated environment of the appliance. Once your product is integrated into another one, your team won't have to stop working on its enhancement: You just need to define an update path for your product in the design phase.
Since your application might be integrated into other cloud appliances in the future, it has to support patching within an integrated environment.
Also, your application should have updates, fixes, and patches packaged so they can be included or bundled with other updates of the appliance. And it should be able to go through the patch/update process with having to restart the application.
Including a provision that allows you to undo the applied update or patch is good too in case the change is found to be incompatible with the rest of the appliance.
Try to make sure all commands aren't restricted to any particular shell. The CLI commands related to your application (at least the most important ones) should not be restricted so that they only work on certain shell. The appliance into which your product is integrated might run on a different shell than the one you choose; in that case, you will not be able to do run the CLI commands just because the shell is different.
Functions that are supported by a license key should be connected to the common appliance's GUI or CLI and trigger when a license key is installed. If any of the functions in your application also support a license key, then this feature must be designed properly and be integrated into the appliance's common GUI from the beginning in a way that if the license for any component of your application is applied, the same should be detected by the common GUI informing the user using the appliance. This gives the customer a clear idea of which licenses he is already using and which ones he needs to apply for or purchase. This also helps the cloud administrator maintain the various licenses effectively. The application should provide an API to query licensing info and apply or update it without restart.
This is an important requirement. There should be a provision in your application to rebrand it (with product name and version number) when it is included in another product or appliance.
An appliance owner might want to rebrand the functions provided by your application so that they are described in a name that can be more closely aligned with the appliance's common objective.
The version number should also be capable of being overwritten by the appliance. This can be achieved through various ways, one way is to have a file describing product name and version number as a constant variable that can be changed by the appliance admin (with appropriate permissions, of course).
Make provisions for a clean, hard stop of the application through APIs. When there is a need to abruptly exit any program in your application (such as critical shutdown or when it is not responding), there should be APIs in place that can cleanly terminate the processes and threads within your product without corrupting data or adversely affecting the appliance.
Create data backup and restore abilities through APIs in multiple formats like flat files, a database dump, etc. Develop a command line capability (a GUI is not necessary) that can backup all critical data related to your application and restore it when required.
This is useful every time a re-installation of your product is done in the appliance and the older data is required for your product to be able to perform the same processes and functions as before. It is also helpful in enhancing resiliency or high availability in the appliance.
This is an important requirement so that your application can be independently included or excluded or updated in an appliance. While trying to include, exclude, or update your app, the sysadmin should not be struggling with the dependencies the application might have on external data, settings, configurations, or environments.
It's a good thing to have APIs ready that can query data from within your application or write data from the application to any location. The same API can also be used to manage permissions of the user querying or writing data. This eases the process of editing any feature in your application by the appliance team and provides them with more modularity.
Have a programmatic way to create, delete, or modify users and roles and to restrict various options or functionality. To have secure access to your application's features (and also secure appliance functions as well), there should be a programmatic way to restrict and manage various users and their roles. A GUI would be an idle interface to create users and roles and to manage their respective permissions.
There should be only loose coupling to any specific versions or vendors. Try to eliminate any tight dependencies on external tools to be used in your application.
These 18 basic practices should help you think about alterations to make to any appliance you plan to run in a cloud, especially if you plan to add it to a cloud appliance, whether it is already running in the cloud or not.
The next step is to dive deeper into each of these practices to view some real-world implementations of them, and understand the implications each has in building an effective cloud application, one that can be easily integrated in the cloud environment.
More resources from the topics mentioned in this article:
- Virtual appliances and the Open Virtualization Format
- Automate your virtual cloud appliance onto IBM PureFlex System
- Introduction to virtual appliances
- Definitions of virtual appliances, virtual applications, and virtual machines
For more on how to perform tasks in the IBM Cloud, visit these resources:
- Upload and download files from a Windows instance.
- Install IIS web server on Windows 2008 R2.
- Create an IBM Cloud instance with the Linux command line.
- Create an IBM Cloud instance with the Windows command line.
- Extend your corporate network with the IBM Cloud.
- High availability apps in the IBM Cloud.
- Parameterize cloud images for custom instances on the fly.
- Windows-targeted approaches to IBM Cloud provisioning.
- Deploy products using rapid deployment service.
- Integrate your authentication policy using a proxy.
- Configure the Linux Logical Volume Manager.
- Deploy a complex topology using a deployment utility tool.
- Provision and configure an instance that spans a public and private VLAN.
- Secure IBM Cloud access for Android devices.
- Recover data in IBM SmartCloud Enterprise.
- Secure virtual machine instances in the cloud.
In the developerWorks cloud developer resources, discover and share knowledge and experience of application and services developers building their projects for cloud deployment.
- Find out how to access IBM SmartCloud Enterprise.
Get products and technologies
See the product images available for IBM SmartCloud Enterprise.
Join a cloud computing group on developerWorks.
Read all the great cloud blogs on developerWorks.
Join the developerWorks community, a professional network and unified set of community tools for connecting, sharing, and collaborating.
Sheetal Jharia is a Staff Software Engineer (and IBM Cloud OS Development Lead) at IBM-ISL, currently working on IBM Systems Director VMControl Development, a critical product in the IBM cloud portfolio. She has eight years of IT experience and holds a bachelor's and master's degree in Electrical and Communication Systems Engineering from IIT Madras, India.
Ashish Billore is an IBM Cloud OS Development Manager at IBM India Labs. He manages IBM Systems Director VMControl development team and is responsible for developing reusable components for building cloud infrastructures. He designs and develops applications using technologies such as Java, Eclipse, OSGi, and web services. He has contributed several patches to the Eclipse open source platform and presented articles at IBM technology and QSE conferences. He holds a Bachelors Degree in Electronic and Communication Engineering and Post Graduation in Information Technology.