Sizing the Beast
In my 20-year span of SAP Technology BASIS, DBA, OS -seen it all- career, nothing could be as interesting as the topic of Infrastructure architecting and sizing. To the DBA it is the clichéd – ‘Science as well as an Art’. To the CIO – it’s that cost, requiring just justification, yet needed to be maintained to the bare minimum.
And yet today, even with Cloud on demand infrastructure available at your fingertips providing elasticity, scalability and the likes, Sizing-Computing, Storage and Network-continue to remain that clarion call the CIO has to make. In many ways than one-the CIO retains the ubiquitous position of the captain of that ship which has to speed the dark cold waters and at the same time avoid the proverbial Iceberg.
Today, in the age of Transformers (the movie!), at the flick of a click, we can get cloud resources, on demand, ‘scaled up’ , transforming Meek servers into Mean Beasts and back again into Transformers.
Though it sounds too good to be true-it is! But the journey to the Cloud- like many journeys, is not wholly a bed of Roses, and has its own constraints, a plethora of hidden factors that are assumed and those not assumed. The devil, as they say is in the details, in some cases, the devil is in the dark.
The devil—or call it details—goes by various names; Assumptions, Constraints, Factors, Costs, Considerations-to name a few of them.
Allow me to ruminate on a few seemingly unassuming though interesting ones I have encountered on the journey—Licensing, Compatibility, Service Level Agreements, Security, Regulations.
Let me start by touching a supposedly non-technical yet an interesting one-Licensing. The best things in life are free, for the rest of course one has to pay. Consider OS and DB licenses which were ‘bundled’ together while procuring on-premise hardware, the good ole days when SAP and Enterprise software would run on ‘real’ servers. These licenses-many of them (if not all) of the OS/DB licenses may not be easily portable to public cloud platforms, without incurring additional delta fees for running them on a public cloud OS/DB, assuming it is technically possible and/or certified by the vendor to run them, that is.
The second one being Compatibility. Undoubtedly, if at all there would be an abused term in cloud migration parlance, “lift and shift” would be the term. Prima facie what is wrong in: Stopping the application, Lifting, Shifting, and starting the application, except that one caveat. ‘Dinosaurs’ were not designed for ‘Jurassic Park’ neither was ‘Jurassic Park’ designed for them. Our Dinosaur applications—let’s call them with due respect by their names, ‘Legacy Applications’—were neither designed nor certified to run on public cloud platforms. If one of these Apps do make it to the ‘Park’ they may never have been vendor “certified” to run on the public cloud , and what that means if the dinosaur goes bad.…. No one’s coming.
The third though not the least is the all-time favorite topic of SLAs – especially Availability/HA/clustering, a very touchy topic which always evokes spontaneous reactions from technical, functional, business alike, something that I as Tech Arch always pondered why as to? But in many ways than one – the quest for the elusive promised land of the 99.999% remains a holy grail. SLAs (Service Level Agreements-for the uninitiated, sigh!) are the promises given by the on-premise hardware vendors, on the on-premise infrastructure. These SLAs may or rather do not necessarily hold good for the same architecture on the Public Cloud.
Consider the SLA of High Availability. On-premise, an uptime SLA of 99.95% availability may have already been baked in the on-premise system (though this does not imply a NEED for it). Similar would be the case for RTO and RPO levels. What this means is that the SLA discussion on required/expected/accepted levels, have to be brought back again to the table, most importantly driven by business considerations. Assuming these levels to be the same for the given architecture on the public cloud architecture, would turn out to be the rude shocker that this architecture will not work on the public cloud to support those SLAs.
As they say, ‘Wants are many, needs are few’. Not to get me wrong, machines will fail, redundancy will need to be factored in, but the architecture on the premise cannot be assumed to be the same for the Cloud, for the given levels of SLAs. The sooner this realization dawns on all, the lesser will be the heartbreaks.
Last, though not the least, among the ‘vital few’, are the “other” aspects, perils overlooked that have the potential to snowball into an avalanche. Network Connectivity, Security, Legal and Govt Regulations on data (at rest/in transit), E2E Integration testing are those important discussions that need to be on the overall agenda.
To sum in all -most of the above challenges -can be fixed by Architecture, Vendor agreements, licensing discussions, but the important point is to have a discussion and awareness of the challenges ahead and prepare for the same.
With all these set of challenges on the Journey to Cloud-One may wonder is it feasible to move to Cloud. The clichéd answer is “It depends” and what it depends on is the “Business Case”. Many cases it may be “Yes” and in many “No”. But the entire exercise of Value Realization of a Cloud migration itself, is a unique soul-searching experience unique to the organization. An effective balance between Business Objectives and Costs is the thin line the CIO has to walk through practically every living moment.
A Cloud Migration is thus a crucial joint responsibility for all eco-system partners – Application vendor, Cloud provider, the customer, the Architect, the BASIS DBA, and the Customer Execs. The ship will leave the harbor, only if each of the teams support and work in the same direction with each other!
That said and done – nothing is as fulfilling as completing the entire procedure to see the application start and run as planned.