Migrating your on-premises workload to the cloud using the Cloud Native development scenario offers numerous advantages, such as increased scalability, flexibility, and cost savings. By following the step-by-step process outlined in this document, you can ensure a smooth and successful migration.

This post demonstrates how we can get started with Application modernization using Cloud Native Development approach.

This post is the continuation of the previous article on App Modernization scenario where we covered App re-host, and containerization in detail.

Overview:

Let’s look at the picture that talks about the Journey to the Cloud.

Monolithic apps that provide strategic enterprise functions might best benefit from a Cloud-Native approach.

The right migration strategy depends on organizational priorities and the systems you’re targeting. For many, it may be more cost-effective to cloud-optimize a monolithic application or add coarse-grained services to an N-Tier app. In these cases, you can still make full use of cloud PaaS capabilities like the ones offered by Azure App Service.

Cloud Native development:

The Cloud-Native modernization maturity level usually requires new development investments. Moving to the Cloud-Native level typically is driven by the business need to modernize applications as much as possible to drastically improve scale in large applications by creating autonomous subsystems (microservices) that can be deployed and scale independently from other areas of the application while lowering costs in the long term and increase evolution agility of those autonomous app’s parts that provide significant compete advantages.

The main pillars of Cloud-Native applications are based on microservices architecture approaches, which can evolve with agility and scale to limits that would be difficult to achieve in a monolithic architecture, deployed to either on-premises or cloud environment.

Below picture shows the main characteristics of the Cloud-Native model.

Cloud-Native is a more advanced or mature state for large and mission-critical applications. Cloud-native applications usually require architecture and design that are created from scratch instead of modernizing existing applications.

Cloud-optimized apps can be Microservices based or monolithic web apps or N-Tier apps.

The Twelve-Factor App (a collection of patterns that are closely related to microservices approaches) is also considered a requirement for cloud-native application architectures.

The Cloud Native Computing Foundation (CNCF) is a primary promoter of cloud-native principles.

Business drivers

Let’s take an example for a customer who is experiencing tremendous growth and has determined that their applications need a major redesign to meet the anticipated growth and future business demands.

Below are the business drivers for this Digital Transformation:

• Provide enterprise-grade IT systems solutions to support ever-changing business dynamics.
• Provide excellent customer-centric user experience with better B2C interfaces and SSO.
• Scale customer base rapidly with minimal technological impediments.
• To have Enterprise integrated technology platform to support IoT, Web portal, Mobile application (and an E-commerce – B2C application).

Migration goals

Let’s assume the Customer has below system for Digital Transformation and needs Cloud Native development:

Web:

Leverage Microsoft Azure HA and Scalability features to support the following:

• Scalable applications to support 1 million users and 10,000 concurrent users.
• Ability to provide backward compatibility with the legacy member, coach, and other data.
• Secure application with threat management on SQL Injection, DOS.
• Responsive web application for better user experience and usability.
• HTML 5 support
• Automated API testing against business core APIs
• Screen loading in under 6-8 seconds.

Mobile member:

• Support offline data synchronization.
• Native mobile application with Android and iOS smartphone support.
• Support mobile phones with Android versions 5, 6, 7, and 8 and iOS versions 10 and 11.

IoT:

• Design for High Availability and Scalability.
• User manual for IoT Solution.

CRM Integration:

• Secure Restful APIs with OAuth
• Under 2 Second response time with CRM

Additionally, below are NFR:

Solution design

It’s time to design the solution, let’s look at the current architecture and propose a new one.

Current architecture

Understand the current system, review the current system, Functional requirements, System components, Integration point, and Database details.

Also, understand the Non-Functional requirements, such as Performance, Monitoring, Security, Scalability, Configuration management, and Availability.

Let’s assume that below are the Current System details.

• Client uses Legacy WebApp (developed in LAMP).
• It is accessible online and has login using LDAP.
• Data is being saved in MySql database.
• It also interacts with CRM using Batch job integration.

Assessment:

App and Data Modernization

Cloud Adoption Security Review

Proposed architecture

The proposed solution for the current client should be focused on focused on implementing identified set of patterns as the First objective; functional aspects of the system covering the key functionalities is another objective of this solution.

Among all the nonfunctional requirements security is one of the key aspects and is expected to be implemented in the following aspects –

• Ensuring Transportation level security between the caller & core solution
• Centralized Identity & Access Management Process using Active Directory
• Centralizing Access to the APIs through SSO, OAUTH
• Key-based authentication for accessing the APIs.

Enforce authorization for more fine-grained access to microservices.

Based on Customer requirements below are the key solutions available, and the solution needs to be selected based on technology, and customer IT roadmap.

• Web App: options for SPA, Angular, or React
• DB: Cloud PaaS database, SQL, and No SQL
• CRM Integration: using API with Security features.
• IoT: (Optional)
• Mobile: (optional)
• Platform: Azure or AWS

Based on the above details, let’s assume that the Customer decided on technologies.

Create a logical view of these components.

Logical View:

Create a Logic View of the proposed architecture, it includes below components:

Solution Architecture:

Below are a few recommended articles for designing the web app for our case.

Web architecture design – Azure Architecture Center | Microsoft Learn

Let’s have a look at the proposed Solution Architecture.

Serverless web application – Azure Architecture Center | Microsoft Learn

Solution Components:

Solutions will be developed utilizing cloud-native components using Azure, and the solution will leverage Multi-Regional high availability sets for increased availability & scalability.

The solution has below components:

Web Layer

The web layer hosted as part of Azure Web Apps instance has Angular JS, CSS3, and jQuery.

Static image files pertaining to the solution will be hosted in Azure Storage, whereas the Azure CDN will work to distribute content according to the region from where a user connects to the application.

The JSON data structure exposed by API Orchestration layer will be utilized by Angular JS for direct consumption.

API Orchestration Layer:

API Orchestration Layer will be the key layer for the proposed solution, and it will consume CRM API/restful services and any API exposed by IoT. After consuming the response from CRM API, it will apply its own business logic and will expose RestFul Services to Web and Mobile App.

Azure Storage/Blob will be holding relevant log information to support monitoring and telemetry data for all these integration points (like request-response time for CRM, IoT interaction, etc..)

Azure Redis Cache will be holding frequently referred to entities facilitates to refer it by all the hosted APIs.

Storage/DB:

Azure Storage like Table/Blob will be used for logging errors and for monitoring. The solution will also use Cosmos DB for device registration/activity. CRM used in the solution is Microsoft SaaS offering and acts as a backend DB.

Note: IoT and Mobile related solutions are out of the scope of this post. We will cover this in detail in another post.

Design Patterns/Solution Components Description:

Application Development

Reliable web app pattern

Reliable web app pattern – Azure Architecture Center | Microsoft Learn

The reliable web app pattern provides essential implementation guidance for web apps moving to the cloud. It defines how you should update (re-platform) your web app to be successful in the cloud. The reliable web app pattern focuses on minimal code changes, reliability design patterns, and managed services so you can rapidly adopt the cloud.

 12 factors

Use below 12 factors as guidelines to help steer the development of new applications, as well as to create a scorecard with which to measure existing applications and their suitability for the cloud:

1. Codebase: One codebase tracked in revision control, many deploys
2. Dependencies: Explicitly declare and isolate dependencies
3. Configuration: Store configuration in the environment
4. Backing Services: Treat backing services as attached resources
5. Build, release, run: Strictly separate build and run stages.
6. Processes: Execute the app as one or more stateless processes
7. Port binding: Export services via port binding
8. Concurrency: Scale out via the process model
9. Disposability: Maximize robustness with fast startup and graceful shutdown
10. Dev/prod parity: Keep development, staging, and production as similar as possible.
11. Logs: Treat logs as event streams
12. Admin processes: Run admin/management tasks as one-off processes.

Azure Well Architecture Framework

Use Azure Well Architecture Framework and define Reliability, Security, Cost Optimization, Operational excellence, and performance efficiency for each service used for the proposed solution.

Identity Services

SPA, Web Apps

Web API and APIM

Storage (Azure SQL, Cosmos db, Blob, etc.)

Security

The solution must consider security implementation in all layers across the components including API, Azure Functions, static storage, queues, messages, web forms/SPA & the back-end systems.

SSL with assymetric keys with 256 encryptions must be enforced across the layers & components and specific security measures across each interaction & component.

Below are the security design considerations followed for web app:

• Microsoft Identity Provider:  The Microsoft identity platform helps you build applications your users and customers can sign in to using their Microsoft identities or social accounts. It authorizes access to your own APIs or Microsoft APIs like Microsoft Graph.
• Microsoft Active Directory hosted on-premises should be designed to work with Azure Active Directory, Microsoft Identity Platform for authentication & authorization.
• Auth Flow: Solution components, such as API Gateway, Angular JS, connecting the flow will be interlinked to facilitate Single Sign On through OAuth and must be designed to use Authentication Flow, OAuth 2.0 Authorization code flow (with PKCE)
• API Gateway & Azure functions would be provisioned with throttle limits to prevent any sort of Denial-of-Service attack to the underlying implementation.
• API Gateway will be provisioned with Subscription keys to ensure single unified access to the API Gateway Component.
• CORS will be enabled for the specified domain to restrict Cross-Site Request Forgery attacks that potentially lead to URL mishandling.
• ESAPI Framework implementation will be utilized for preventing any sort of attacks specific to OWASP such as SQL Injection, Cross Site Scripting patterns.

The Microsoft identity platform supports authentication for different kinds of modern application architectures. All of the architectures are based on the industry-standard protocols OAuth 2.0 and OpenID Connect.

By using the authentication libraries for the Microsoft identity platform, applications authenticate identities and acquire tokens to access protected APIs.

Scenarios and supported authentication flows

Scenario: Accessing API from WebApp (SPA)

As per the proposed solution, SPA needs to consume all the API for Business Logic, and thus all the API endpoints must be secured.

In our case, it is SPA, and in this scenario, the Application run on a web browser and has different authentication characteristics than traditional server-side web applications.

The Microsoft identity platform provides two options to enable single-page applications to sign in users and get tokens to access back-end services or web APIs.

You have below options:

• OAuth 2.0 Authorization code flow (with PKCE). The authorization code flow allows the application to exchange an authorization code for ID tokens to represent the authenticated user and Access tokens needed to call protected APIs.

Using the authorization code flow with PKCE is the more secure and recommended authorization approach, not only in native and browser-based JavaScript apps, but for every other type of OAuth client.

• OAuth 2.0 implicit flow. The implicit grant flow allows the application to get ID and Access tokens. Unlike the authorization code flow, implicit grant flow does not return a Refresh token. It is also less secure, so it’s recommended to use the authorization code flow for new applications. This authentication flow does not include application scenarios that use cross-platform JavaScript frameworks such as Electron and React-Native. They require further capabilities for interaction with the native platforms.

The OAuth 2.0 authorization code grant type, or auth code flow, enables a client application to obtain authorized access to protected resources like web APIs. The auth code flow requires a user agent that supports redirection from the authorization server (the Microsoft identity platform) back to your application. For example, a web browser, desktop, or mobile application operated by a user to sign into your app and access their data.

authorization code

Apps using the OAuth 2.0 authorization code flow acquire an access_token to include in requests to resources protected by the Microsoft identity platform (typically APIs). Apps can also request new ID and access tokens for previously authenticated entities by using a refresh mechanism.

Note:

ADAP has been deprecated, so use MSAL  Microsoft Authentication Library (MSAL).

The implicit grant flow is no longer recommended – use authorization code with PKCE instead.

Solution review

Plan to have Governance and CoE for your migration and review the solution and its implementation from time to time.

List out-of-scope items, Risks, and Blockers from time to time.

All the deliverables mentioned in the document will have the acceptance criteria of being signed off by the Client PM for proceeding to the next logical phase.

Migration methods

Plan your Project and have below details at high level.

• Onboarding Resources, Access
• Analysis phase
• Design phase
• Implementation phase (Sprints)

Implementation:

It’s time now for implementation, start your project with all the above steps.

Deployment and Automation:

We explored Angular, APIM, Web API, and Backend DB for the solution.

The application is deployed in PaaS Service, below is one reference for automated deployment for this Solution.

DevTest and DevOps for PaaS solutions – Azure Solution Ideas | Microsoft Learn

Monitoring

Monitoring is the act of collecting and analyzing data to determine the performance, health, and availability of the business application and the resources that it depends on. An effective monitoring strategy helps understand the detailed operation of the components of the application. It also helps increase uptime by proactively notifying us of critical issues so that they can be resolved before they become problems.

Below are our key metrics for Monitoring.

Application Insights

We are using Azure Application Insights to monitor the availability, performance, and usage of the application, whether it’s hosted in the cloud.

Azure Monitor

Azure Monitor enables core monitoring for Azure services by allowing the collection of metrics, activity logs, and diagnostic logs. For example, the activity log tells us when new resources are created or modified.

Web application monitoring on Azure – Azure Architecture Center | Microsoft Learn

High Availability

Design for high availability for your solution.

Highly available multi-region web app – Azure Architecture Center | Microsoft Learn

Conclusion

In this article, we covered details on how we can plan to modernize legacy Web App with modern SPA and start your Cloud Native Development journey.

In an upcoming post, we will deep dive on below topics:

• Design Cloud Native SPA using Angular.
• Design Web API, APIM.
• Design backend data for this solution Azure SQL, Storage, Cosmos DB.
• Security Guidelines.
• Deployment best practices and DevOps
• Monitoring best practices and tools set up.

Stay tuned for further posts.

Details of upcoming blogs.

1. Designing Cloud Native SPA using Angular:

– We will discuss the key principles and concepts behind designing a cloud-native SPA using Angular. This will include understanding the benefits of a cloud-native approach, architecture patterns, and best practices.

2. Designing Web API and APIM:

– We will explore the process of designing Web APIs and how to leverage Azure API Management (APIM) to manage and secure these APIs effectively. This will include topics such as API design principles, authentication, authorization, and how to expose and consume APIs securely.

3. Designing Backend Data for the Solution:

– We will dive into the different options available in Azure for storing and managing data in the backend of our cloud-native SPA. This will include Azure SQL, Azure Storage, and Cosmos DB. We will discuss the pros and cons of each option and how to choose the right data storage solution based on specific requirements.

4. Security Guidelines:

– Security is a critical aspect of any application. We will provide comprehensive guidelines on how to design and implement secure features in our cloud-native SPA. This will include topics such as authentication, authorization, data encryption, and protecting against common security threats.

5. Deployment Best Practices and DevOps:

– We will explore the best practices for deploying our cloud-native SPA to Azure. This will include topics such as infrastructure as code (IaC), continuous integration and continuous deployment (CI/CD) pipelines and leveraging Azure DevOps for automating the deployment process.

6. Monitoring Best Practices and Tools Setup:

– Monitoring is essential for maintaining the health and performance of our cloud-native SPA. We will discuss the best practices for setting up monitoring and alerting in Azure. This will include topics such as Azure Monitor, Application Insights, and other relevant tools for monitoring and troubleshooting.

Stay tuned for our upcoming posts, where we will provide in-depth insights into these topics. We are excited to share our knowledge and help you design robust and scalable cloud-native SPAs using Angular.

References:

Introduction to cloud-native applications – .NET | Microsoft Learn

What about Cloud-Native applications? – .NET | Microsoft Learn

Introduction to cloud-native applications – .NET | Microsoft Learn

The Twelve-Factor App (12factor.net)

What is Cloud Native? | VMware Tanzu

Microsoft identity platform overview – Microsoft Entra | Microsoft Learn

JavaScript single-page app scenario – Microsoft Entra | Microsoft Learn

Microsoft identity platform app types and authentication flows – Microsoft Entra | Microsoft Learn

Microsoft identity platform and OAuth 2.0 authorization code flow – Microsoft Entra | Microsoft Learn

DevTest and DevOps for PaaS solutions – Azure Solution Ideas | Microsoft Learn

Web application monitoring on Azure – Azure Architecture Center | Microsoft Learn

Highly available multi-region web app – Azure Architecture Center | Microsoft Learn