The present subject matter described herein, in general, relates to providing infrastructure based multi-tenancy, and more particularly to providing the infrastructure based multi-tenancy without requiring modifications in legacy program code.
BACKGROUND
[002] Several Independent Software vendors (ISVs) today are facing a common challenge. This challenge hinders the ISVs from providing their software services over cloud network with multi-tenancy so that the ISVs can use the same cloud infrastructure to provide services to multiple customers in an optimized way. The ISVs have either developed program code for the offered services before the advent of cloud computing or some ISVs, even today, are developing the program code that is not providing multi-tenancy over the cloud network.
[003] Although cloud computing has revolutionized the way in which ISVs can provide software services to their customers. One approach for helping the ISVs includes providing a setup of one or more Virtual Machines (VMs) per customer, with their respective software services. This approach is expensive as each deployment needs a VM of their own which adds to the cost of implementing the software services. Another approach includes making changes in legacy program code to provide multi-tenancy in the legacy program code itself. This approach is intrusive and is associated with other challenges, such as; modifying the legacy program code might create more problems & regression in software service; and making changes in program code of a software service is very expensive option.
[004] Existing techniques fail to determine usage of services by a customer and calculate a bill based on the usage by each customer. Therefore, in a multi-tenancy based environment, it becomes crucial to determine usage of services by each customer and bill them as per their usage. Such a facility is lacked by existing services available to the customers.
[005] Thus, a method that can allow the ISVs to provide infrastructure based multi-tenancy for their software services provided to multiple customers, without making any modification in the program codes developed by program developers is much desired.

SUMMARY
[006] Before the present systems and methods for providing infrastructure based multi-tenancy, are described, it is to be understood that this application is not limited to the particular systems, and methodologies described, as there can be multiple possible embodiments which are not expressly illustrated in the present disclosures. It is also to be understood that the terminology used in the description is for the purpose of describing the particular implementations or versions or embodiments only, and is not intended to limit the scope of the present application. This summary is provided to introduce aspects related to a system and a method for hosting software services over cloud network. This summary is not intended to identify essential features of the claimed subject matter nor is it intended for use in determining or limiting the scope of the claimed subject matter.
[007] In one implementation, a system for providing infrastructure based multi-tenancy is disclosed. In one aspect, the system comprises a memory and a processor coupled to the memory. The processor may be capable of executing instructions in the memory to perform one or more steps. In the aspect, the system may receive inputs from a developer for creating a schema definition file. The schema definition file may include details related to application bits, cloud infrastructure, cloud products, metering, and billing. Specifically, the schema definition file comprises a header section including information related to cloud provider, subscription identity, and credentials. The schema definition file may further comprise a deployment section including information related to docker and container. The schema definition file may also comprise a product and plan section including information related to cloud products provided by service providers. Further, the system may launch a software service over the cloud network, based on the inputs received from the developer.
[008] In one implementation, a method for providing infrastructure based multi-tenancy is disclosed. In one aspect, the method may comprise receiving inputs from a developer for creating a schema definition file. The schema definition file may include details related to application bits, cloud infrastructure, cloud products, metering, and billing. Specifically, the schema definition file may comprise a header section including information related to cloud provider, subscription identity, and credentials. The schema definition file may further comprise a deployment section including information related to docker and container. The schema definition file may further comprise a product and plan section including information related to cloud products provided by service providers. The method may further comprise

launching a software service over the cloud network, based on the inputs received from the developer.
[009] In yet another implementation, non-transitory computer readable medium embodying a program executable in a computing device for providing infrastructure based multi-tenancy is disclosed. In one aspect, the program may comprise a program code for receiving inputs from a developer for creating a schema definition file. The schema definition file may include details related to application bits, cloud infrastructure, cloud products, metering, and billing. Specifically, the schema definition file may comprise a header section including information related to cloud provider, subscription identity, and credentials. The schema definition file may further comprise a deployment section including information related to docker and container. The schema definition file may further comprise a product and plan section including information related to cloud products provided by service providers. The program may further comprise a program code for launching a software service over the cloud network, based on the inputs received from the developer.
BRIEF DESCRIPTION OF THE DRAWINGS
[010] The foregoing detailed description of embodiments is better understood when read in conjunction with the appended drawings. For the purpose of illustrating of the present subject matter, an example of construction of the present subject matter is provided as figures; however, the invention is not limited to the specific method and system disclosed in the document and the figures.
[Oil] The present subject matter is described in detail with reference to the accompanying figures. In the figures, the left-most digit(s) of a reference number identifies the figure in which the reference number first appears. The same numbers are used throughout the drawings to refer various features of the present subject matter.
[012] FIG. 1 illustrates a network implementation diagram of a system 100 for providing infrastructure based multi-tenancy, in accordance with an embodiment of the present subject matter.
[013] FIG. 2 illustrates a block diagram of the system 100 for hosting software services over cloud network, in accordance with an embodiment of the present subject matter.

[014] FIG. 3 illustrates a User Interface (UI) of a schema definition file used for providing infrastructure based multi-tenancy, in accordance with an embodiment of the present subject matter.
[015] FIG. 4 illustrates a method 400 of providing infrastructure based multi-tenancy, in accordance with an embodiment of the present subject matter.
DETAILED DESCRIPTION
[016] Some embodiments of this disclosure, illustrating all its features, will now be discussed in detail. The words "comprising," "having," "containing," and "including," and other forms thereof, are intended to be equivalent in meaning and be open ended in that an item or items following any one of these words is not meant to be an exhaustive listing of such item or items, or meant to be limited to only the listed item or items. It must also be noted that as used herein and in the appended claims, the singular forms "a," "an," and "the" include plural references unless the context clearly dictates otherwise. Although any systems and methods for providing infrastructure based multi-tenancy, similar or equivalent to those described herein can be used in the practice or testing of embodiments of the present disclosure, the exemplary, systems and methods for providing infrastructure based multi-tenancy are now described. The disclosed embodiments for providing infrastructure based multi-tenancy are merely examples of the disclosure, which may be embodied in various forms.
[017] Various modifications to the embodiment will be readily apparent to those skilled in the art and the generic principles herein may be applied to other embodiments for providing infrastructure based multi-tenancy. However, one of ordinary skill in the art will readily recognize that the present disclosure for hosting software services over cloud network is not intended to be limited to the embodiments described, but is to be accorded the widest scope consistent with the principles and features described herein.
[018] Referring now to FIG. 1, a network implementation diagram 100 of a system 102 for providing infrastructure based multi-tenancy, in accordance with an embodiment of the present subject matter may be described. In one example the system 102 may be implemented as a standalone system 102 connected to a communication network 104.

[019] It may be understood that the system 102 may also be implemented in a variety of computing systems, preferably a cloud-based computing environment. It may also be understood that the system 102 supports a plurality of browsers and all viewports. Examples of the plurality of browsers may include, but not limited to, Chrome™, Mozilla™, Internet Explorer™, Safari™, and Opera™. It will also be understood that the system 102 may be accessed by multiple users through their devices 106-1 through 106-N. In an example, the devices operated by the users may include smartphones, tablets, phablets, laptops, smart watches, and the like. Furthermore, the system 102 may be communicatively coupled to a database for storing data. In one example, the database may be any of the relationship database and the like.
[020] In one implementation, the communication network 104 may be a wireless network, a wired network, or a combination thereof. The communication network 104 can be implemented as one of the different types of networks, such as intranet, Local Area Network (LAN), Wireless Personal Area Network (WPAN), Wireless Local Area Network (WLAN), wide area network (WAN), the internet, and the like. The communication network 104 may either be a dedicated network or a shared network. The shared network represents an association of the different types of networks that use a variety of protocols, for example, MQ Telemetry Transport (MQTT), Extensible Messaging and Presence Protocol (XMPP), Hypertext Transfer Protocol (HTTP), Transmission Control Protocol/Internet Protocol (TCP/IP), Wireless Application Protocol (WAP), and the like, to communicate with one another. Further, the communication network 104 may include a variety of network devices, including routers, bridges, servers, computing devices, storage devices, and the like.
[021] Referring now to FIG. 2, a block diagram 200 of the system 102 is illustrated in accordance with an embodiment of the present subject matter. In one embodiment, the system 102 may include at least one processor 202, an input/output (I/O) interface 204, and a memory 206. The at least one processor 202 may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuitries, and/or any devices that manipulate signals based on operational instructions. Among other capabilities, the at least one processor 202 may be configured to fetch and execute computer-readable instructions stored in the memory 206.

[022] The I/O interface 204 may include a variety of software and hardware interfaces, for example, a web interface, a graphical user interface, a command line interface, and the like. The I/O interface 204 may allow a user to interact with the system 102. Further, the I/O interface 204 may enable the system 102 to communicate with the user devices 104, and other computing devices, such as web servers and external data servers (not shown). The I/O interface 204 can facilitate multiple communications within a wide variety of networks and protocol types, including wired networks, for example, LAN, cable, etc., and wireless networks, such as WLAN, cellular, or satellite. The I/O interface 204 may include one or more ports for connecting a number of devices to one another or to another server.
[023] The memory 206, amongst other things, serves as a repository for storing data processed, received, and generated by one or more of modules 208. The memory 206 may include any computer-readable medium or computer program product known in the art including, for example, volatile memory, such as Static Random Access Memory (SRAM) and Dynamic Random Access Memory (DRAM), and/or non-volatile memory, such as Read Only Memory (ROM), Erasable Programmable ROM (EPROM), Electrically Erasable and Programmable ROM (EEPROM), flash memories, hard disks, optical disks, and magnetic tapes.
[024] The memory 206 may include data generated as a result of the execution of one or more of the modules 208. In one implementation, the memory 206 may include data 210. The modules 208 include routines, programs, objects, components, data structures, etc., which perform particular tasks or implement particular abstract data types. In one implementation, the modules 208 may include a User Identification (UI) module 212, a launching module 214, and other modules 216. The other modules 216 may include programs or coded instructions that supplement applications and functions of the system 102. The modules 208 described herein may be implemented as software modules that may be executed in the cloud-based computing environment of the system 102.
[025] The data 210 may include a repository 218 for storing data processed, computed, received, and generated by one or more of the modules 208. Furthermore, the data 210 may include other data 220 for storing data generated as a result of the execution of one or more modules in the other modules 216.

[026] In one implementation, at first, a User Interface (UI) module 212 may provide a UI to receive inputs from a developer for creating a schema definition file. In one case, the schema definition file may be present as an Extensible Markup Language (XML)/ Multi-tenancy based on Infrastructure Markup Language (MEVIL) schema. The schema definition file may include details related to application bits, cloud infrastructure, cloud products, metering, and billing. A standard established by the embodiments described successively for hosting software services over cloud network may be identified as MEVIL.
[027] Referring now to FIG. 3, a User Interface (UI) of a schema definition file used for providing infrastructure based multi-tenancy is explained. The functionalities described below could be provided using one or more tabs/ icons provided in the UI of FIG. 3, therefore, it is essential that all such tabs are referred simultaneously while the related functionalities are described. The schema definition file may comprise a header section including information related to cloud provider, subscription identity, and credentials for getting authenticated by the cloud provider. Multiple cloud providers may come into picture and every cloud may have a different way of user authentication and management of services end points. To start provisioning any infrastructure component, a user may be required to be authenticated with valid credential for a cloud provider.
[028] In one case, the header section may be developed using the below provided program code.

Cloud Provider name (Azure, AWS, GCP etc.)
xxxxxx-xxxxxx-xxxxxx-xxxxx
adminxx@xxx. com
xxxxxxxxxxxxxx
00-00-000000

< CloudAuthentication>

[029] The schema definition file may further comprise a deployment section including information related to docker and container. In one case, the deployment section may be developed using the below provided program code.

URL
< Image Type > Docker Image
< Source > GitHub

< Type>Kubernetes

[030] The schema definition file may further comprise a product and plan section including information related to cloud products provided by service providers, such as service providers like Azure, Amazon Web Service (AWS), and Google Cloud Platform (GCP). The

information related to cloud products may include name of a product, start and end date of a service, and charge frequency. The charge frequency could be set hourly, daily, weekly, monthly, semi-annually, and annually. In one case, the product and plan section may be developed using the below provided program code.

xxxxxxxxxxxxxxxxxxx
xx-xx-xxxx
xx-xx-xxxx
$0.00
Monthly
$0.00

xxxxxxxxx
$0.00
< TaxPercentage>18
< TaxType>Exclusive

******** * $0.00
< TaxPercentage>18
< TaxType>Inclusive

< Type >PerDayAfterDueDate
$0.00

[031] In one embodiment, the schema definition file may comprise a metering and billing section comprising information related to a manner of metering and charging a user for usage of the software service. The metering may be performed based on logs generated by the software service or infrastructure based performance parameters. The performance parameters may include at least one of Central Processing Unit (CPU) utilization and memory consumption. For example, a billing value of 'x' may set for 100% utilization of the CPU and a value of 'y' may be set for 100% consumption of the memory. In one scenario, a software service used by a customer would account for 50% utilization of the CPU and 30% consumption of the memory. Then, the customer may be billed a value of 0.5x for CPU utilization and 0.3y for memory consumption.
[032] The billing could also be done based on a licensing model agreed upon with customers. The metering and billing section may provide payment methods and reminders for pending payment. In one case, the metering and billing section may be developed using the below provided program code.

< Type >NonIntrusive

Webserver Logs < Unit>PerSessions
A vgCP UUtilization % < Meter ingModel>

Yes Yes
10 days

PayPal https://www.paypal. com/xxxxxxxxxxx

PortaK/Mode > https://www.xxxxxxxx.com/pay

[033] Subsequent to collecting details by one or more of the header section, the deployment section, the product and plan section, the metering and billing section, a launching module 214 may launch a software service over the cloud network, based on the inputs received from the developer.
[034] Various embodiments described above provide an infrastructure based multi-tenancy by allocating, based on a requirement of the software service, one or more docker container for each customer, for hosting the software service.
[035] Exemplary embodiments for hosting software services over cloud network, as discussed above, may provide certain advantages. Though not required to practice aspects of the disclosure, these advantages may include those provided by the following features.
[036] Some embodiments of the system and the method provide non-intrusive multi-tenancy based on infrastructure over cloud server to software applications developed in non-multi-tenancy based architecture.
[037] Some embodiments of the system and the method provide separate VMs and infrastructure such as docker container for each customer.
[038] Some embodiments of the system and the method provide non-intrusive metering & billing for targeting new customers without touching code base.
[039] Some embodiments of the system and the method would allow the ISVs to provide multi-tenancy without modifying a program code.

[040] Some embodiments of the system and the method would allow automatic provisioning on infrastructure i.e. software services provided on cloud network, based on mark-up provided.
[041] Some embodiments of the system and the method provide cost saving on infrastructure as buying and maintaining an infrastructure is expensive compared to using a cloud based infrastructure.
[042] Referring now to FIG. 4, a method 400 for providing infrastructure based multi-tenancy is described, in accordance with an embodiment of the present subject matter. The method 400 may be described in the general context of computer executable instructions. Generally, computer executable instructions can include routines, programs, objects, components, data structures, procedures, modules, functions, etc., that perform particular functions or implement particular abstract data types.
[043] The order in which the method 400 for providing infrastructure based multi-tenancy is described is not intended to be construed as a limitation, and any number of the described method blocks can be combined in any order to implement the method 400 or alternate methods. Additionally, individual blocks may be deleted from the method 400 without departing from the spirit and scope of the subject matter described herein. Furthermore, the method can be implemented in any suitable hardware, software, firmware, or combination thereof. However, for ease of explanation, in the embodiments described below, the method 400 may be considered to be implemented in the above described system 102.
[044] At block 402, a User Interface (UI) may be provided to receive inputs from a developer for creating a schema definition file. The schema definition file may include details related to application bits, cloud infrastructure, cloud products, metering, and billing. Specifically, the schema definition file may comprise a header section comprising information related to cloud provider, subscription identity, and credentials. The schema definition file may further comprise a deployment section including information related to docker and container. The schema definition file may also comprise a product and plan section including information related to cloud products provided by service providers.
[045] At block 404, a software service may be launched over the cloud network, based on the inputs received from the developer.

[046] Although implementations for methods and systems for hosting software services over cloud network have been described in language specific to structural features and/or methods, it is to be understood that the appended claims are not necessarily limited to the specific features or methods described. Rather, the specific features and methods are disclosed as examples of implementations for hosting software services over cloud network.

WE CLAIM:

1.A method of providing infrastructure based multi-tenancy, the method comprising:
receiving inputs from a developer for creating a schema definition file including details related to at least one of application bits, cloud infrastructure, cloud products, metering, and billing, wherein the schema definition file comprises:
a header section including information related to a cloud provider, subscription identity, and credentials;
a deployment section including information related to docker and container; and
a product and plan section including information related to cloud products provided by service providers; launching, by a launching module (214), a software service over a cloud network, based on the inputs received from the developer.
2. The method as claimed in claim 1, wherein the information related to cloud products include name of a product, start and end date of a service, and charge frequency.
3. The method as claimed in claim 1, wherein the schema definition file further comprises a metering and billing section comprising information related to a manner of metering and charging a user for usage of the software service.
4. The method as claimed in claim 4, wherein the metering is performed based on logs generated by the software service or infrastructure based performance parameters, and wherein the performance parameters include at least one of Central Processing Unit (CPU) utilization and memory consumption.
5. The method as claimed in claim 4, wherein the metering and billing section provides payment methods and reminders for pending payment.
6. The method as claimed in claim 1, wherein an infrastructure based multi-tenancy is provided by allocating, based on a requirement of the software service, one or more docker containers for hosting the software service.

7. A system (100) for providing infrastructure based multi-tenancy, the system (100)
comprising:
a memory (206); and
a processor (200) coupled to the memory (206), wherein the processor (200) is capable of executing instructions to perform steps of:
receiving inputs from a developer for creating a schema definition file including details related to at least one of application bits, cloud infrastructure, cloud products, metering, and billing, wherein the schema definition file comprises:
a header section including information related to a cloud provider, subscription identity, and credentials;
a deployment section including information related to docker and container; and
a product and plan section including information related to cloud products provided by service providers; launching a software service over a cloud network, based on the inputs received from the developer.
8. The system (100) as claimed in claim 7, wherein the information related to cloud products include name of a product, start and end date of a service, and charge frequency.
9. The system (100) as claimed in claim 7, wherein the schema definition file further comprises a metering and billing section comprising information related to a manner of metering and charging a user for usage of the software service.
10. The system (100) as claimed in claim 9, wherein the metering is performed based on logs generated by the software service or infrastructure based performance parameters, and wherein the performance parameters include at least one of Central Processing Unit (CPU) utilization and memory consumption.
11. The system (100) as claimed in claim 9, wherein the metering and billing section provides payment methods and reminders for pending payment.

12. The system (100) as claimed in claim 7, wherein an infrastructure based multitenancy is provided by allocating, based on a requirement of the software service, one or more docker containers for hosting the software service.
13. A non-transitory computer program product having embodied thereon a computer program for providing infrastructure based multi-tenancy, the computer program product storing instructions for:
receiving inputs from a developer for creating a schema definition file including details related to at least one of application bits, cloud infrastructure, cloud products, metering, and billing, wherein the schema definition file comprises:
a header section including information related to a cloud provider, subscription identity, and credentials for getting authenticated by the cloud provider
a deployment section including information related to docker and container for containerisation; and
a product and plan section including information related to cloud products provided by service providers; launching a software service over a cloud network, based on the inputs received from the developer.