Tag: Cloud

Measuring Risk

~ Danny Kwok ~ Leave a comment

One part of Risk management involves the measurement of risk. Risk is an elusive scenario that may or may not happen. So, how to you anticipate and measure risk in IT projects. These are some methods that you may consider for measuring risk.

Historical References

Historical data is the classical way of getting data. You can also reference similar projects and obtain the data as a benchmark. By projection of these data, you can measure risk and build your strategy around these risks. However, these methods have its drawbacks. This is because you may over invest and overestimate based on historical data.

Active Monitoring

Active monitoring is most widely used in Cloud. This is usually resource intensive for your family servers. Risk are captured real time and send for corrective actions. The purpose of active monitors helps to mitigate risks with known scenarios. Ironically, this is rarely used due to the higher cost.

It is useful to list out the risks and mitigations. In many cases, measurement of risks have been neglected. If you have a risk team in place, you will want to continue understanding and measure risks. This approach will give you clear indicator of potential risks regardless of the method you used.

The Good and Bad of Waterfall Migration

~ Danny Kwok ~ Leave a comment

Waterfall migration is the mainstay for on premise application. In recent years, migration is adapting to Agile with Cloud. However, it is common to see conservatives conduct waterfall migration with Cloud. What are the good and bad of waterfall migration?

The Good and Bad of Waterfall

The good parts of using waterfall migration are:

  • Traditional approach with fixed scope.
  • Increased redundancy with development and testing environment.
  • Increased testing and issue management.
  • Tight control of changes from one environment to another.

By using waterfall approach, you need to anticipate these bad situations that will arise:

  • Increased duration from additional environment setup.
  • Increase cost of maintaining and licence costs.
  • Unable to react to scope creep.
  • High reliance to critical path.

While waterfall migration is a tried and tested method, be prepared for longer duration and higher costs due to the environment redundancy.

Force To Cloud

~ Danny Kwok ~ Leave a comment

Application migration to Cloud is on the full swing with many applications ending support for on premise version. If you are an product or application owner, you will be caught in countdown to migrate to Cloud version. In a way, you are compelled to go to Cloud or faced with end of support for on premise version.

Cloud Risk

Cloud risk will increase if you have more than 20% customisation for your on premise application. The first order of business when moving to cloud is a “rollback” to product base by removal of your customisation. This is the most challenging and tedious nature of cloud migration. This means you can either remove the customisation or decoupled them from the product.

Cloud Approach

Migration duration is not the time that you should start the cloud move. If you are aware of the EOL (End of Life) date, you can after preparation as early as possible. For many, this risk is only handled during migration project. However, I favored this preparation be done as early as possible. One approach is to decouple the customisation to Cloud. This leave your entire on premise ready for “lift and shift” migration approach. Another approach is to move your new customers to Cloud instead of on premise. You can always scale up when you fully migrate all your customers from on premise.

The advantages to migrate of cloud outweighs the risks. In many instances, you will be force to cloud due to EOL of on premises. You should start preparing to decouple your customisation as early as possible. Do be creative and consider various approach to lower your risk and increase confidence in cloud. In a way, moving to cloud is more of psychological than technical.

A Tale of Two Cities

~ Danny Kwok ~ Leave a comment

Cloud and On premise reminds me of A Tale of Two Cities. One is being replaced gradually without the other having knowledge of it. It is not surprising some teams will remain in self denial of the proliferation of Cloud.

Similarities and Revolution

Cloud is nothing new and have been around for decades like hosted servers or managed services. The revolution comes about in the form of Digital Transformation from need for larger and larger server capacity in a particular entity and virtualisation. Suddenly, everyone jumps to the bandwagon as costs plummets with competition. However, not all teams are challenged to change.

How this Ends?

If you are familiar with the ending of the story, Darnay is knocked unconscious while being replaced by Carton for the guillotine. Does this sounds familiar if you are belonging to the teams who are not on Cloud? In many organisations, this replacement are taking place without involvement of on premise team. In most case, decisions are done at top management level and the teams are only engaged during migration. What a stark reminder to being at the guillotine!

A Tale of Two Cities are playing out at many organisations. However, it is a good suggestion that this should not be the plot. The ending is not pleasant for many. It is time we revisit the playbook and mirror another tale!

A Shift to Cloud Upgrade

~ Danny Kwok ~ Leave a comment

Major upgrades and minor upgrades are a thing of the past. These methods are common for on premises applications where versions upgrades are costly and unstable. Usually, it is a three months efforts for minor version to a year for major upgrade. In your cloud application, it is common to see upgrade in another form. This is because you will be pushed to upgrade to a higher version.

Managing Cloud Upgrade

If you are not familiar to Cloud upgrade, you will be in for a surprise. Cloud upgrade is similar to your mobile OS upgrade. You will be notified of the newer version and its details. Then, you will be recommended “update” to the higher version. Similarly, your cloud application upgrade will be in the same process. The risk is that some of your application may break after the upgrade. Unfortunately, you cannot rollback to the other version.

Reducing Risk

The key part of Cloud applications is the ability to clone, export and import the configuration. Cloning allows you to upgrade for your testing environment and resolve pending issues before making the change in production. Another way is update your application to the latest version incrementally. This reduces the probability of big changes of the new version to your current one.

Be prepared for cloud upgrade similar to what you are facing in your mobile OS upgrade. You need to manage upgrades more often in order to reduce your risk exposure.

No Downtime Approach

~ Danny Kwok ~ Leave a comment

Application downtime is getting lesser and lesser with Cloud computing. Users are more demanding without the need of downtime. Thus, we need to move to the approach of hotfix and high availability environment.

Picture by Ethan
Shift to Zero Downtime

The design of zero downtime will require a digital transformation approach to your entire architecture. Another consideration is utilisation of the Cloud platform for different high availability approach. As this approach will incur additional cost like licences, you may want to evaluate a switch to pay as your use model instead of fixed licensing.

Development with No Downtime

Another key change is your development approach. This must be changed to reflect deployment with no downtime. Instead, hotfix and patches must be applied seamlessly without any downtime or impact to user operations. Therefore, your development will need Agile and DevOps to enable this approach.

If you have intention to move to a services with no downtime, it is time to reform your architecture and development approach. This involves utilisation of Cloud platform and Agile development to achieve this vision.

Multicloud Approach

~ Danny Kwok ~ 2 Comments

As we are moving our applications to Cloud, you realise that you are using a combination of different cloud providers. This is what we called a multicloud approach. It is now the most commonly used approach as applications are being migrated to its Cloud version.

Managing Multicloud

Multicloud strategy will be the norm for all cloud approach. The management of cloud must be taken as a single view instead of viewing as different cloud providers. Your key strategy to manage multicloud is on how to maintain each cloud like a single entity. Thus, you will need to draw up engagement rules and accountability matrix for your team. You may even consider having a primary cloud provider to manage other cloud providers. Depending on your needs, these management of multicloud must be summarised in a concerted manner.

Measuring Multicloud

There are a few ways you can consider to measure your Multicloud usage. One way is to start the management of cloud from a consumer centric view. This view utilise a user as the unit of measure. Cloud consumptions are managed at a user level. Another way is a product view where your product is leveraging on different cloud services. The product will be your unit of measure. Your selection will depends on how you intend to ROI (return on investment) from your cloud consumptions.

Multicloud approach will be the norm for all organisation. It will take time to understand and marry these cloud providers into your desired needs. Thus, you have start considering on how to manage and measure your multicloud providers in a single view.

Cloud and Digital Transformation

~ Danny Kwok ~ Leave a comment

Digital Transformation usually move at different stages for each application team in an organisation. This is because legacy system and old process remain entrenched for users. Cloud is a major proponent for digitalisation. What should be the practical approach to use Cloud for your Digital Transformation efforts?

Transform to Hybrid Cloud

Major applications are now offered as SaaS (Software as a service) or cloud application. Thus, your upgrade likely will be conducted in Cloud platform. Due to the timing differences in upgrades, you will encounter the hybrid Cloud approach. This is where your applications is located in both Cloud and on-premise. All digital transformation efforts will definitively result in Hybrid Cloud in your enterprise applications.

Cloud Transition Application

As your building blocks of applications transition from on-premise to Cloud, you will find a need for transitional application These type of software helps as a temporary bridge between on-premises and Cloud applications. Such software could be API gateway, integration platform or even customised applications. This application are not designed for long term. The key focus is to bridge until your application digital transform to Cloud.

Cloud and Digital Transformation will take at least 5 years. You will need to prepare for Hybrid Cloud and create your Cloud transition applications. In summary, it will not be a Big Bang approach to move to Cloud overnight.

Digital Transform your Legacy System

~ Danny Kwok ~ Leave a comment

In the era of Digital Transformation, you will be shopping for new systems or SaaS (Software as a Service). Often, vendors may demo existing product or propose turnkey project can cater to all your needs. Today, I had learnt that a review to replace an existing application with a new application would be shelved. This is because a new system will take 2-4 years to customise or configure.

Cloud Transformation

Moving to Cloud is not a bed of roses if your legacy is heavily customised with no standard SOP across your global offices. You may consider to split your migration into two major steps rather than a Big Bang to Cloud. The first major step is to set a baseline for your Cloud. This usually involves standardisation or even conforming your SOP to the new Cloud platform. The second step is to determine your pilot site to be moved. This increase your Cloud knowledge and helps you understand the pros and cons in Cloud.

Application Consolidation

In a large organisation, it is not surprise to find overlapping applications and products. It is more worthwhile and cost effective to consolidate your applications. These applications may be spread out in different regions and you should always review existing applications before embarking on external review. You will also have the advantages of knowledge and data with your existing application.

Digital transforming your legacy system does not always translate to high cost of buying a new product. You can always opt for SaaS Cloud approach or review existing application to be consolidated. This way, you gain traction and speed to digital transform without wasting time, cost and efforts.

XML to JSON

~ Danny Kwok ~ Leave a comment

XML and XSLT used to be a very popular choice for integration transmission. However, this format proved to be messy and complex even with XSD in place. Then, JSON format comes around with the resurgence of JavaScript and REST service. It quickly overtakes XML as the preferred choice of integration format. This puts us into challenging mode as we move to convert XML to JSON.

Your Stack Setup

Historically, the usage of applications is directly linked to the type of integration format used. JSON is very geared towards web languages like JavaScript, Python, PHP and Nodejs. In contrast, XML favored Java and Dot Net languages. Thus, you will find difficulty for your legacy system to consume JSON. Even database is split for CLOB to XML. There is newer database like unstructured or NoSQL database for JSON. Therefore, a consideration of architecture changes may be required to leverage the advantage of integration format like JSON.

Your Endpoints

If you do not have budget and time to overhaul your architecture, you may consider focusing on your endpoints and gateway. It is common to setup integration gateway to manage the translation of XML to JSON. This provides backward compatibility to your legacy architecture. In another words, you gain more time to progressively upgrade your stack. The good part is that these integration gateway can serve as a command post to manage your endpoints.

The switch from XML to JSON is a time consuming effort. If you do not have legacy system with XML, you may want to consider having a technology stack that favors JSON. However, those with legacy and XML integration may want to lower risk with the setup of integration gateway to manage your endpoints and translation of XML to JSON.