Enabling your existing “pre-cloud” enterprise applications to take full advantage of cloud computing is fraught with technical obstacles, such as unsupported versions of operating systems (OS), monolithic architectures that are tightly integrated with enterprise data stores or file storage, and difficulty in meeting stakeholder expectations (including cost reductions).
When “greenfield” applications adopt cloud-native architecture, they suffer much less from the burden of these challenges, but these new applications only make up a small percentage of an organisation’s application portfolio.
A typical legacy application rehosted on infrastructure as a service (IaaS) migrated using a “lift and shift” approach cannot take full advantage of every cloud characteristic. Organisations that follow this rehosting approach often discover that the migration team took shortcuts and came up with workarounds just to get the applications running.
These shortcuts and workarounds arise because the goal of rehosting was to move the application in a time-sensitive manner and support other, more significantly modified applications that are already running on the cloud. The comprehensive assessment for cloud-native readiness was never performed on the legacy application, which resulted in poor outcomes.
One of the areas to consider is that a typical legacy application relies on traditional relational database management systems (RDBMS) and atomicity, consistency, isolation and durability (ACID) transactions for strong data integrity.
These traditional databases rely on the underlying infrastructure to be rock solid and reliable. They are not built for environments where the infrastructure is fluid or prone to failure. These databases are also built to scale up, not out, which impedes your ability to utilise the abundance of cloud resources and to elastically scale your application.
However, contemporary application design takes advantage of polyglot persistence to optimise database behaviour for specific use cases. This concept allows developers to choose the data storage that best suits the data and their programming approach rather than forcing the data to fit into a traditional Structured Query Language (SQL) model. Using RDBMS for all data storage can lead to inflexibility in your design and significant costs in scaling the database.
Adopting cloud computing requires careful planning and a deep understanding of how your existing applications might impede migration to a cloud-native architecture. Gartner clients often cite poor planning and inappropriate migration strategies as reasons for sub-standard cloud adoption. Without planning and structure, decisions will be made inflight just to get the application running. This will lead to misalignment with stated project goals.
Setting goals
Cloud migrations typically encompass a mix of applications, some of which are due for an overhaul or an update and can benefit from what the cloud offers. These initiatives have varying business goals from one organisation to the next. The decisions, processes and people behind the initiatives are specific to each organisation. However, Gartner has identified and outlined several recurring technical goals.
It is critical that specific business goals guide an organisation’s cloud modernisation efforts and that stakeholders throughout the organisation are aligned with those goals. For instance, not all application modernisations will require rebuilding. You may not need to change how your database is partitioned for improved scalability for a given application if that is not one of its cloud migration goals.
Building an effort scorecard
Gartner proposes a framework for application modernisation, representing an architecture assessment with specific hotspots.
The effort required to modernise an application should be established by assessing how each hotspot inhibits the business objectives of the migration. The more easily changeable your application is, the less work, effort and resources you will need to adopt cloud-native architecture patterns and principles.
This step requires you to build an effort scorecard that will be populated while analysing each hot spot during the rest of the assessment.
Modernisation inhibitors
Two major inhibitors increase the effort of modernisation of your applications – coupling and complexity.
Coupling can be viewed as the number of interdependencies within and outside your application. For example, from a code perspective, you would examine how blocks of code interact with each other and the call graph – including how the methods, classes and functions are composed. A script or block of code that is reliant on different code blocks is considered coupling.
Compounding the coupling issue is the complexity of your architecture and code. Application components that are tightly coupled and heavily dependent on the underlying software and hardware specifics can lead to complexity. This complexity limits your deployment, runtime and hosting options when targeting cloud-native platforms. It is important to implement abstractions and encapsulation of those underlying dependencies and components that are similar and change at the same time. In this sense, complexity means having dependencies that are hard to fulfil. Application-level dependencies – for example, dependencies between components of the application – can also play a part.
An assessment of your application will reveal the depth of coupling and complexity within the application. It will allow you to determine the overall effort required to modernise each of these hotspots within your application. Depending on these varying degrees of modernisation, you may choose different strategies for different portions of your code.
Modernisation level is linked directly to business goals. If the application is changeable enough to meet those goals, refactoring the code and modernising the application to a cloud-native platform can be sufficient. If the effort level to modernise is high across the board, you may have no choice but to rebuild the entire application. However, you also can rearchitect and rebuild individual components if, for instance, your modernisation level is low from an application architecture standpoint and high from a data persistence standpoint.
Other challenges
In a cloud environment, you are attempting to build a reliable application using an abundance of unreliable components that have the potential to fail – often in ways that are different from the kind of application component failures you might see on a single machine. Cloud computing requires an architecture that will work in an environment with ephemeral resources that favour horizontal over vertical scalability.
Cloud-native architectures will balance the benefits the cloud has to offer, along with the areas that are different and outsourced to the provider, thus limiting your control over them. Your organisation’s motivations for moving to the cloud are additional scalability, expansion of the business to adopt new channels, and reducing the resources when demand decreases. This can lead to an unpredictable load that varies from normal day-to-day operations.
Utilising native, managed services in your cloud provider will also introduce latency into your application because your application components are now distributed across a network. Cloud-native architects also need to take into account that some cloud service failures, systematic failures and security breaches are entirely out of their control.
There must be an overall shift in mindset from the leadership level to understand when and where cloud-native principles apply in the application portfolio. Leadership must empower individuals to continuously learn and improve on these lessons in the context of your organisation. Make cloud-native modernisation an inherent part of your application maintenance cycles. Heavy investment in organisational change processes is needed because cloud innovation outpaces existing organisational processes and culture, and breaks existing processes.
This article is based on the Gartner report “How to modernise your application to use cloud-native architecture” by Eklove Mohan, senior director analyst at Gartner.