HomeNewsExpert NoteModernizing an online core business platform into a Cloud-Native solution

Modernizing an online core business platform into a Cloud-Native solution

With a global pandemic, many businesses have had to respond to changes in customer behavior, industry regulation, and shifts in development partnerships.

Transforming a platform to meet these changes needs to be motivated by clear goals:


  • Short time to market - Prompt delivery to meet the changing demands of business and be able to respond to emergent opportunities.
  • Support future growth – Design to support future growth without requiring considerable changes. Eliminating the need to plan for hardware acquisition and integration.
  • Market adaptability - More flexible and scalable solution to cope with changing and volatile market demands.
  • Resilience & availability – Resilience to fault/outage in the resulting solution. High availability and ability to run in a healthy state with no significant downtime.
  • Security – Strong security to meet compliance requirements and protect customer and proprietary data as well as reputation.


To reach these goals one must adopt a strategy. Starting with choosing a cloud service provider, may this be a private cloud or one of the hyper-scaler public clouds. Making such a choice is easier after undertaking smaller innovation cloud-based projects, providing feedback from this concrete experience into the decision-making.


When opting for a hyper-scaler cloud service provider, another strategic option becomes available: favoring Platform-as-a-Service (PaaS) over Infrastructure-as-a-Service (IaaS). This enables the development team to focus on what matters the most: added value business features.


Another key element of the strategy is the isolation of each business domain through the adoption of a microservices architecture enabling both technical and organizational scalability.

The Solution

The time to market is shortened by making regular and more frequent releases. Going from months between releases to two weeks in a sustained rhythm. With shorter development cycles, changes are tested sooner. This is enabled by Infrastructure as Code and Continuous Integration / Continuous Deployment.


  • Infrastructure as Code (IaC)

To speed up and guarantee consistency in the operation of the cloud-native environments, infrastructure is provisioned and configured via IaC. The desired state of the cloud infrastructure is defined using code as opposed to manual processes or complex imperative scripts.


  • Continuous Integration / Continuous Deployment (CI/CD)

Both the IaC and the application code for each microservice are integrated and deployed continuously via DevOps pipelines. These pipelines allow more than just building the code artifacts and deploying them. They are well suited to orchestrate additional automated checks like code analysis for quality, unit testing for functionality, Static Application Security Testing (SAST), Dynamic Application Security Testing (DAST), integration testing, performance, and load testing. 


This approach enables a focus on quality and security concerns earlier in the development cycle, which helps reduce the risk of vulnerabilities and defects in the final product. This leads to a better-quality solution that meets security standards and satisfies user requirements.


  • Hyper-scale

By opting to deploy on a hyper-scaler, a large cloud services provider that can provide enterprise-scale computing, storage, and other services, our cloud-native solution can be rapidly scaled to meet changing demand. Cloud resources can easily be reconfigured or provisioned as needed without the lengthy and costly process of acquiring, setting up, and hosting additional hardware.


A hyper-scaler also helps us achieve high availability and resilience to faults by offering us data centers with highly redundant hardware which themselves have redundancies. Providers like Azure and AWS offer multiple availability zones, distinct zones engineered to be isolated from failures. Therefore, to mitigate the failure of an availability zone in a region, the data and workloads can is replicated in several other availability zones.


For example, Azure offers two regions within Switzerland maximizing available redundancy within the same country. Typically, the Switzerland West Azure region can be used for disaster recovery of Switzerland North workloads.


  • Domain Driven Design

A Domain Driven Design approach facilitates market adaptability by aligning the technical implementation with the business domain. This results in each business domain being implemented as a separate service independently delivered by a dedicated team. These dedicated teams can vary in size as their domain requires allowing for organizational scalability. Therefore, the solution adopts a micro-service architecture, each service being able to scale independently.


  • API Management

These micro-services are made available via an API Gateway on which we publish the APIs each domain offers. From this service, a catalog and technical documentation for those APIs facilitates their discoverability. Additionally, cross-cutting concerns like token validation, caching, throttling and handling service unavailability are managed via policies.


  • Monitoring

To achieve operational excellence, troubleshoot issues, and validate security, it is essential to monitor the many components of a cloud-native solution. This is done with the cloud service’s native monitoring service allowing us to observe the health, dependencies, and performance of the entire solution and be alerted of abnormal conditions.


  • Security

In addition to the monitoring of the solution, a threat detection solution is put in place. Threat detection allows us to proactively identify potential security threats and take action to prevent or mitigate them before they can cause harm.


Monitoring is important to good security but only part of the overall security design. General cloud architecture best practices and best practices recommended by the hyper-scaler are applied to the design and implementation. 


Platform as a Service works on a shared responsibility model where the cloud service provider is responsible for securing the underlying physical hardware, network, and software. Those designing, developing, and operating solutions built on top of those services, have the responsibility of properly configuring them, manage access, secure workloads, and other aspects depending on the service.


At ELCA we have recently supported a company active in gaming in the modernization of its online platform into Cloud Native solution on Azure.


The benefit of implementing these elements in a solution is a reduction of operational complexity which results in a smaller operational team. The customer also receives a more standardized stack, therefore, reducing integration partner lock-in. By moving workloads and using a cloud services provider the solution benefits from the provider’s knowledge and capabilities in security and commodities-as-a-service (database, compute, storage, monitoring, ...).


The new solution also offers improved elasticity allowing it to scale to match business needs whether they may be short or long-term. And by having opted for a microservices architecture, that elasticity is combined with great organizational flexibility. Allowing each business domain to evolve and new domains to be rapidly added while organization-wise, the teams developing these domains, can also grow and evolve as needed.



As World-changing events have greatly impacted many industries, transforming to a cloud-native solution brings in many short and long terms benefits including the ability to be better prepared for future unexpected events.

Philippe Cuvecle

Lead Architect

Meet Philippe Cuvecle, our Lead Architect specialized in cloud transformation and cloud-native architectures. Contact Philippe to discuss how he can help propel your cloud transformation initiatives forward.

Related Content