Vendor lock-in is a common problem with many cloud deployments

China IDC Circle July 16 reported: Manufacturers lock is a common problem of many cloud deployment. We all know a historic it challenge: The more a company uses a specific vendor's product or service, the higher its reliance on the vendor and its product services, and the more difficult it is for companies to change vendors. Even when you renew a contract with an existing vendor, this can lead to a lack of initiative in the negotiation process. Manufacturers know that the cost of enterprise change manufacturers is very high, the difficulty is very good, so both take its light, enterprises will inevitably accept the requirements of manufacturers price increases.

Lower utilization is a problem with cloud computing deployments, where utilization is a key "bargaining chip" at the negotiating table. Cloud vendor lock-in means that security-related services and functions have low or zero utilization; for example, when a new security control is required, when a more normative report is required to provide security events, when a security operation process is required, and when a requirement for audit transparency or other security and regulatory compliance adjustments is required, We can only listen to the manufacturer's mercy.

Therefore, it is obvious that to prevent cloud vendor lock-in is a very practical proposition. But there are some realities that will force the IT department to do otherwise. First, it may not always be involved in cloud computing deployments at the outset (for example, before a contract is signed). This means that companies requiring scope vendors to use the opportunity to develop standards (which is a very important factor in preventing cloud vendor lock-in) may have been lost. Once the partnership is established, the economic reality of the enterprise will force the enterprise to be subject to the manufacturer and cannot easily change the manufacturer. In particular, it is challenging to ask for additional budget after signing an agreement, because the fundamental reason for pushing many cloud computing implementations is to save costs. Therefore, it will be difficult to convince the additional cost budget due to the replacement of the manufacturer.

However, the good news is that you can follow several steps to proactively prevent cloud vendors from applying locks at very low cost. This is not to say that there is absolutely no cost involved (after all there will always be a certain amount of soft cost, such as considering staff time), but because these policies do not require additional budget, they can be used to avoid vendor lock-in.

Periodic test data export function

Assuming you have the right to a contract, the first thing a vendor can do for a cloud vendor is to test the ability of the service vendor to export any data. If the manufacturer declares (or is in the form of a contract text or a service capability advertised in its advertisement) that the data is yours, that they will provide you with data (or, as needed, or at the end of the contract relationship), there are several advantages to testing the service vendor's capabilities.

The periodic test data export function will help the user understand the actual export operation (not just theoretically). This will help users to further clarify the different aspects of the operation: how long it will take for the entire job to run, what people on the service vendor would be involved in, whether any additional costs will be incurred, what the resulting data format would be, and so on. If exporting data results in costs (such as the time of the vendor's staff or other professional services), you may need to decide whether to continue the test, as you may not be prepared to bear these costs. But at the very least you will understand that these costs exist (and know the approximate cost) so that you will not be caught off guard when you decide to change the cloud services vendor.

If data export costs are controllable, users should perform this action on a regular basis. Regularly performing backup data restore operations in roughly the same way can give you an idea of whether the backup operation works, and any changes to the data export methods (such as different data formats, different export mechanisms, running changes, new costs, and so on) will have an immediate impact.

Avoid the three secrets of cloud manufacturers

Apply Open API

Second, open standards can be rigorously enforced in new integration. You may not be able to ask vendors to use open standards within their products or services (at least not immediately after establishing a contractual relationship), but you can enforce requirements when discussing new integrations. Now, the specifics of which APIs will obviously depend on several factors: the specific cloud model you're using, whether you're using cloud computing as a whole, the type of integration work you're talking about, and so on.

For example, if you want to migrate virtual machine mirroring between your internal virtual data center and your infrastructure, the service provider's cloud computing, you may require open standards such as the Open virtualization format to be used in the exchange. This (at least) ensures that the service vendor is able to generate mirrors in the format that you subsequently export data to the selected platform. In Software as a service (SaaS), you can make access configurations for users using SPML. Specific standards vary, there are literally too many things to mention, but the key is that enforcing open standards means that another vendor can more easily replace and assume the role of the original manufacturer. This is a valuable way for your company to be immune to accidents when your service provider stops unexpectedly.

Read maintenance updates and service announcements

You will be surprised to find that many companies will not read the service announcements published by their cloud services vendors. Again, you will be amazed at what you learn from the bulletin. They are important channels for notifying your vendors of major service changes. In addition to the likely impact on your data security, these service changes may also affect your ability to change the vendor.

For example, a SaaS vendor decides to use encryption technology in its database. Vendors will notify you of this change through service announcements, release comments, or maintenance upgrades. You may have some problems with this: when the contract is terminated and the user exports the data, will the vendor provide the data decryption service? If this service is not provided, does it provide the decryption key so that the user can perform the decrypt operation on its own? People in your business should be careful to read these notices and be sensitive to whether these changes will affect your portability.

These do not fully include all the strategies that you can use to eliminate the constraints on the cloud vendor. However, these strategies are relatively low-cost (at least, in most cases) and are fairly easy to complete. If you already have a comprehensive plan to avoid vendor lock-in (in fact most companies do not have such a plan), the strategies described above will help further refine your plan. If you don't have such a plan, these strategies can help you in the process of forming a more comprehensive plan.