The need for upgrading a platform that hosts cloud services and applications derives from a variety of pretty good reasons.
- There are always improvements that you may apply in the structure and architecture of your platform
- Faster more intelligent and more reliable algorithms and procedures will benefit your cloud performance; so you should upgrade
- A modern cloud infrastructure must support modern technologies; so you have to upgrade
- As time goes by, clouds become bigger their services are delivered faster and their users are increased; you your cloud has to manage the extra burden
- If you don’t consider the above and you do no upgrade your platform will become useless in a while
Let’s suppose that you have decided to upgrade and you also have set the specifications and goals of your upgrade. There is a key issue on applying the necessary changes. This is backward compatibility. In simple words, you have to answer the question “How easily the users and applications of the previous version of my platform will adapt to the new version?”.
This is not an easy question to answer and depends on how big the upgrade will be. There are cases where upgrades are almost invisible as the architecture of the platform does not change dramatically and the hosting specifications stay the same and on the end no-one notices any change. There are also case where the change is quite big to miss. Usually old architectures become useless after some time and an upgrade has to be like building the platform from scratch.
In case of the second category, the administrators of the platform have to design an easy and as possible less painful way for users, developers and applications to migrate. Give the developers and users some time to understand the new platform. Keep both versions running in parallel for an efficient amount of time. Give the developers and users a good and clear deadline for migrating to the new version and make sure this migration will be feasible within this time.
Another important issue is the terms of use and the pricing policy of the new version. In case of incompatibility between the terms of use of the two versions or in case of radical changes in the pricing policy then the users will have to migrate to a new version of the platform that does not satisfy them or their needs any more. Moreover it is, at least, not decent to trap your old clients that have invested in your platform into a new version that does not satisfy their needs any more, constrains them and makes them spend more.
This is exactly what happened with Open Shift the cloud platform of Red Hat. A new promising version of the platform was recently released (version 3) and Open Shift made in short an important announcement. The architecture of the platform has changed so you have to adapt to it the architecture of your apps; the pricing policy has change, to more expensive, so reconsider your budget; you have one month to upgrade.
It sounded like a joke but it was true. One month is a short period of time to adapt to a new architecture. Reading the terms and conditions while signing for version 2 it was clearly written that the pricing policy would not change. We all thought that this would be for the whole platform; I think they meant to write that this would be only for the current version. After lots of complains the deadline was extended to four months only for the customers that had sighed on a paying plan.
Still, this is not a serious and professional way to upgrade a popular cloud platform.
This is not an easy question to answer and depends on how big the upgrade will be. There are cases where upgrades are almost invisible as the architecture of the platform does not change dramatically and the hosting specifications stay the same and on the end no-one notices any change. There are also case where the change is quite big to miss. Usually old architectures become useless after some time and an upgrade has to be like building the platform from scratch.
In case of the second category, the administrators of the platform have to design an easy and as possible less painful way for users, developers and applications to migrate. Give the developers and users some time to understand the new platform. Keep both versions running in parallel for an efficient amount of time. Give the developers and users a good and clear deadline for migrating to the new version and make sure this migration will be feasible within this time.
Another important issue is the terms of use and the pricing policy of the new version. In case of incompatibility between the terms of use of the two versions or in case of radical changes in the pricing policy then the users will have to migrate to a new version of the platform that does not satisfy them or their needs any more. Moreover it is, at least, not decent to trap your old clients that have invested in your platform into a new version that does not satisfy their needs any more, constrains them and makes them spend more.
This is exactly what happened with Open Shift the cloud platform of Red Hat. A new promising version of the platform was recently released (version 3) and Open Shift made in short an important announcement. The architecture of the platform has changed so you have to adapt to it the architecture of your apps; the pricing policy has change, to more expensive, so reconsider your budget; you have one month to upgrade.
It sounded like a joke but it was true. One month is a short period of time to adapt to a new architecture. Reading the terms and conditions while signing for version 2 it was clearly written that the pricing policy would not change. We all thought that this would be for the whole platform; I think they meant to write that this would be only for the current version. After lots of complains the deadline was extended to four months only for the customers that had sighed on a paying plan.
Still, this is not a serious and professional way to upgrade a popular cloud platform.
No comments:
Post a Comment