We all know about Gartner’s several Rs of application modernization – Retain, Rehost, Replatform, Refactor, Repurchase, Retire, Re-architect and Rebuild.
All Rs are important in the given context and a decision of which R to go with often depends upon carefully evaluating if the problem (if at all) of the current application lies in the platform, technology, architecture, coding or operations.
‘Rebuild’, of course, holds its place of importance when it comes to long term application transformation. Rebuild is to rewrite the application from scratch while preserving its scope and specifications. In the context of Cloud, we often term it as ‘Cloud-Native Development’ which is doing application development with most or all of the components (Database, event bus, queuing, API management, etc.) using Cloud services AND using Cloud-based architectural patterns (For example, Serverless).
As I had mentioned in my earlier blog, Cloud-native development is perceived as a costly and long process but as I had highlighted in my earlier blog, it need not always be a complete big bang rewrite of the entire system. We can start decomposing system in modules or components (Database, event bus, etc.), convert them into APIs and slowly move parts of it on Cloud using Cloud services/architectural patterns.
Following are the important aspects that need to be considered or practiced for the adoption of Cloud Native development:
Business Case Development: Before cloud-native is put into action, it is important to do a formal assessment of the existing legacy application and do prepare a business case. Cloud-native development need not be cost-effective for the entire application portfolio. Business critical legacy applications suffering from performance, consistent downtime, scalability constraints and high cost of maintenance can be an ideal candidate for Cloud-Native Development.
Some tools like CAST can be used to assess the static quality of code and there are many run time performance testing tools to evaluate run-time quality (Performance and scalability) of the code. These parameters along with the cost of maintenance (skills availability, all incidents history, critical incident history, time required to troubleshoot incidents, time required to detect incidents, average time to do simple/medium/complex changes, and release frequency restrictions) can be used to reach to current actual and notional costs. Cost of development of cloud-native applications and improvement in cost of maintenance along with business benefits it will bring (rapid deployment of new business functionality to market) can help develop a business case.
Two important questions that could come across during a discussion of Cloud Native Development.
1) Can Cloud Native be hybrid development? Yes, it can be and rather, it is recommended. So, you have some components in one cloud and some in other and they interact with each other through integration frameworks is a way to go forward.
2) What about vendor lock in? Eternal question and there is always compromise between flexibility vs lock in. But careful usage of hybrid cloud, containerization and more levels of design abstractions can reduce vendor lock in.
If you are starting to think about what this will mean for your business, Sogeti can help you to take the first concrete steps towards getting the right answers and solutions for your organisation. Contact us today to start the conversation.