Abstract:
A system includes reception of a request associated with a cloud-based application at an external port of a container associated with the cloud-based application, passage of the request to an application controller associated with the cloud-based application, determination of whether the request includes a command to modify the cloud-based application, invocation of a function to execute the command if it is determined that the request includes a command to modify the cloud-based application, and forwarding of the request to the cloud-based application at a second port different from the external port if it is determined that the request does not include a command to modify the cloud-based application.

Description:
BACKGROUND 
       [0001]    As shown in  FIG. 1 , a software developer may operate a development system  10  to develop a cloud-based application  20  conforming to a cloud-native application framework, and push (i.e., deploy) the developed application to cloud-based application platform  30 . Cloud-based application platform  30  supports application lifecycle stages including development, testing and deployment. Application platform  30  hosts application  20  within container  40 , which communicates to the outside world via a single Transmission Control Protocol (TCP) port. 
         [0002]    A developer will typically modify application  20  several times (e.g., for debugging, incremental deployment, etc.) after initial deployment. In order to reflect these modifications in the deployed application, the developer re-pushes (now-modified) application  20  to platform  30 . As a result, container  40  which hosts application  20  is killed and application  20  is re-deployed to a new container which is associated with a new TCP port. This process may be time- and resource-intensive. Improved support for development activities is desired. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0003]      FIG. 1  is a block diagram of a system architecture. 
           [0004]      FIG. 2  is a block diagram of a system architecture according to some embodiments. 
           [0005]      FIG. 3  is a flow diagram according to some embodiments. 
           [0006]      FIG. 4  is a block diagram of a system architecture according to some embodiments. 
           [0007]      FIG. 5  is a flow diagram according to some embodiments. 
           [0008]      FIG. 6  is a block diagram of a hardware system according to some embodiments. 
       
    
    
     DETAILED DESCRIPTION 
       [0009]    The following description is provided to enable any person in the art to make and use the described embodiments. Various modifications, however, will remain readily apparent to those in the art. 
         [0010]    Some embodiments provide an application controller within the above-mentioned container, which functions as a wrapper to the application. The application controller assumes responsibility for the external TCP port of the container and acts as a reverse proxy to route application requests to the application. The application controller may thereby allow management of the application resources and/or actions of the deployed application without instantiation of a new container (with a new TCP port) as described above. 
         [0011]    According to some embodiments, the application controller examines any traffic arriving at the port and either passes the traffic to the wrapped application, or treats the traffic as a command and executes the command. For example, executing a command to replace some or all of the files in the application filesystem enables hot-deployment of static resources served by the wrapped application. 
         [0012]    In some embodiments, the application controller further provides a plugin mechanism which allows extension developers to add new functionality. The plugin mechanism may include an extensible plugin framework to allow different domain types to be served and supported. For example, incremental deployment of static resource-based applications such as static websites may simply require replacement of a static resource in the wrapped application (i.e., web server), while Node.js applications require restarting of the wrapped application after resources are refreshed. 
         [0013]      FIG. 2  is a block diagram of system architecture  100  according to some embodiments. Architecture  100  includes development system  110  and application platform  120 . Embodiments are not limited to architecture  100 . 
         [0014]    Any of the depicted elements of architecture  100  may be implemented by one or more hardware devices coupled via any number of public and/or private networks. Two or more of such devices may be located remote from one another all devices may communicate with one another via any known manner of network(s) and/or via a dedicated connection. 
         [0015]    Development system  110  may comprise any computing system providing a development environment for developing program code. The program code may conform to a cloud-native application format. Development system  110  may comprise a desktop computer, a laptop computer, a netbook computer, a tablet computer, a smartphone, and/or any other computing system that is or becomes known. For example, development system  110  may include a memory storing program code of an Integrated Development Environment and one or more processors to execute the code. The code of the Integrated Development Environment may be located remote from system  110  and provided as a service, in which system  110  executes program code of a client application such as a Web browser. 
         [0016]    Application platform  120  supports application lifecycle stages including development, testing and deployment. Application platform  120  may provide a Platform as-a-service (PaaS) as is known in the art. Accordingly, application platform  120  may communicate with development system  110  via a Web-based protocol such as HyperText Transfer Protocol (HTTP) or WebSocket. 
         [0017]    Application platform  120  has instantiated container  130 , which may comprise a PaaS application container as is known in the art. As is not known in the art, container  130  includes an instantiation of application controller  140 , which functions as a wrapper to application  150 . Application controller  140  assumes responsibility for the external TCP port (i.e., Port A) of container  130  and routes application requests to application  150  via its port (i.e., Port B). 
         [0018]      FIG. 3  is a flow diagram of process  300  for instantiating an application controller according to some embodiments. Process  300  and each other process described herein may be embodied in processor-executable program code read from one or more non-transitory computer-readable media, such as a floppy disk, a CD-ROM, a DVD-ROM, a Flash drive, a fixed disk and a magnetic tape, and then stored in a compressed, uncompiled and/or encrypted format. Accordingly, a processor of any suitable device or devices may execute the program code to cause the device or devices to operate as described. In some embodiments, hard-wired circuitry may be used in place of, or in combination with, program code for implementation of processes according to some embodiments. Embodiments are therefore not limited to any specific combination of hardware and software. 
         [0019]    Initially, at S 310 , a request is received to push an application to an application platform. For example, a developer may enter a command into development system  110  to instruct development system  110  to transmit code of an application to application platform  120 . 
         [0020]    At S 320 , an instance of an application container is created. The instance is intended to contain the application and is associated with an external port of the application platform  120 . In this regard, S 310  and S 320  may proceed as is known in the art. 
         [0021]    However, at S 330 , an instance of an application controller (e.g., application controller  140 ) is created within the application container. As described above, the application controller is a wrapper of the application and will receive traffic from the container which is intended for the application. At S 340 , the application controller determines a free port (e.g., Port B) of the application platform and assigns the determined port to the application. The port is assigned because the original port is used by the application controller as described above. 
         [0022]    As mentioned above, application controller  140  may receive a request which arrives at the port of container  130 . Application controller  140  examines the request and determines whether the request is a command or a call to application  150 . For example, commands may follow the syntax: &lt;host&gt;:&lt;port&gt;/&lt;UUID&gt;/command. If the request is a command, application controller  140  may execute the command using its built-in functionality. 
         [0023]    For example, if a command is received to replace all resources of application  150 , application controller  140  retrieves the files of application  150  (e.g., from a resources folder under app/web/resources) and replaces all the application resources in the runtime filesystem of application platform  120 . Re-pushing the application as described in the Background may thereby be avoided, allowing a user to quickly see the changes reflected in a client system. 
         [0024]    Functionality supporting commands may also be provided by a plug-in framework according to some embodiments. Such a framework may also supports the addition of new commands. 
         [0025]      FIG. 4  is a view of system architecture  400  including a plug-in framework according to some embodiments. Development system  410 , application platform  420 , container  430  and application  450  may be implemented as described with respect to similarly-named components of  FIG. 2 . Client systems  460  may comprise computing systems operated by users of application  450  in a runtime capacity. 
         [0026]    Application controller  440  includes reverse proxy  442 , plug-in handler  444  and plug-ins  446 . Container  430 , application controller  440  and application  450  may be instantiated as described above with respect to process  300  of  FIG. 3 . 
         [0027]    According to some embodiments, each of plug-ins  446  is self-contained and isolated, can be loaded from any Uniform Resource Indicator (URI), may expose 0 . . . n functions, includes a central (private) plug-in controller for event handling, and is stored in a plug-in folder in application controller  440 . Plug-in handler  444  of application controller  440  may provide the plugin&#39;s mechanism, which can provide other functionality to any native functions, such as save/run/replace project. The plug-in framework may provide efficient support of several application types, including but not limited to static-file, Node.js, Java, and C/C++ applications. 
         [0028]    In one example of plug-in creation to provide extended functionality, a user may clone the application controller, create, in the plug-in folder, a new javascript module file implementing the extended functionality, and create a new JSON file which indicates the plug-in interface. Other non-exhaustive examples include implementing application controller  440  as a Java tool, and using XML as the plug-in interface, or using Java introspection with code annotations for identifying plug-ins. Embodiments may employ Node.JS to implement application controller  440 , leading to the use of JSON as mentioned above and the flow described herein to create a plug-in. 
         [0029]    Accordingly, each plug-in may consist of two files. 
         [0030]    The following is an example of the aforementioned JSON file: 
         [0000]    plugin.json structure 
         [0000]    
       
         
               
               
             
               
               
             
               
               
             
               
               
             
               
               
             
               
               
             
               
               
             
               
               
             
               
               
             
               
               
             
           
               
                   
                   
               
             
             
               
                   
                 { 
               
             
          
           
               
                   
                 “Providers”: [ 
               
             
          
           
               
                   
                 { 
               
             
          
           
               
                   
                 “save”: { 
               
             
          
           
               
                   
                 “path”: “/save”, 
               
               
                   
                 “function”: “saveFn”, 
               
               
                   
                 “method”: “post” 
               
             
          
           
               
                   
                 }, 
               
               
                   
                 “delete”: { 
               
             
          
           
               
                   
                 “path”: “/delete”, 
               
               
                   
                 “function”: “deleteFn”, 
               
               
                   
                 “method”: “delete” 
               
             
          
           
               
                   
                 }, 
               
             
          
           
               
                   
                 } 
               
             
          
           
               
                   
                 ] 
               
               
                   
                   
               
             
          
         
       
     
         [0031]    According to the above structure, the entry name (e.g. “save”) semantically indicates the function, “path” indicates which path to listen to during runtime, “function” indicates the function to handle/invoke via request, and “method” specifies corresponding HTTP actions such as post/get, etc. 
         [0032]      FIG. 5  is a flow diagram of process  500  according to some embodiments. Process  500  will be described with respect to application controller  440  of system  400 . 
         [0033]    Flow initially pauses at S 510  until a request associated with an application is received at an external port. For example, a request associated with application  450  may be received by container  430  at Port A and then passed thereby to application controller  440 . The request may be received from development system  410  or one of client systems  460 . 
         [0034]    At S 520 , it is determined whether the request includes a command. The syntax of commands may be predetermined, such as the syntax &lt;host&gt;:&lt;port&gt;/&lt;UUID&gt;/command mentioned above. Using a UUID in this URI structure may reduce or prevent the chance that the command being implemented conflicts with a command actually provided by application  450 . Accordingly, S 520  may comprise a determination by application controller  440  of whether the request corresponds to the command syntax. If not, the request is forwarded to application  450  at Port B at S 530 . Application  450  then serves the request as intended by the developer of application  450 . In this regard, the request may have been received from one of client systems  460  accessing platform  420  in a runtime mode. 
         [0035]    Flow proceeds to S 540  if it is determined at S 520  that the request includes a command. A plug-in configuration file corresponding to the command is read at S 440  to determine the corresponding plug-in interface, and the requested function is determined based on the received request and the interface. Next, at S 560 , the plug-in is invoked for the requested function. 
         [0036]      FIG. 6  is a block diagram of apparatus  600  according to some embodiments. Apparatus  600  illustrates a hardware architecture implementing a development platform as described above, but implementations are not limited thereto. Elements of apparatus  600  may therefore operate to execute methods as described above. Apparatus  600  may include other unshown elements according to some embodiments. 
         [0037]    Apparatus  600  includes processor(s)  610  operatively coupled to communication device  620 , data storage device  630 , one or more input devices  640 , one or more output devices  650  and memory  660 . Communication device  620  may facilitate communication with external computing systems, such as development systems. Input device(s)  640  may comprise, for example, a keyboard, a keypad, a mouse or other pointing device, a microphone, knob or a switch, an infra-red (IR) port, a docking station, and/or a touch screen. Input device(s)  640  may be used, for example, to enter information into apparatus  600 . Output device(s)  650  may comprise, for example, a display (e.g., a display screen) a speaker, and/or a printer. 
         [0038]    Data storage device  630  may comprise any appropriate persistent non-transitory storage media, including combinations of magnetic storage devices (e.g., magnetic tape, hard disk drives and flash memory), optical storage devices, Read Only Memory (ROM) devices, etc., while memory  660  may comprise Random Access Memory (RAM). 
         [0039]    Development platform  632  and application controller  634  of data storage device  630  may comprise program code executable by processor  610  to provide any of the functions described herein, including but not limited to processes  300  and  500 . Embodiments are not limited to execution of these functions by a single apparatus. Applications  636  and plug-ins  638  may comprise program code as described above, with each of plug-ins  638  comprising a configuration file and an executable file. Data storage device  630  may also store data and other program code for providing additional functionality and/or which are necessary for operation thereof, such as device drivers, operating system files, etc. 
         [0040]    All systems and processes discussed herein may be embodied in program code stored on one or more computer-readable non-transitory media. Such non-transitory media may include, for example, a fixed disk, a floppy disk, a CD-ROM, a DVD-ROM, a Flash drive, magnetic tape, and solid state RAM or ROM storage units. Embodiments are therefore not limited to any specific combination of hardware and software. 
         [0041]    Embodiments described herein are solely for the purpose of illustration. Those in the art will recognize other embodiments may be practiced with modifications and alterations to that described above.