In an earlier post on migration, I looked at different ways to take a codebase and convert it for a new architecture. The methods work best when the language is being kept the same, though the last idea, of taking the original code in small chunks and reworking those chunks as components of the new solution could probably be done across languages.
One thing to consider, though, is whether replatforming makes software better. Why might we replatform?
- The existing platform is no longer supported – e.g. an old Operating System or runtime
- The existing platform has a huge security risk – e.g. unsecured services, or place in the network
- The cost of running a component is high
- The reliability is low
- Scalability
- Data centre strategy
- Difficulty of maintenance
On the whole, it’s hard to argue against the idea that a piece of enterprise software, presently deployed in a cumbersome way/environment, would not be better as a cloud-native application running cheaply at scale in the cloud.
Let’s Argue Against It
A badly thought out migration project could be a little like finding a few screws loose in an engine, and rather than repairing them, buying a fleet of taxis instead.
The apparent cost savings of cloud migration must always be set against the risk and cost of making the move.
Put simply, it cannot be cost alone that motivates us to do a cloud migration. I’ve heard numbers like this component is $10k/month cheaper to run now. But on a project that cost, say $1million, that’s a lot of months before you get the money back. (It’s 8.3 years for those people who can’t be bothered to calculate it)
Similarly, the biggest risk with any replatforming comes from whether it’s really clear what the software is meant to do, and how well we can test that, in its new form, it’s getting equivalent results for the business.
All the bad software engineering that makes us dislike the original, can get amplified by a replatforming effort.
Architecture Doesn’t Fix Process
At the heart of any replatforming effort is a question about the future needs of the business process for which the component was originally built.
Lifting and shifting the code has the effect of repeating the failures of the original process, possibly with added transcription errors.
So the objective must be to review the go-forward process and look to make it leaner and more fitting for the organisation. This must be done within the scope of the engineering effort, and not become a huge barrier to entry for the product. There’s no reason to reinvent the whole world, but there’s no reason to believe that creating a replica of the original is a good idea.
The Original Pattern May Not Fit The Future Architecture
Part of the problem with replatforming is that the target platform may not agree with the paradigm of the original component. This can lead to an egregious hybrid.
The egregious hybrid:
- Looks like the legacy architecture, but is running in a new environment
- Doesn’t work like it should in the new environment, owing to the legacy
- Has all the bugs of the legacy
- Plus some bugs introduced when migrated
- Is hard to support because it’s unfamiliar to everyone
Any project which starts with the phrase let’s just lift and shift runs the risk of hitting this. Swapping like for like components is attractive, and it frequently appears to work, but it doesn’t necessarily land the software in the most desirable state.
The most desirable state for software is that it is lean, effective, and at the lowest level of complexity. It should look like it was designed like that intentionally.
Breaking The Lift and Shift Cycle
While at the micro level, lifting and shifting may be appropriate – say for algorithms or data structures – at a higher level, there are some other thought processes that may help:
- In the new world what’s the core of the business process?
- Can we migrate incrementally?
- If migrating incrementally can we release incrementally?
- Do we need all the original feature set?
- Are there any simplifications we can make to the flows?
- Can we avoid complex, unnecessary, or old-fashioned design patterns?
- Can we get closer to the source data?
- Can we put the output closer to the intended destination?
The fundamental, and most difficult question of all will be to work out how to validate that the new software does the intended job. This may involve reverse engineering specifications, tests, or example data sets with expected answers.
Just rewriting some code is never the core problem with a re-platforming exercise. Any re-platforming project defined in terms of code will run the risk of missing the point entirely.
Published on Java Code Geeks with permission by Ashley Frieze, partner at our JCG program. See the original article here: The Pleasures of Replatforming Opinions expressed by Java Code Geeks contributors are their own. |
It is easy to read blog for the readers by adding subtitles. It is really helped me a lot in the field of
<a herf=”https://techigai.io/cloud-replatforming-for-businesses//”>software replatform </a>