epm blog

Rebuild in the cloud – 3 considerations for cloud-native development

Gartner’s Rs of application modernization will be familiar to most readers – Retain, Rehost, Replatform, Refactor, Repurchase, Retire, Rearchitect and Rebuild.

All these Rs are important in the given context and a decision on which R to choose often depends on carefully evaluating if the problem (if at all) with the current application lies in the platform, technology, architecture, coding or operations.

In this article, I focus on ‘Rebuild’, which 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’. This sees application development being carried out with most or all of the components (database, event bus, queuing, API management, etc.) using not only cloud services, but cloud-based architectural patterns too, such as serverless.

Cloud-native development is perceived as a costly and long process but it need not always be a complete big bang rewrite of the entire system. We can start decomposing the system in modules or components (database, event bus, etc.), converting them into APIs and slowly moving parts onto cloud using cloud services/architectural patterns.

So, with the above in mind, here are three key considerations to bear in mind for the adoption of cloud-native development:

  • Business Case Development: Before you move ahead with cloud native, it is important to carry out a formal assessment of the existing legacy application and prepare a business case. That’s because cloud-native development may not be cost-effective for the entire application portfolio. However, business critical legacy applications suffering from performance, consistent downtime, scalability constraints and high maintenance costs can be ideal candidates for cloud-native development.
    • Some tools like CAST (computer aided software testing) are available for assessing the static quality of code and there are many run time performance testing tools for evaluating the code’s run-time quality (performance and scalability). You can use these parameters to help calculate current actual and notional costs. Further, determining the cost of maintenance will give you a broader picture, so take time to measure 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. Calculating the cost of cloud-native application development and the improvement in maintenance costs will support your development of a business case, which should also include potential business benefits, such as the rapid deployment of new business functionality to market.
  • Architecture Governance: Putting architecture governance at the center of your cloud-native development is crucial to ensuring its success. This governance is needed for choosing the right architectural framework, setting the right architectural and coding practices and ensuring mechanisms are in place to evaluate the code over the application/product lifecycle.
    • Reference Architecture: Depending on the different components of the application (IoT, serverless, data handling, data processing, etc.), the reference architecture will also be different, and will be the responsibility of the central architectural governance team. The reference architecture is a living document that is constantly evolved and acts as a base for application component development.
    • Agile mindset: Insist on an agile mindset to reduce project execution risks where minimum viable products (MVPs) are in place and being constantly evolved, demoed and fed back on over sprints.
  • DevOps mindset: Rapid release of business features to market is integral to cloud-native development adoption, so it is important that DevOps tools, processes and, more importantly, mindset are in place. I have seen a lot of clients getting their architectures and design documents reviewed by the Operations team and setting ‘Operational efficiency’ as one of their architectural pillars to drive that mindset from the word go. This is easier said than done, of course, and it is not a quick process. But consistent emphasis on messages, along with the supporting tools/processes, certainly bear fruit.
    • Continuous evolution: Cloud-native development is not something that’s done and then forgotten about. It is an ongoing evolution and, again, the right mindset and constantly responding to relevant technology evolutions are crucial. As is having a framework in place to adopt and adapt so that you are not creating a system that will be ‘legacy’ after just a few years.

Two important questions might arise during discussions of cloud-native development:

  • Can cloud native be hybrid development? Yes, it can be. Indeed, it is recommended. So, the way to move forward is to have some components in one cloud and some in another interacting with each other through integration frameworks.
  • What about vendor lock in? This is an eternal question and there is always compromise between flexibility vs lock in. But careful use of hybrid cloud, containerization and more levels of design abstractions can reduce vendor lock in.

As your journey to the cloud continues, I hope the above has given you a flavor of some of the best practices for cloud-native development.