The gold rush for Cloud have been started. You can say many organisations are caught off guard when COVID-19 pandemic hit the world hard. Many current cloud implementations are being accelerated by Cloud providers. However, it is time that you must know what you are moving forward into.

Pick Wisely

There are many Cloud providers now. Incidentally, you can also view it as the death of on premise applications. This is because many applications had shifted their development for cloud applications. With so much choices, you need to choose and pick wisely. Do not jump into cloud for the sake of it. The end of support for on premise is usually announced early. Do consider at least 2 to 3 years to plan and pick your cloud applications for any major move.

Manage your Risk

A neglected area when moving to cloud is risk management. There are many horror stories on expectation gaps for many cloud move. Do consider to apply risk management in your cloud move. You should also be prepared to use multi cloud options to replace your legacy applications. Another common risk area is containerisation of applications. Thus, you may want to pilot cloud to explore risk areas and implement mitigation approaches.

The rush into Cloud could be hasty and headache for many applications owners. It is best to plan ahead and understand each cloud providers. You should learn mitigate your risks with pilot Cloud implementation. This way, your journey into cloud will be a breeze.

The good part of Cloud is high availability (HA). It should be hard to find downtime if you are using PaaS or SaaS. This is because HA is often considered in the architecture design. Thus, this is a great push factor for you to move to Cloud. Traditionally, on premise architecture must cater the required licences for HA. Will you move to Cloud for the sake of HA?

HA will be Norm

You may notice that Cloud applications are all HA as a norm. It is not surprising that you should either upgrade your on premise to HA or move to Cloud. The cost of HA is definitely much higher and not affordable in the past. It is usually done for large global enterprise. Most of the time, only production environment is HA because of the high cost of maintenance.

Time to HA on Cloud

If one of your objectives is HA, it is worth consider the cost savings for moving to Cloud. Many Cloud cost do not explicitly state how much HA will be in their cost. Thus, you need to compute the HA costs into your existing total cost of ownership before comparing to cloud cost. You will see that HA will one of the key justification on why you want to move to Cloud.

Building HA into your architecture used to be a costly ordeal. Now, many applications have been included HA as part of their product offerings. It is a ripe time for you to move to Cloud if HA is a critical component. The cost savings can be substantial because you can have HA across different types of development environment beside your production.

Data synchronisation for Cloud will be a standard because of residing data in different platform. The ideal synchronisation timing is always real time. Unfortunately, this can be costly and unrealistic. This is because data changes only happens for a particular moment. Thus, a full synchronisation is not efficient. How should we design for real time synchronisation?

User Behavioural Pattern

All data went through a lifecycle process from creation to modification and/or view only. A way to synch your data is to understand user behavioural pattern. This helps you to add in your trigger when there are user actions. The trigger to synch is usually to maintain modification consistency across the source and target system. It is also wise to close off the data and move these data as read only. That way, costly modification will not be needed for these data.

Scheduled Synchronisation

The most common synchronisation is schedule job. This method is brute force approach and helps ensure data integrity. However, it can be costly if data grows exponentially. It is usually cost effective to synch for changes instead of a full data synchronisation. A targeted schedule synchronisation is the most effective.

User behavioural patterns help to determine the data synchronisation you required in Cloud. A full synchronisation is costly and you should add filter to synchronise efficiency.

The standard REST methods in ORDS (Oracle REST Data Services) are GET, POST, PUT and DELETE. We usually started testing REST with GET because it is usually the easiest for SELECT statement. POST will be next for INSERT for new creation. The complex PUT will be the last for any UPDATE process. DELETE is seldom provided to preserve data integrity. So, why should you leave PUT to the last? This is because no modification process often requires exception flow and handling.

Handling PUT

You should relate PUT to modification process. REST does not have constraints to modify data unless you add the conditions. There are two approaches to handle PUT. One way is the trigger that will allow user to modify the data. Audit trail should be handled at source and/or target application if you want to keep track of the changes. Another way is to set conditions in your PUT services to prevent unauthorised modification.

PUT Response

A key characteristic of PUT is primary key (PK). You will need the PK to amend the correct data. So, what happens if PUT cannot find the PK? There are two ways to handle the PUT response.

1. You can give a valid response or 201 status if PUT is successful.
2. You can choose to INSERT if PK cannot be found.

PUT is the last and most complex REST service that you may want to expose. Handling PUT and its responses will need careful consideration on how you want to manage data modification. In some cases, you may choose to omit PUT service to preserve data integrity like DELETE.