The dynamics of business have changed. Not just as a result of the global pandemic, although it has served to amplify and accelerate many of the business functions and supply chains that make the world go around, but also due to the wider impact of cloud, connected commerce and mobile device ubiquity.
Top-down is now bottom-up
There has been a marked reversal of momentum in many aspects of the technologies we are using. Organisations used to use top-down development practices as the primary rationale for the platforms they adopted and the applications and services they developed. Users largely took what they were given, only opting to complain if they really felt like a fight.
As a blanket IT development policy, that practice no longer works. Users have become empowered and have been able to put the power of choice into their own hands. If flexibility and functionality aren’t up to standard, users will move on, so enterprise IT now has to accept the reality of bottom-up user-driven development.
At the same time, IT teams around the world are transforming datacentre operations (spanning people and processes) and shifting infrastructure investments towards highly automated solutions to now focus on business-centric (rather than infrastructure-centric) decisions.
This is the point of flux at which organisations will need to assess which applications, which workloads and which data repositories they put where across a hybrid cloud landscape now spanning both public and private on-premises resources. It can feel like a mammoth task, so what aspects or IT operations should the business be thinking about?
Calculating workload lifecycle
Most organisations’ C-suite teams will know they have some data and understand that they operate a database to serve it. Equally, they will be aware of a certain amount of the organisation’s application base, some of which they will inevitably use themselves in the normal course of business.
What these upper C-suite managers are unlikely to know is the rather more granular detail that lies under the surface of these data resources and applications. With decisions surrounding cloud migration responsibility now coming to the fore, a business will need to examine the stage and nature of an application and data workload’s life cycle and the value to be attained by moving each workload to the cloud.
There is no single model for a workload lifecycle calculation, but if there were, it would be a calculation based upon a piece of technology’s mission criticality, its place in the business value chain, its number of touchpoints with users, partners and customers, plus also its fit into the governance and compliance responsibilities that the company has to adhere to.
If the above factors stem from business variables as validation points, then there will also be a corresponding set of IT operations variables that will help ‘describe’ an application’s workload lifecycle status. These factors would include (but are not limited to) its use of memory, the number of data analytics calls it makes, its Input/Output (I/O) requirements and the amount of processing power it requires.
Retain or retire, not rip & replace
Naturally, some application workloads will not be easily migrated to the cloud in an economically viable manner. For these workloads, they should remain on existing platforms or be migrated to an updated traditional infrastructure, which can now be delivered with on-premises cloud deployments.
Other application workloads will be at a stage of their lifecycle where the most prudent course of action is to retire them. Possibly due to discontinued support from the original vendor when deployed in the cloud, or more likely due to the fact that superior cloud-based alternatives exist, the case for securely managed retirement is made.
Whether a workload is retired or replaced with a public, private or hybrid cloud alternative, organisations must make all decisions methodically and carefully only after a full evaluation process has been carried out. Any idea of a rip and replace process should be avoided at all costs.
Are we there yet?
Once all those thoughts are processed and the business has further evaluated the privacy and security factors needed to assess which workloads need to stay on-premises, which are suitable for public cloud breath and which need to straddle the hybrid world in between… can we ask whether we are there yet?
The answer in the always-on essentially dynamic world of cloud is often yes, but also think about xyz. Other key factors will include cloud skill set availability in the existing workforce. Organisations will need cloud-migrated and cloud-native skills not just to bring application and data workloads to the cloud, they will also need these competencies to build new cloud services and operate the total cloud estate once instances are ‘spun up’ and in motion.
The level of cloud skills an organisation has access to will organically determine the degree to which it can deploy, leverage and expand upon all types of cloud resources, particularly public cloud. For organisations with limited cloud skills, it may make sense to start by using cloud platforms as a form of data protection target for traditional infrastructure.
The path to cloud migration
The actual process cloud of migration may be a combined mix of the four Rs: rehosting, refactoring, rearchitecting or replacing, which is another story in and of itself. What we can say is that an organisation in any business vertical that takes stock of these core factors is on the road to taking advantage of cloud computing technologies at the right time, in the right workflows, at the right cadence and at the right price point.
Cloud migration can be something of a cocktail given the diversity of ingredients (workloads), the range of shakers and blenders (migration vehicles and techniques), the number of serving vessels and glasses (workloads endpoints and user interfaces) and the additional promise of a cherry on top or a twist of lime (cloud accelerators, visualisation dashboards and so on) if required.
Cloud is a cocktail, but take a considered approach and you can avoid a muddle.