Many organizations have started their journey to the Cloud. As they complete their infrastructure migration, organizations realize that most of the value and intelligence they could get from the cloud are in the consumption of PaaS workloads for their applications. Cloud-native apps are perfectly designed and shaped into small and loosely-coupled components running on highly scalable, replicable, available Cloud services.
That’s great for new applications, but the big / core critical applications are still stuck on-premises, mostly due to pure software engineering reasons that have concrete blockers to PaaS adoption. Without fixing these issues, migrating applications to take advantage of PaaS services will take longer and cost more money. I was pleasantly surprised to see that we’re not the only ones to apply this kind of analysis. In doing research for an upcoming eBook we’re writing, I ran across this great article by IBM…
As Kyle Brown and Mike Capern were pointing it out in their paper back in 2014 (“Top 9 rules for cloud applications – The dos and don’ts of making your application cloud-ready“), a majority of Cloud blockers are not related to the CSP you’re targeting. Indeed, most of the technical roadblocks you could encounter during a Cloud migration of an on-premise and monolithic application are purely platform-agnostic and take on a poor level of software abstraction. At that time, no one could imagine that the underlying app infrastructure (i.e. the machine and/or the OS where the app was running) could change, restart, scale without disturbing the application behavior in production. At that time -and we’re talking about mid-2000’s here, not about the dinosaurs’ era- it might be obvious to use the Windows registry to store application settings, very common to develop stateful apps (user sessions information stored within the application not in the browser) or to call resources on hardcoded IP addresses through HTTP (and not HTTPS).
A few examples of cloud blockers that Brown and Capern really well summarized in 9 rules:
Information like this really helped me as I was documenting the Cloud patterns we’re adding in Highlight around the detection of unsupported functions in Azure SQL Databases (the first series of platform-specific blockers we’re scanning in our Transact-SQL analyzer). I was very happy to see that our list of Cloud requirements perfectly fits into these 9 rules. These software engineering principles, such as avoiding implementing OS-specific features (removing DLLs is PIA), to use the local file system or non-standard protocols … are valid and applicable advice for PaaS migrations. And it’s always good news when, as a Product Owner in the Software Analytics space, the smartest guys from a major Cloud player like IBM advise to fix the problems you already spot with your product.
Examples of Cloud requirements and blockers found in code with CAST Highlight
Over the last 25 years, CAST has leveraged unique knowledge on software quality measurement by analyzing thousands of applications and billions of lines of code. Based on this experience and community standards on programming best practices, Highlight implements hundreds of code insights across 18+ technologies to calculate software health factors.
Developed with some of the smartest Cloud experts across the globe, Highlight helps you quickly and objectively assess your application portfolio for PaaS migration. It automatically builds your migration strategy by identifying where to start, quick wins, and applications that will take longer to migrate. Where a Cloud expert could spend weeks to measure the capability for a single application to move to PaaS, Highlight CloudReady makes it possible on the entire portfolio – in only days. Highlight uses 100 + different code patterns to detect issues that make an application harder to migrate and run smoothly in the Cloud. Track issues like the use of COM components, usage of middleware, usage of system DLLs or impersonate identity – and monitor improvements over time.