Abstract: As well as deploying new applications to the cloud, many organizations will also be considering the opportunities to migrate current applications to the cloud in search of reduced costs or SLA improvements. In this research note we consider several migration alternatives, expressed as a set of patterns.
The patterns can also be seen as a sequence of activities, through which the current application is gradually modernized.
A fundamental question will be the extent to which a pattern applies to the migration to a public or private cloud, or both.
Architecturally, there should be no difference. But from a capital or operational expenditure perspective, an organization seeking to reduce costs will not want to invest in a private cloud to just improve the SLA of applications running on a niche platform. That said, if an organization invests in a private cloud for its core platforms, but it is also one that can purpose instances of the niche platform on-demand, then that may be a viable option.
The use of a public IaaS provider will be dependent on their ability to support the platform. They may provide
That is not to suggest that a private cloud doesn’t face licensing issues. Issues of multi-tenancy and virtualization may not be well dealt with by the niche or legacy platform on a license basis. But that is beyond the scope of this note.
Organizations can start by considering whether the application is suitable for simply migrating “as is”.
Figure 1 – Application Re-Hosting Pattern
As illustrated in figure 1, the current architecture is simply mirrored in the cloud deployment, but can take advantage of virtualization to not only reduce operational expenditure (OpEx), but also to create multiple instances of the application to improve the SLA with scalability and failover without increasing the capital expenditure (CapEx).
The key risk is that underlying architecture issues not addressed. A monolithic legacy app in the cloud is still a monolithic legacy app. Hence scalability is on a coarse-grained basis and may not be easy to achieve if for example the internal architecture doesn’t lend itself to the database being updated by multiple instances of the application.
A variation on this is illustrated in figure 2, where only the database component of the application is re-hosted. The general benefits of re-hosting still apply.
The key determinant for this is the separation of application logic and database components in the current application. For many client/server style applications already using a database server this should pose little problem. The most obvious scenario for this is for “thick client” applications where the application logic is deployed to multiple desktop and laptop clients, and not to an application server.
Figure 2 – Database Re-Hosting Pattern
Simply re-hosting the current application to the cloud does not make it service-oriented, even though the underlying cloud platform itself might be. Existing APIs do not become REST or SOAP services just because it has been re-hosted. Hence it may be difficult to integrate with other applications.
The well-known service façade pattern is not specific to application migration, but is likely to be used together with the application re-hosting pattern in order to provide REST or SOAP service interfaces that allow programmatic access to the re-hosted application. Here the pattern is given a cloud perspective.
Figure 3 – Service Facade Pattern
As figure 3 shows, this requires a wrapper around the native API of the existing application that does the necessary schema and protocol conversion to provide a service interface. This helps to decouple the application from consumers (loose coupling) and provided platform independent interoperability. This pattern can also apply to database re-hosting.
If the goal is specifically to improve the performance aspects of the SLA, then there may be steps that can be taken to achieve that, which don’t necessarily require the complete re-architecting of the application.
For example, as figure 4 illustrates, throughput may be better managed by adopting the principle of writing to a queue and reading from a cache. The queue front-ends the application and helps to smooth out peaks in transactions, whilst the cache takes the load off the application for simple reads.
This isn’t going to help where the application is accessed most often via its embedded UI. However, in addition to the above, data could be replicated to a simpler table or flat file structure that optimizes reads. Or the database could be partitioned, or non-relational data segregated onto a separate instance. This would help in either UI or service interface based access.
Whilst these same actions could be taken for the current in-house deployment, leveraging the capabilities provided by IaaS and PaaS make these more viable without the associated CapEx required. A combination of the capabilities offered by Amazon AWS for example, such as the Simple Queue, Simple Storage (S3) or CloudFront may make these enhancements relatively straightforward.
Figure 4 – Re-host and Optimize
There is however, a limit to how much can be achieved through the optimization pattern. As stated earlier, a monolithic legacy app migrated to the cloud is still a monolithic legacy app.
Moreover, the application migration to the cloud may be under consideration as part of a broader application modernization initiative, where the goal is not just to re-host the application in the cloud but to address new business and IT requirements that demand a more agile, fine-grained architecture of services and software that is not provided by the as-is implementation.
Hence figure 5 illustrates that the application is re-architected into a set of independent services and automation units that encapsulate their own data – we will refer to these as integrity units. Each integrity unit can be independently deployed and its SLA optimized to its unique profile. The componentized implementation improves scalability – with individual automation units for each service. The deployment of high-usage components can be optimized independently of low-usage ones. Whilst a parallel design can provide better throughput.
The major risks here are that an application is modernized in isolation, and not as part of a portfolio that ensures consistent service and information architecture. Or that modernization is done primarily for technical reasons resulting in continued sub-optimal response to business change.
Figure 5 – Re-Architect
An outcome of re-architecting an application is that it can utilize a hybrid cloud deployment. This is a likely scenario, where components of the application are deployed independently to both public and private clouds.
A further likely scenario is illustrated in figure 6, where components of the re-architected application remain deployed on their current platform, whilst the remainder is deployed to the cloud.
Either of these scenarios might be triggered for example by a requirement to keep sensitive data in-house. Or perhaps where integration requirements demand a component remains deployed on its current platform. Or some feature of the current app cannot be replicated on the cloud platform.
If this is the case, then of course there is no option other than to re-architect the application as simply re-hosting it will not suffice.
Figure 6 – Re-Architected Hybrid
In this scenario some form of ‘service bus’ is used as a mechanism to both integrate the different components of the application regardless of their deployment location, and also to further decouple the service consumers from the complexity of the deployment architecture. Moreover, it enables the provider to continue to refine the architecture without impacting the consumer. For example, there may be an orderly migration of the components from the currently platform to the cloud platform rather than a big bang approach.
The service bus might be the existing Enterprise Service Bus (ESB) that an organization already has in-house. Or it could be a capability that is part of the cloud platform, for example by Microsoft Azure’s AppFabric
As mentioned in the re-architect pattern, one risk is that an application is modernized in isolation. Whilst the architecture of the new application might be greatly improved, the opportunities to improve consistency and reduce cost through consolidation and sharing across a portfolio are missed.
As figure 7 shows, Applications A and B are re-architected and migrated as a component-based portfolio offering shared services or capabilities common to both.
It is likely this will happen in stages. The business users of Application A may be unwilling to sit patiently by waiting until the migration of Application B is also completed. There are ways to mitigate this that are beyond the scope of this research note. For example, the service architecture may be developed first to act as a façade across the current applications. New solutions can then be assembled using these services, whilst the underlying applications are re-architected and migrated behind the scenes.
Figure 7 – Portfolio Migration
Re-architecting an application provides an opportunity to re-evaluate provisioning decisions for each capability contained in the application. The opportunity is greater when modernization is undertaken on a portfolio basis.
Analysis of business requirements should identify a set of required capabilities. Current systems analysis on the existing application then identifies which of these capabilities could be supported by the current system in its re-architected state.
However, it should not be a given that where there is a match that the existing capabilities are re-engineered. Rather, each capability should be evaluated to see if some alternative provision can be made – for example by use of a Cloud Service, or a COTS component that can be deployed to the cloud. Clearly this decision would be made on the assumption that the alternative provided some additional benefit, such as reduced cost compared to re-engineering, reduced time to solution, encapsulation of best practice, better SLA, etc.
Traditionally, organizations provision and deploy the business capabilities they require on a coarse-grained whole application basis. They purchase an ERP, an HR, or CRM application for example. However, this typically results in the tight coupling of these capabilities within these coarse-grained applications, which leads to inflexibility, and as explained earlier their deployment to the cloud cannot be fully optimized. Moreover, with a purchased application there is no opportunity for the end-user organization to re-architect.
Cloud Services presents an opportunity for the capabilities to be provisioned on a more fine-grained basis. However, it is also true that many Cloud Services are still implemented as a monolith behind the service façade which may lead to dependencies between services that requires they are provisioned on a “suite” basis.
In large organizations there may be thousands of different applications in use. Many of them are non-core applications that are quite independent, serving some specific niche business or ‘utility’ need. These may be obvious candidates for straightforward re-hosting.
For more integrated applications and or those considered core to the business, then re-architecting is a more likely requirement. Core business applications should best be considered as a part of a wider application portfolio modernization strategy, and not re-architected and migrated to the cloud in isolation.
In these cases, it is important that the service architecture is considered top-down to match business requirements, not just bottom-up based on the existing applications. This is necessary to better provisioning decisions.
Figure 8 shows that as suggested in the introduction, these patterns might be viewed as a sequence of activities by which an application is gradually migrated to the cloud and refined. For the reasons given throughout this research note, in many situations the initial steps of re-hosting may only be possible in a private cloud scenario. Only later once the application has been re-architected can a hybrid public/private deployment be considered.
Figure 8 – Sequence of Migration Patterns
However, there is no simple rule here and each application will have to be evaluated on its own merits.
KeyWords: Cloud Computing, Application Modernization
CBDI Journal Report - CBDI-SAE Application Modernization Process
CBDI Journal Report extract - The Agile Application Modernization Project
Everware-CBDI Case Study - Application Modernization - Portfolio Pathfinders.
CBDI Journal Report - Service Portfolio Planning and Architecture for Cloud Services
Download the PDF Version below for an extended version of this research note with the above patterns documented using the standard "problem/solution" pattern template. (free registration required)