Cloud migration: From monolith to microservices

(c)iStock.com/Andrey Prokhorov

A cloud migration project can be a relatively simple exercise, where applications are migrated ‘as is’, to gain benefits such as elastic capacity and utility pricing, but without making any changes to the application architecture, software development methods or business processes it is used for.

There may be a clear business for doing so, such as the hardware platform becoming obsolete; however the organisation overall won’t realise any additional benefits – there is no business transformation as part of this move.

With senior executives potentially expecting broader strategic capabilities as a result of a move to the cloud, it’s therefore important that clarifying this scope is the very first step in planning a cloud migration, and the OMG’s Architecture Driven Modernisation (ADM) methodology is ideal for this purpose.

As the ADM ‘horseshoe’ model articulates, and this Carnegie Mellon article shows, a migration project can be considered with three distinct tiers of scope possible, increasing the size and length of the project with an increasing level of associated business benefit.

This begins at a technical migration, meaning the application is migrated ‘as is’ to a new hardware infrastructure service without modification.

Breaking innovation gridlock: harnessing DevOps and microservices

Higher levels then include application and data architecture and business architecture, meaning that as well as shifting platforms the application itself is also transformed and then furthermore, so is the business model that it enables.

As the horseshoe describes, these increases in scope mean a larger project that takes longer, because each is delivering a larger scope of business benefits, impacting a larger group of stakeholders and requiring a larger business transformation exercise.

Exploring the nature of these benefits can help specify exactly what business executives are hoping to gain by moving to the cloud, and this can be headlined by a theme of “breaking innovation gridlock”, described in this whitepaper from HP.

In short, this described how most large enterprise organisations have a legacy application estate, made up of elderly technologies like mainframes running COBOL, that perform the core business processes of the organisation and are thus central to the business value they provide, but because of their age have become rigid, inflexible and fragile business systems.

Due to the complexity of these environments and the lack of staff skilled in these technologies they essentially become untouchable black boxes, the CIO can’t take the risk of downtime by trying to make changes, and due to their age their maintenance is very costly, consuming the majority of their budgets as HP describes.

Thus they have become trapped in a state of innovation gridlock, unable to afford investment in new digital-enabling platforms and unable to adapt legacy systems to offer new customer-centric processes.

Enterprise DevOps

Although moving to IaaS can deliver benefits such as elastic capacity and utility pricing for infrastructure level components, this isn’t really of strategic value to most large organisations as they aren’t constrained in these areas.

Instead where the major business value will come from is modernising this legacy environment, transforming the core enterprise applications to new cloud-centric approaches so that innovation gridlock is broken and a faster cycle of development throughput is achieved.

A variety of tools are available that can automate the process of transforming legacy code like COBOL into their modern equivalents on Java and .net, meaning they can be re-deployed to private or public Cloud services and most importantly, then much more easily modified by software developers, setting the scene for an agile Enterprise DevOps culture and faster change cycle achieved through Continuous Deployment practices.

Furthermore leading edge Cloud architecture principles can also be utilized, such as ‘Microservices’. This means breaking up large monolith software, like mainframe systems, into an array of small self-contained services making it even easier to implement change at a faster pace. As described in our Microservices section pioneering organizations like Nike have adopted this approach.

Conclusion

An especially powerful aspect of these legacy transformation solutions is that they can also automatically generate the new code required for key features such as a web front-end and mobile client.

This would provide the foundations for achieving the enhanced functionality that senior executives are likely hoping for from their cloud investments. As they seek to pioneer their digital strategies enabling ‘omnichannel’ access across web and mobile interfaces the IT team would previously have faced a considerable challenge achieving this goal when working with aged application environments.

By employing the full scope of architecture driven modernisation they can quickly accomplish this important capability while also transforming the environment so that additional innovative enhancements can more easily be engineered too on an ongoing basis.

With web and mobile platforms established this then makes possible the full three-tier scope of ADM transformations. Business executives can more easily build social communities around their core business processes, explore dynamic new mobile commerce scenarios, and so on. In short the only limitation of the innovative business models they might pioneer would be their imagination, not the IT estate.

The post Cloud Migration: From monolith to microservices appeared first on Cloud Best Practices.

Related Stories

Leave a comment

Alternatively

This will only be used to quickly provide signup information and will not allow us to post to your account or appear on your timeline.

ChrisNerney
22 Jun 2015, 6:06 p.m.

Transitioning to the cloud requires planning around strategic business goals. (http://bit.ly/1D0n01Z) -- Chris Nerney, commenting on behalf of IDG and Microsoft

Reply