Modern Applications: Adaptability and scalability

The ability to adapt and scale your IT environment can lead to the difference between business success and failure. Typically, when presented with such challenges, organizations, due to business pressures, often make trade-offs, which introduce technical debt and suboptimal systems.

However, by following the below principles, organizations can become adaptable and scalable, and embrace the inevitable change which is central to a cloud native environment.

Agile Architecture: Just-in-Time and Just Enough Architecture

The recognition of this issue has led to the concept of the Just-in-Time (JIT) with Just Enough Architecture (JEA) approach which aims to align architecture processes with DevOps more closely.

The purpose of this approach is to avoid big design upfront costs. By building ‘just what it takes’ to meet the current requirements, we have a product-centric approach with an iterative way of release in conjunction with continuous user feedback.

Furthermore, this approach should be aligned with your organization’s architecture inventory. It should also be balanced (i.e., not too little) to reduce the likelihood of creating tech debt e.g., rigid and not extensible solutions.

Beware of technical debt with the Single Responsibility Principle

Typically, when software systems are developed with sub-optimal practices, they may accumulate technical debt, which is the ultimate cost of maintaining and supporting such systems over their lifespan.

Also, tech debt can occur with emerging technologies or shifts in IT strategy.

For both scenarios, a good practice is the single responsibility principle – which means that single responsibilities should not be spread over multiple services.

However, cloud native architecture as a service delivered to a user is composed of several different parts. Therefore, as it is easy to deviate from the single responsibility principle, you must be vigilant and try to stick to this principle as much as the system allows.

Technical debt is a risk – do not let it go unchecked.

Build business-focused serverless functions

Along with the performance benefits and enhanced speed of development, serverless functions are a major asset for scalability. Their many benefits include reduced operating costs (as you only pay for what is used), adaptability (as it is no longer necessary to plan traffic peaks), a lack of server maintenance, and developers can deploy code without managing servers. 

By separating the orchestration of events and management of events, a developer focuses on a simple process triggered by an event – which can be tested manually.

However, organizations must define microservices based on architecture components and think of them as simple and fast actions. Failure to do so may create complex workflows and add complexity to your architecture.

Lastly, it is worth highlighting that containerization is still a popular approach. Both serverless functions and Kubernetes offer distinct advantages for scalability and adaptability, each with its own set of trade-offs. The choice between them depends on your specific business needs and technical requirements. 

Ultimately, the best approach depends on your specific use case. Serverless functions excel in scenarios with variable workloads and event-driven architectures. Arguably, it’s also the option which best allows for a business-focused approach.

The ability to change is related to the ability to recover

There are many reasons why service interrupting events can happen such as network outages, cyber attacks or even natural disasters. With a well-designed and tested cloud-based Disaster Recovery (DR) plan, the impact on the organization should be minimal. Yet, there will likely be some level of impact and the plan should be to minimize the recovery time.

It is important to define what a disaster is, and that your plan reflects this definition, and the impact it may have on business outcomes. Also, the plan must be analyzed, implemented, and tested. Plans that have not been validated risk not being implemented due to a lack of confidence or failure to meet disaster recovery objectives.

Cloud native services can be categorized into three groups with each group acquiring a different DR plan.

1. Data persistent services

Services with stored data must be retained during a failover to a secondary region in case of a disaster. Once the services are back online, the data should fall back to the primary region. Regular snapshots of data and copying it to the secondary region or setting up data replication between data stores and services is a good approach.

2. Code based services

These services are mostly implemented in a container, PaaS services or a serverless function. A way to plan for such services is to deploy them in multiple regions simultaneously.

3. Global Services

These tend to be regional services and therefore are deployed in specific geographical regions by a cloud provider’s distributed global platform. While these services may experience degraded performance or site slowness, the chances of complete disruption are extremely low due to their global footprint.

Disaster Recovery is the ultimate expression of adaptability. Always plan ahead and have a solution for your systems to work – and recover – even when components fail. 

Summary

Once an organization becomes cloud native, it has never been in a better position to become adaptable and scalable due to the inherent architect of the various platforms. By planning ahead and adhering to key principles, the ability to adapt and scale will be built into your processes thus allowing you to continuously evolve and get the most out of today’s and tomorrow’s technology.

Sogeti and Microsoft have been strategic partners for more than 25 years. Together to demonstrate the strength in our technical alignment we bring you the latest eBook: ‘Start in control and stay in control – five cloud native adoption principles for enterprises’.

Learn more about these business benefits and to download the eBook.