Given the growing benefits of connecting mission-critical systems to cloud computing, presented in the first part of this article, it is necessary to carefully evaluate the prerequisites to be fulfilled so that this integration does not jeopardize the ‘critical mission’ of the companies.
Auditability and Levels of Services in the Cloud
As with any system and service consumed by large enterprises, cloud computing resources, when used in the corporate context, need to be “auditable”: just as in accounting, every individual operation where the business is involved needs control. The subsequent analysis, totalization, and verification of this big data only generate additional benefits.
Also, because they are computational services, the auditable records allow proving that the level of service agreed with the external suppliers or promised to the clients (external or internal) is being reached. For example, if the service level agreement predicts that 99.9% of requests are processed and answered in less than ten seconds, this can be proven by observing the auditable records.
One of the reasons for the low corporate adoption of systems made available as a service in the cloud is that, they do not allow their auditing by external users.
Resilience to Installable Connections
Cloud computing, because it is based on Internet connections, does not have the same reliability as internal corporate networks: mission-critical systems not only need to ‘stand up’ to interrupted or suspended communications failures, but need to be (such as cell phones, tablets, and credit card machines) that simply disappear from the network when your power source (your battery) runs out (as is the case, for example, for tablets, cell phones, and credit card machines) without completing the ongoing transactions.
The integration of these devices with mission-critical systems requires to not to suffer from any interference in case of significant volumes of incomplete transactions.
Another consequence of connecting mission-critical systems to cloud computing is that the total number of users tends to increase significantly.
Typically, the servers responsible for mission-critical systems have been sized to serve the internal users of the enterprises. Through the cloud, these same devices can now receive demands directly from customers, partners or connected devices, making the total number of users expand greatly.
The expansion of the computer park that supports the mission-critical environment in the same proportion as the user base growth results in economically unviable costs. Even though they are designed with some capacity slack, there is a risk that the available processing capacity will not be sufficient to serve all users.
Because they are mission-critical systems designed for internal users of enterprises, they must be the last to feel the consequences of any problems in the processing capacity (or, in other words, they must have priority attention so that they do not feel that impact).
To achieve this goal, it is necessary to limit the number of cloud computing demands to be processed in order to guarantee the processing capacity available to internal users.
Access to the company’s mission-critical systems must rely on all possible techniques, created by information security professionals. User registration is a fundamental prerequisite, but insufficient for the security of mission-critical systems.
The source code for the mobile applications, web pages, or software of the connected devices must contain no password to access resources made available on mission-critical servers (such as specific user accounts or databases). Otherwise, this password would be available to any hacker capable of applying ‘reverse engineering’ techniques to the above codes.
Another ‘loophole’ to be avoided in connecting mission-critical systems to the cloud is to allow access to critical resources from devices with any IP address on the Internet. Using the appropriate tools to limit access to a few or even a single IP address known to the firewall increases the level of security. In cases where security is extremely important (as in the case of banks), this single IP must belong to the private cloud.
Resilience to Service Refusal Attacks
Denial of Service (DoS) has long since ceased to be science fiction: this type of attack consists of attempting unauthorized access to large and simultaneous systems.
In this way, the demand for capacity grows very quickly, causing responsible servers to have difficulties or even fail to provide the service due to legitimate users.
When connecting mission-critical systems to the cloud, it is necessary to ensure that in the event of such an attack (to resources made available through the cloud), the service provided to users connected through the internal network of the company is not harmed.
The recess consists of a system’s ability to allow new calls (to services or routines) by the same user even before a previous call made by it has been completed.
Since the emergence of recursive programming techniques in the 1960s, almost all computing platforms evolved to support the recess.
Although useful, overusing this feature can lead to processing problems and, in the end, result in the same behavior as a denial of service attack.
Thus, even when mission-critical servers have the ability to process many thousands of transactions simultaneously, it is necessary to have callback locks for each individual user.
For example, in the case of a server belonging to a bank, no user should start a new money transfer transaction from one checking account to another in less than ten seconds (even if he is operating with the bank on different devices).
The architects, designers, and developers of mission-critical systems thought, at the time of their creation, only internal users of companies: this type of audience has well-known cultural and idiomatic preferences.
Through cloud computing, these systems are connected with new audiences, whose preferences may be quite different. For example, cloud applications can attract users who speak other languages for which the mission-critical system is not supported. But we must not give up supporting these new human languages and cultural preferences in the user interface made available through the cloud.
Productivity of Developers
The complexity of solutions that integrate mission-critical servers, cloud computing, and end-user devices is greater than the average of the systems in use.
So often, after long development efforts, when launching tests (for example, using Web pages to trigger mission-critical services across the cloud) the only result is a blank screen or an empty response. In such cases, identifying the cause of the problem can turn into a nightmare for developers (or many sleeping nights).
This kind of situation could be avoided if the cloud environment were able to report on the problems encountered by transferring the demands to the mission-critical servers. Creating cloud infrastructure for this purpose, however, does not have obvious benefits for cloud service to users (as well as being too costly to be included in the budget of any individual project).
Conclusion – ROI is the Key!
The benefits of connecting the mission-critical systems described in Part One can only be made available if all the safety and security in Part Two are properly addressed – not only from a functional point of view but from an economic point of view. In other words, return on investment (ROI) needs to be rewarding for companies to be willing to develop projects of this type on a more significant scale. This economic equation is responsible for the restricted advancement of the so-called “API Economy” in the corporate world.
On the other hand, we note that all the safety quoted in the second half of this article are not specific to a particular type of software, or a particular vertical market segment. Rather, they represent a set of requirements imposed on any mission-critical system that one wishes to effectively integrate into the cloud.