English | EN 
We all know about Gartner’s several Rs of application modernization – Retain, Rehost, Replatform, Refactor, Repurchase, Retire, Rearchitect 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.
- Architecture Governance: Architectural governance for choosing a right architectural framework, setting right architectural and coding practices and ensuring mechanisms to evaluate it over the application/product lifecycle is at the center of the success of cloud native development.
- Reference Architecture: Reference architecture can be different for different components of the application (IoT, Serverless, Data handling, Data processing, etc.) and will be the responsibility of the central architectural governance team. The reference architecture is a living document which constantly gets evolved and acts as a base for application component development.
- Agile mindset: Agile mindset is a must to reduce risks for project execution where we have MVPs in place and that gets constantly evolved/demoed/feedbacked over sprints.
- DevOps mindset: Rapid release of business features to market is key behind Cloud-native development adoption so it is important that DevOps tools, processes and more importantly, mindset is in place. I have seen a lot of clients getting their architectures and design documents getting reviewed from Operations team and setting ‘Operational efficiency’ as one of their architectural pillars to drive that mindset from the word go. Easier said than done, of course, and it is not a quick process. But consistent emphasize on messages and supporting tools/processes certainly bear fruits.
- Continuous Evolvement: Cloud-Native Development is not something which is done and forgotten for a long time. Again, the mindset and constantly responding to relevant technology evolutions and having a framework in place to adopt and adapt will be key to not create a system which will be ‘Legacy’ after a few years
Two important questions that could come across during discussion of Cloud Native Development.
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.
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.
