topBarLeftS

How do Single- and Multi-Tenancy, Cloud-Native and Born in the Cloud differ!

You probably wonder why I am assembling this overview of definitions. Now the explanation is very simple, lately I have been reading the latest publication / report from Gartner about "Cloud ERP for Product-Centric Enterprises". [Gartner: see references]

A lot of terms are used in the report that made me doubt if I really understood these concepts properly.

Multi-Tenant versus Single-Tenant

☛ What is Multi-Tenant Architecture? [Datamation: see references]

Multi-tenant architecture, commonly referred to as multitenancy, is a software architecture in which multiple single instances of software run on a single physical server.

The server then serves multiple tenants.

Additionally, multitenant architecture is used to enable multiple users to use a single application, for instance a database.

“Tenants” is a term for a group of users or software applications that all share access to the hardware through the underlying software.

Multiple tenants on a server all share the memory, which is dynamically allocated and cleaned up as needed. They also share access to system resources, such as the network controller.

This is the opposite of single-tenancy, in which the server runs one instance of the operating system and one application.

Multi-tenant architecture’s core advantage is that it allows exponentially more use from a single hardware or software platform.

What Is The Difference Between Single And Multi-Tenant?

Single-tenancy is largely seen as the “deluxe” option, in that a client operates in a solely dedicated environment.

In a multi-tenant environment, each customer shares the software application along with a single database, so multiple people from the same company can access the database.

Still, even in multi-tenant, each tenant is isolated from other tenants.

☛ WHAT IS THE DIFFERENCE: SINGLE TENANT VS MULTI-TENANT [Digital Guardian: see references]

Single Tenant

A single instance of the software and supporting infrastructure serve a single customer. With single tenancy, each customer has his or her own independent database and instance of the software. Essentially, there is no sharing happening with this option.

Multi-Tenantancy

Multi-tenancy means that a single instance of the software and its supporting infrastructure serves multiple customers. Each customer shares the software application and also shares a single database. Each tenant’s data is isolated and remains invisible to other tenants.

☛ Single Tenant vs Multi Tenant: SaaS Architecture [ClickIT: see references]

Today we’ll break down the differences between single tenant vs multi tenant architectures.

The main difference between them is that these software applications can serve either one or more customers at the same time.

Single Tenant Architecture

Single tenant architecture uses a software application and a database for each tenant (client).

What this means is that clients can’t share the database or application between them, because all of them have their own instances of database and applications.

We’ll try to explain how the single tenant structure system works by providing you with the real estate example, which should be easy enough to understand.

Imagine that every client has its very own office building.

All these buildings are located on the same street. The street represents the same server from which all the SaaS clients operate.

Every client runs its operations from within their buildings. The buildings are lined-up next to each other on the street.

Multi Tenant Architecture

We’ll use the same descriptive method of the above real estate example for multi tenant architecture.

Multi tenant architecture can be described as the environment in which clients are offices, but, in this case, all of the offices (clients) are located within the same building.

Every client works from its own space within a large SaaS software product, making it much more comfortable and more accessible in some cases.

The multi tenant approach models are divided into:

  • Logical Data Separation is a model that allows all tenants the possibility to utilize only one database. All of their data is securely separated within the same database by implementing unique identifiers for every client. The codebase is responsible for retrieving and storing the data via this unique identifier.
  • Physical Data Separation is another model that will successfully separate the data by utilizing different databases for different clients (tenants). Doing so helps people scale the application following the client’s growth and will also scale the application according to the clients’ needs.
  • Cloud-Native versus Born in the cloud

    ☛ What is Cloud Native? [Microsoft: see references]

    Let's start with a simple definition:

    "Cloud-native architecture and technologies are an approach to designing, constructing, and operating workloads that are built in the cloud and take full advantage of the cloud computing model."

    The Cloud Native Computing Foundation provides the official definition [CNCF: see references]

    "Cloud-native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach.

    These techniques enable loosely coupled systems that are resilient, manageable, and observable. Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil."

    The pillars of cloud native

    The speed and agility of cloud native derive from many factors. Foremost is cloud infrastructure.

    But there's more: Five other foundational pillars shown in Figure 1-3 also provide the bedrock for cloud-native systems.

    Figure 1-3. Cloud-native foundational pillars

    Microservices

    Cloud-native systems embrace microservices, a popular architectural style for constructing modern applications.

    Built as a distributed set of small, independent services that interact through a shared fabric, microservices share the following characteristics:

  • Each implements a specific business capability within a larger domain context.
  • Each is developed autonomously and can be deployed independently.
  • Each is self-contained encapsulating its own data storage technology, dependencies, and programming platform.
  • Each runs in its own process and communicates with others using standard communication protocols such as HTTP/HTTPS, gRPC, WebSockets, or AMQP.
  • They compose together to form an application.
  • Figure 1-4 contrasts a monolithic application approach with a microservices approach. Note how the monolith is composed of a layered architecture, which executes in a single process. It typically consumes a relational database.

    The microservice approach, however, segregates functionality into independent services, each with its own logic, state, and data. Each microservice hosts its own datastore.

    Figure 1-4. Monolithic versus microservices architecture

    ☛ What is cloud native? The modern way to develop software [InfoWorld: see references]

    Cloud-native definition

    Cloud-native is a modern approach to building and running software applications that exploits the flexibility, scalability, and resilience of cloud computing. Cloud-native encompasses the various tools and techniques used by software developers today to build applications for the public cloud, as opposed to traditional architectures suited to an on-premises data center.

    The cloud-native approach to building and running software was pioneered by a group of companies commonly referred to as “born in the cloud” — such as streaming giants Netflix and Spotify, ride-hailing company Uber, and accommodation booking platform Airbnb. The cloud-native approach has since been adopted by other companies looking for similar digital agility and disruptive competitive advantage.

    The Cloud Native Computing Foundation (CNCF) defines cloud-native a little more narrowly, focusing on application containerization — where applications are broken down into microservices and packaged in lightweight containers to be deployed and orchestrated across a variety of servers.

    In the CNCF’s own words: “Cloud-native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds.”

    Cloud-native app development typically includes marrying microservices, cloud platforms, containers, Kubernetes, immutable infrastructure, declarative APIs, and continuous delivery technology with techniques like devops and agile methodology.

    ☛ Cloud-Based, Cloud-Native, and Cloud-Enabled Applications — What fits your business? [ISHIR: see references]

    Cloud-native application: Cloud-native applications are architected for the public cloud. Due to being designed specifically for the cloud, it can harness the full power of cloud using cloud-based technologies. These are made on the microservice architecture and comprise continuous integration, container engines, and orchestrators, making them highly flexible and scalable.

    Cloud-enabled application: Cloud-enabled application is any traditional app developed in a legacy system and then upgraded to work in the cloud. These apps were initially intended to operate on-premise, with local resources and hardware, but later migrated to the cloud, where they use the virtual resources and inherent capabilities of the cloud to gain the cloud advantage.

    Cloud-based application: Cloud-based apps serve as a hybrid – the best balance between cloud-native and cloud-enabled. A cloud-based application doesn’t need infrastructure upgrades, but it also doesn’t run to the fullest power like a cloud-native app. Essentially, it leverages the capabilities and resources of the cloud to run the app without the need for a complete overhaul.

    Referenties

    Three Composable Commerce Myths [Jason Cottrell]

    Enterprise suites are no longer “the safer choice." The MACH ecosystem is. It is agile and nimble, always up to date. [MACH Alliance]

    What is a Platform Ecosystem? [Partner Fleet]

    What Is Composable ERP? [RootStock]

    Staan NetSuite en Microsoft ERP/WMS al op uw WishList? (12 juni 2022)

    Het Gartner® Magic Quadrant™ for Product-Centric Enterprises - editie 2022 [Gartner]

    😍#mensenwerk met een vleugje #technologie😏