Short answer into the cloud world

Like most developers, most cloud applications have development capabilities and many services that allow for compilation, plus a certain amount of database access and computation. But even the best cloud computing applications are limited by the platform or the development environment, and applications are not just generic runtime or generic object containers. Just as development languages ​​must provide security for multi-tenant deployments without letting the user's code corrupt the virtual machine, the database, or the entire application. In addition, certain types of language structures must be constrained to prevent over-exploitation and deadlocking of resources, and security considerations are important.

Take Salesforce APEX as an example, does not require too much skill, the language itself can handle most of the business logic, but in a cloud development environment, to be limited by the platform, for example, in J2EE there is a good library to complete your The task you want, but J2EE is not available on your cloud platform, even if you only need a set of methods for this library, and many of the underlying features must be implemented on your own.

Let's take a real world example: License Key Generation. Software vendors may use license keys to force their end users to sign an agreement. The CRM system manages these license keys (as part of the client's assets) and generates a complete key within the CRM application. The software organization therefore requires that the secret The key system is transplanted to the CRM, in fact, the key generation is also used CRM platform encryption method.

However, even though you can port all logic to the CRM system, the computational load generated by the key remains constrained by the CPU, the stack size, and the amount of queries.

The solution is to call a service in the adjoining cloud to perform data processing. Unfortunately, there is currently no design pattern appropriate for this situation because:

Some of the data you need to access may not be mobile due to policy, organizational tactics, security, or other reasons. There is also a case where other systems are also using the data that needs to be moved.

If your other clouds need to handle the large amount of data that resides in the CRM database, you probably want a summary, summary, or graphing of the data instead of the original record.

Other clouds may support RESTful protocols such as JSON better, but they may not support WSDL and SOAP well.

Depending on the nature of the calculation, it may make sense to do all of the work in the CRM system, with only a small method called from the remote cloud. Conversely, it might make sense to do everything remotely and call it as a complete service.

If the calculations need to assess the status of the system (such as workload, locks, or data changes), network traffic (and result delays) can become a serious problem.

Security, testing, and deployment considerations can not be ignored and must be kept in the line of sight, even if ownership of the developer, administrator, and organization changes, to minimize impact (think about the impact enterprise reorganization will have on developers in the future Whether there is enough to have access to other clouds).

So the first step is to determine the best architecture for your particular application, find out which data elements need to be transmitted, and restructure your class across the cloud.