CLOUD-NATIVE

At its core Cloud-Native is all about speed and agility.

In the past IT based systems were focused on delivering functionality to enable business capabilities.
This has more and more changed into providing tools for strategic transformation that accelerate business velocity and growth.
This is where increasingly complex IT systems meet the indispensable demand for high responsiveness, innovative features, and constant availability.

BUILDING BLOCKS

A cloud-native architecture aims to pass the challenge to provide demanding fast proceeding features while to manage overall system complexity and to ensure its reliability and scalability.
The architecture of a cloud-native application is based on six pillars:

1. Consistently modularized Service-of-Services system
   Strictly separated software modules (often called micro-services) with widely isolated storage that are integrated with defined interfaces (APIs). Each of these modules implements a clearly focused functionality with neatly manageable complexity and testability.

2. API centered services
   Providing lightweight APIs formally documented following open standards and to be consumed with open protocols, facilitate efficient interaction between the cloud-native application, client interfaces and external services. The highly formalized (standards based) technical description of the service API allows for an extensively automated code generation of interfaces consuming the cloud-native application services.

3. Containerization
   This term describes an efficient virtualization technique that supports the deployment of services as highly isolated and portable software packages. Containerized services also enable a very fine grained control of system resources at their disposal.

4. Dynamic container orchestration This is the application of automated system administration tools to dynamically manage the lifecycle and resource allocation of containers in reaction of changing operation conditions like workload, hardware failure or software updates.Container orchestration is to guarantee any expected scalability and availability.

5. Vendor neutral portability
   Cloud-native application are designed with a focus on a vast portability between cloud infrastructure environments to deliberately avoid any vendor lock-in. This guarantees a flexible choice of the most cost effective cloud infrastructure offerings and is also a prerequisite for a dynamic service deployment into the orchestrated computing infrastructure.

6. Separation of stateful components
   Technically the scaling and orchestration of stateful system components like databases or persistent storage systems is essentially different from stateless components.This requires an identification and specific treatment of stateful system components where typically the internal state of several service instances is persisted with shared database or storage systems.

BENEFITS

The central properties of a cloud-native application described above result into several advantages compared to traditional monolithic application architectures:

1. Faster Development
   An application architecture consisting of clearly separated modules allows for faster growth and change of functionality for being developed in parallel without the danger to break the entire system, also testing and deployment into a widely automated cloud infrastructure results into considerably acceleration. This allows for a faster release pace and substantially reduces the time to market which is a key differentiator from lagging competitors.

2. Enhanced Reliability and Quality
   Full application of the automated system management facilities of a cloud infrastructure allow for fault tolerance, redundant and highly available application services.The distinct functionality of each application module provides a much better testability and results into enhanced quality.

3. Reduced Operation Cost
   Containerization & standardized cloud infrastructure management processes automation and tools significantly drives down the administration and system costs.The high scalability of a cloud-native architecture allows for very cost efficient allocation of computer resources. The portability of a cloud-native application also allows for choosing the most cost effective cloud infrastructure provider or to change the provider based on best price offerings.

4. Avoid vendor lock-in
   Usage of mostly opens source based standardized cloud infrastructure means: No multi-year licensing ties into proprietary hardware, enterprice software and operating systems.
   Instead cloud-native offers fast adoption of new technologies from any provider.

About Monolithic Multi-Tenant Applications

Providing several customers with the same application services would likely cause intolerable costs with a traditional monolithic application that was operated with one instance per customer. Because of the typically required hardware and software licensing, installation and operational costs for a single instance of a monolithic application, it initially looks beneficial to reuse and share one single instance with several customers to cut down operation costs. Even a substantial growth of complexity combined with a higher development and maintenance efforts caused by the multi-tenancy of the application coming along with this approach is being considered acceptable.

But with the availability of modern cloud infrastructure tools at hand, looking at the often praised advantage of an application’s multi-tenancy, it actually appears to be rather ill-founded by the attempt to leverage the problems resulting from the complex and protracted deployment and expensive operation of a large resource hungry monolithic application.

Even more not to be ignored with the multi-tenant approach are problems with the overall data security:
Here any unnecessary complexities should be avoided or at least need to be dealt with. In the case of a multi-tenant application, special measures must not only defend against unauthorised access to the data from the outside, but now the application must also assure that the data of one tenant is kept inaccessible across all other tenants of the same application instance.
Even if any persistent data of a tenant is being stored within its own separate database, any temporary or cached data is living in the same shared memory address space of the single instance’s process. Same applies for the database connection information of all tenants. This implies that across a large number of places in the code of the multi-tenant application the exact right decision has to be made which data is to be presented to which tenant.
Since in the area of data security there is no fault tolerance, the correct handling of all these cases is definitely hard!

Furthermore the problems with data security are supplemented with the extra challenge of a multi-tenant application to warrant a fair allocation of the shared computational resources among all tenants to avoid the suffering of some tenants from serious performance issues due to a misbehaving co-tenant. Not to mention the typical lack of noteworthy scalability in case of any unforeseen performance demands.

If we now look again at a modern cloud-native application where we have one instance per customer to avoid any extra security and resource allocation problems while gaining extra benefits from reduced application complexity, enhanced scalability and cost effective operation, it should become more clear why monolithic multi-tenant applications are no longer a promising future proofed IT solution.