Patent Application
20150341445
On-premise software delivery model is a model of software deployment that involves an enterprise to purchase hardware such as servers, to invest capital into software licenses, to invest into dedicated IT staff for maintenance and support, etc. On-premise is the traditional model of software deployment where enterprises deploy applications in-house, e.g., on the premises of the enterprise. The initial investment for the on-premise computing infrastructure is typically high, but may pay off long term. One advantage of the on-premise model is that the enterprise has control over the systems and data. On-premise platforms are considered more secure than cloud platforms as corporate data is stored and handled internally, e.g., within an internal private network.
Cloud computing is a widely adopted and evolving concept. Generally, cloud computing refers to a model for enabling ubiquitous, convenient, and on-demand access via Internet to shared pools of configurable computing resources such as networks, servers, storages, applications, functionalities, and the like. There are a number of benefits associated with cloud computing for both the providers of the computing resources and their customers. For example, customers may develop and deploy various business applications on a cloud infrastructure supplied by a cloud provider without the cost and complexity to procure and manage the hardware and software necessary to execute the applications. The customers do not need to manage or control the underlying cloud infrastructure, e.g., including network, servers, operating systems, storage, etc., but still have control over the deployed applications. On the other hand, the provider's computing resources are available to provide multiple customers with different physical and virtual resources dynamically assigned and reassigned according to clients' load. Further, cloud resources and applications are accessible via the Internet.
The claims set forth the embodiments with particularity. The embodiments are illustrated by way of examples and not by way of limitation in the figures of the accompanying drawings in which like references indicate similar elements. The embodiments, together with its advantages, may be best understood from the following detailed description taken in conjunction with the accompanying drawings.
Embodiments of techniques for hybrid applications operating bets teen on-premise and cloud platforms are described herein. In the following description, numerous specific details are set forth to provide a thorough understanding of the embodiments. One skilled in the relevant art will recognize, however, that the embodiments can be practiced without one or more of the specific details, or with other methods, components, materials, etc. In other instances, well-known structures, materials, or operations are not shown or described in detail.
Reference throughout this specification to “one embodiment”, “this embodiment” and similar phrases, means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one of the one or more embodiments. Thus, the appearances of these phrases in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.
Companies may select either to run an application fully on-premise or fully on a cloud platform. However, there are advantages and disadvantages with both cloud and on-premise platforms. Issues related to security and compliance of cloud platforms may be one disadvantage. On the other hand, for on-premise platforms the cost may be a disadvantage. Since the initial investment in on-premise infrastructure may be high, companies that have already invested in on-premise platforms may prefer gradual adoption of cloud platforms, if at all, in order to maximize return and protect their initial investments. Therefore, a hybrid software delivery model may bring more value to such companies. The hybrid delivery model is a hybrid model between on-premise and cloud, e.g., on-demand. For example, in the case where an application operates on an on-premise platform with sensitive data, such data may be undesirable to be stored on a cloud platform and accessed via the Internet In such a case, a hybrid software delivery may be used where cloud services can be consumed by applications operating on anon-promise platform. Another situation where hybrid software delivery model may be appropriate is when companies prefer to run their existing on-premise applications on a cloud platform. For example, business applications running and operating on-premise at one point may be extended Of migrated towards a cloud platform, for example, to consume functionality and modern development environment and models provided by the cloud platform. However, to enable an application operating on-premise to operate on cloud, the company may have to incur costs comparable to develop a new application resulting in worse protection for on-premise investments. Also, when an application is migrated to the cloud platform, two versions of the application may have to be maintained for the on-premise and the cloud platform, increasing maintenance costs for the application.
Companies applying either on-premise or cloud software delivery model usually may have to balance between security and costs. In one embodiment, a hybrid delivery model is implemented that enables one or more applications to be deployed to both on-premise and cloud platforms without modifying the one or more applications. An application operable to be deployed and run on both on-premise and cloud platforms, without modification of the original source code of the application, is referred herein as a hybrid application. For example, a hybrid application may be deployed and/or run on an on-premise platform, and consume services or other resources provided by a cloud platform (e.g., public or virtual private cloud). Further, a hybrid application may be deployed and/or run on a cloud platform and consume resources of an on-premise platform such as a backend system.
Cloud platform 110 may be viewed as containing both a physical layer and an abstraction layer. The physical layer may consist of the hardware resources to support the cloud services being provided, and may typically include a server, a storage unit, network components, and so on. The abstraction layer may include the software deployed across the physical layer, which manifests the essential functionalities provided by cloud platform 110. For example, cloud platform 110 may provide an application runtime such as application runtime 150, user interface (UT) development toolkits, internal configurations, cloud services such as cloud services 135. Exemplary cloud services 135 may include a connectivity service, a persistence service, an identity service, a feedback service 139, a document service 137, a translations service, a collaboration service, a mobile service, etc. The functionality provided by the cloud platform 110 can be used by customers to develop and deploy software applications on application runtime 150 of cloud platform 110. In various embodiments, the cloud platform 110 may also provide support for the application lifecycle process, for example, deployment, installation, provisioning and maintenance of applications. In one embodiment cloud platform 110 may be a platform-as-a-service (PaaS) solution implemented in Java. Example of such PaaS offering may be SAP® HANA Cloud Platform.
On-premise platform 120 is a computing platform that may be installed and operated on the premises of an entity such as a customer of on-premise platform 120. On-premise platform 120 may provide functionality such as application server 140 and tools 125. Tools 125 may provide functionality for software lifecycle management, software monitoring, etc.
In one embodiment, cloudifier 130 component is implemented. Cloudifier 130 is an extension of on-premise platform 120 and provides an environment for migration of applications between on-premise platform 120 and cloud platform 110. Cloudifier 130 further provides an environment to develop, deploy, and run hybrid applications. Cloudifier 130 exposes one or more cloud application runtimes to systems and modules within on-premise platform 120 such as tools 125 or application server 140. Thus, cloudifier 130 integrates cloud application runtimes 132 and 136 with on-premise platform 120. For example, cloudifier 130 is integrated with application server 140 and tools 125. Cloudifier 130 connects internal systems of on-premise platform 120 to cloud platform 110. For example, systems of on-premise platform 120 that may be connected to cloud platform 110 through cloudifier 130 may be Enterprise resource planning (ERP) systems, Customer relationship management (CRM) systems, private cloud, etc. Once connected through cloudifier 130, systems of on-premise platform 120 may use cloud services 135, among other on-demand services.
Cloudifier 130 may include one or more application runtimes such as cloud application runtime 132 and cloud application runtime 136. In one embodiment, cloud application runtime 132 and cloud application runtime 136 correspond to application runtime 150, but are installed on on-premise platform 120. As such, cloud application runtime 132 and cloud application runtime 136 are local version of an application runtime that is installed on cloud platform 110. Cloud application runtime 132 and cloud application runtime 136 provide to on-premise platform 120 the same or corresponding environment where an application would run in cloud platform 110, including the same or corresponding application programming interfaces (APIs). Cloudifier 130 may include one or more APIs that are also provided at cloud platform 110. In one embodiment, cloud application runtime 132 or cloud application runtime 136 may be an entity that is installed together with application server 140 in on-premise platform 120.
Hybrid applications may be deployed and run locally on cloud application runtime 132 or cloud application runtime 136. For example, hybrid application ‘A’ 134 and hybrid application ‘Z’ 138 are hybrid applications operable to be deployed and run locally on cloud application runtime 132 and cloud application runtime 136 At the same time, hybrid application ‘A’ 134 and hybrid application ‘Z’ 138 may be deployed to application runtime 150 at cloud platform 110, without modification of hybrid application ‘A’ 134 and hybrid application ‘Z’ 138, respectively. Similarly, application ‘X’ 157 deployed on application runtime 150 may also be deployed on cloud application runt 132 or cloud application runtime 136. Hybrid applications remain unchanged being deployed to cloud platform 110 or local on-premise platform 120. Further, hybrid applications ‘A’ 134 and ‘Z’ 138 may consume both resources provided by on-premise platform 120 or cloud platform 110. In one embodiment, hybrid applications may be already developed applications that may have previously been installed on application server 140 of on-premise platform 120, and then re-installed on local cloud application runtime (132 and 136) of cloudifier 130. Also, a first portion of a hybrid application may be installed on a cloud application runtime installed locally at an on-premise platform, and a second portion of the hybrid application may be installed on an application runtime provided by a cloud platform. Further, application ‘X’ 157 although installed on application runtime 150 of cloud platform 110, may also be re-installed to cloud application runtime 132 or cloud application runtime 136 of on-premise platform 120. In various embodiments, cloud application runtime 132, cloud application runtime 136, and application runtime 150 may be Java® containers such as Java Enterprise Edition of Apache Tomcat (TomEE), Lean Java Server (LJS), etc.
Further, cloudifier 130 includes cloud connector 145 that, together with connectivity agent 155, provides connectivity between on-premise platform 120 and cloud platform 110. Applications and backend systems of on-premise platform 120 operate in private customers' networks. Whereas, applications, databases, and services of cloud platform 110 may be accessed and requested via the Internet. Cloud connector 145 together with connectivity agent 155 integrates applications running in cloud platform 110 with backend systems and resources of on-premise platform 120. Further, cloud connector 145 together with connectivity agent 155 integrates applications running in on-premise platform 120 with services, applications and resources of cloud platform 110. In one embodiment, requests from on-premise applications to cloud platform 110 are virtually represented by connectivity agent 155 as if the requests are sent from cloud platform 110. Requests from on-premise applications to cloud platform 110 are authenticated with connectivity agent 155 credentials. Further, cloud connector 14, to connect to cloud platform 100 via connectivity agent 155.
In one embodiment, cloud connector 145 establishes a persistent and secure communication tunnel from a network of on-premise platform 120 to connectivity agent 155 associated with cloud account 115. Typically, a customer or a group of customers of cloud platform 110 are assigned a cloud account such as cloud account 115 to be authorized to develop, deploy, run, and configure cloud applications. Once established, the secure tunnel may be used by applications assigned to cloud account 115 to remotely communicate with systems and resources of the intranet of on-premise platform 120. In one embodiment, the persistent tunnel may also be used for bidirectional communication and by multiple virtual connections. Applications and systems of on-premise platform 120 may use the tunnel to consume resources and services of cloud platform 110. For example, hybrid application ‘A’ 134 may consume one or more services from cloud services 135 through the tunnel established by cloud connector 145.
In various embodiments, cloud platform 110 uses a sandboxing approach. Cloud platform 110 starts applications of a specific account in a sandboxed environment, so that cloud applications are isolated from each other, as well as from cloud platform's services and infrastructure. Communication between cloud applications and cloud services 135 is encrypted with mutual authentication of the caller and the receiver. For calls from a cloud application to a backend system of on-premise platform 120 that are delivered through the established tunnel, the calling account and application may be identified and authenticated by a certificate which may be provisioned during application start.
In cloud platform 110, for application ‘X’ 157 to consume a service from cloud services 135, a remote connection may be initiated from a virtual machine where the application is installed, e.g., virtual machine 170, to a virtual machine where one or more cloud services are installed, e.g., virtual machine 175. In a similar manner, connectivity agent 155 may be hosted on virtual machine 170 in a sandbox environment. Requests from hybrid applications ‘A’ 134 and ‘Z’ 138 are authenticated with credentials provided by virtual machine 170, where connectivity agent 155 is installed. Thus, requests from applications for cloud services 135 received through connectivity agent 155 are authenticated as if the applications were running on cloud platform 110 instead of on-premise platform 120. Thus, from perspective of hybrid applications ‘A’ 134 and ‘Z’ 138, a virtual cloud is available at the intranet of on-premise platform 120. Similarly, requests from applications to backend 160 or other on-premise systems received through cloud connector 145 may use a local address and port as if the applications were running on on-premise platform 120 instead of cloud platform 110. Thus, applications running in cloud platform 110 use on-premise resources as if virtually the on-premise resources were available via the Internet.
In one embodiment, the request is received at a cloud connector, e.g., cloud connector 145 in
At 220, the request is received at the connectivity agent. The connectivity agent is running in the virtual machine and is being installed for a predefined cloud account. The request is automatically forwarded to the connectivity agent via the tunnel by the cloud connector. In one embodiment, the connectivity agent has been installed and running prior to the establishment of the secure tunnel. The connectivity agent accepts connections not only from a local host at the cloud platform but also from external sources such as the cloud connector in the on-premise platform. Upon receiving the request, the cloud connector forwards the request to the connectivity agent via the secure tunnel.
At 230, the connectivity agent forwards the request to the corresponding resource to be consumed. At 240, credentials of the cloud account associated with the virtual machine where the connectivity agent is installed, are verified. For example, a cloud service verifies whether the cloud account associated with the virtual machine and the connectivity agent, respectively, is authorized to access the requested cloud resource. Thus, requests to services in the cloud from on-premise hybrid applications are forwarded and processed via the cloud account. Because requests are processed via the cloud account, consumption of cloud services and other cloud resources from anon-promise platform are tracked, accounted for, and secured. At 250, a response from the requested resource of the cloud platform is received at the connectivity agent. At 260, the response is forwarded to the requesting hybrid application by the connectivity agent via the secure tunnel.
The connectivity agent where the request is received is running in the virtual machine of the cloud platform where the cloud application runtime is installed, according to one embodiment. The connectivity agent is being installed for a predefined cloud account. The request may be forwarded to the connectivity agent by the cloud application runtime. At 320, the request is received at a cloud connector installed on the on-premise platform. The request is forwarded to the cloud connector by the connectivity agent via a secure tunnel. In one embodiment, the tunnel is established by the cloud connector to the connectivity agent prior forwarding the request.
At 330, the request is forwarded to the corresponding resource to be consumed. The resource to be consumed is within the private internal network of the on-premise platform. For example, the request may be forwarded to a backend system such as backend 160 in
At 430, a local version of the cloud application runtime is installed on the on-premise platform. Examples of local version of a cloud application runtime are cloud application runtime 132 and 136 in
At 450, the local version of the cloud application runtime is integrated with the on-premise platform. For example, a cloudifier runtime installed and running on the on-premise platform exposes the cloud application runtime to other systems of the on-premise platform. At 460, a cloud connector, e.g., cloud connector 145 in
At 480, a second connection to a second instance of the connectivity agent is initiated. The second connection may be used by a cloud application deployed to the cloud application runtime for consumption of resources of the on-premise platform. The second instance of the connectivity agent is running in the cloud application runtime at the cloud platform, in one embodiment, the tunnel client of the cloud connector initiates the second connection and opens a port from the cloud application runtime to the on-premise platform, including on-premise systems, storages, etc. At 490, a third connection from the on-premise application to one or more on-premise systems is initiated via a second proxy. The second proxy for on-premise systems may be running on the cloud connector. The on-premise application that is developed with modern cloud technology can loop back through the proxy to the one or more on-premise systems such as legacy systems. Thus, in various embodiments, process 400 may configure both an on-premise application and a cloud application to interoperate between an on-premise computing platform and a cloud computing platform.
In one embodiment, requests from on-premise application 575 to consume resources of cloud platform 510 are received by port forwarding proxy 582 and then forwarded via the established tunnel to the connectivity agent 545. Connectivity agent 545 is running in cloudifier proxy virtual machine (VM) 540 and accepts requests from external sources. In one embodiment, a cloud account may be associated with one cloudifier proxy VM. Once the request from on-premise application is received at connectivity agent 545, the request is forwarded to the requested cloud resource. For example, when on-premise application 575 request to consume a cloud service such as a documentation service connectivity agent 545 may forward the request to documentation server 555 installed on documentation service VM 550. In one embodiment, on-premise application 575 may requests to consume storage of cloud platform 510. In such case, connectivity agent 545 may forward the request, for example, to in-memory database 565.
On-premise application 575 may also consume on-premise resources. In one embodiment, cloud connector 580 starts proxy for on-premise systems 584. Proxy for on-premise system 584 forward requests from on-premise application 575 to on-premise systems 590. Thus, on-premise application 575 may loopback to consume resources of on-premise platform 520. Proxy for on-premise systems 584 may be an HTTP proxy, a socks proxy, etc.
In one embodiment, on-premise resources may be consumed by cloud applications. For example, cloud application 515 running in application VM 505 may requests to consume one or more on-premise systems 590. The request is forwarded to a proxy for on-premise systems 535 running in connectivity agent 530 installed on application VM 505. Proxy for on-premise systems 535 forwards the request to port proxy forwarder such as an HTTP or RFC forwarder 586. Forwarder 586 may be running in cloud connector 580. Once the request from cloud application 515 is received at forwarder 586, forwarder 586 forwards the request to the respective on-premise system from on-premise systems 590.
Some embodiments may include the above-described methods being written as one or more software components. These components, and the functionality associated with each, may be used by client, server, distributed, or peer computer systems. These components may be written in a computer language corresponding to one or more programming languages such as, functional, declarative, procedural, object-oriented, lower level languages and the like. They may be linked to other components via various application programming interfaces and then compiled into one complete application for a server or a client. Alternatively, the components maybe implemented in server and client applications. Further, these components may be linked together via various distributed programming protocols. Some example embodiments may include remote procedure calls being used to implement one or more of these components across a distributed programming environment. For example, a logic level may reside on a first computer system that is remotely located from a second computer system containing an interface level (e.g., a graphical user interface). These first and second computer systems can be configured in a server-client, peer-to-peer, or some other configuration. The clients can vary in complexity from mobile and handheld devices, to thin clients and on to thick clients or even other servers.
The above-illustrated software components are tangibly stored on a computer readable storage medium as instructions. The term “computer readable storage medium” should be taken to include a single medium or multiple media that stores one or more sets of instructions. The term “computer readable storage medium” should be taken to include any physical article that is capable of undergoing a set of physical changes to physically store, encode, or otherwise carry a set of instructions for execution by a computer system which causes the computer system to perform any of the methods or process steps described, represented, or illustrated herein. A computer readable storage medium may be a non-transitory computer readable storage medium. Examples of a non-transitory computer readable storage media include, but are not limited to: magnetic media, such as hard disks, floppy disks, and magnetic tape; optical media such as CD-ROMs, DVDs and holographic devices; magneto-optical media; and hardware devices that are specially configured to store and execute, such as application-specific integrated circuits (“ASICs”), programmable logic devices (“PLDs”) and ROM and RAM devices. Examples of computer readable instructions include machine code, such as produced by a compiler, and files containing higher-level code that are executed by a computer using an interpreter. For example, an embodiment may be implemented using Java, C++, or other object-oriented programming language and development tools. Another embodiment may be implemented in hard-wired circuitry in place of, or in combination with machine readable software instructions.
A data source is an information resource. Data sources include sources of data that enable data storage and retrieval. Data sources may include databases, such as, relational, transactional, hierarchical, multi-dimensional (e.g., OLAP), object oriented databases, and the like. Further data sources include tabular data (e.g., spreadsheets, delimited text files), data tagged with a markup language (e.g., XML data), transactional data, unstructured data (e.g., text files, screen scrapings), hierarchical data (e.g., data in a file system, XML data), files, a plurality of reports, and any other data source accessible through an established protocol, such as, Open Data Base Connectivity (ODBC), produced by an underlying software system (e.g., BBP system), and the like. Data sources may also include a data source where the data is not tangibly stored or otherwise ephemeral such as data streams, broadcast data, and the like. These data sources can include associated data foundations, semantic layers, management systems, security systems and so on.
In the above description, numerous specific details are set forth to provide a thorough understanding of embodiments. One skilled in the relevant art will recognize, however that the embodiments can be practiced without one or more of the specific details or with other methods, components, techniques, etc. In other instances, well-known operations or structures are not shown or described in details.
Although the processes illustrated and described herein include series of steps, it will be appreciated that the different embodiments are not limited by the illustrated ordering of steps, as some steps may occur in different orders, some concurrently with other steps apart from that shown and described herein. In addition, not all illustrated steps may be required to implement a methodology in accordance with the one or more embodiments. Moreover, it will be appreciated that the processes may be implemented in association with the apparatus and systems illustrated and described herein as well as in association with other systems not illustrated.
The above descriptions and illustrations of embodiments, including what is described in the Abstract, is not intended to be exhaustive or to limit the one or more embodiments to the precise forms disclosed. While specific embodiments and examples are described herein for illustrative purposes, various equivalent modifications are possible, as those skilled in the relevant art will recognize. These modifications can be made in light of the above detailed description. Rather, the scope is to be determined by the following claims, which are to be interpreted in accordance with established doctrines of claim construction.
