ES2877363T3 - Multitenencia a través de código encapsulado en solicitudes de servidor - Google Patents

Multitenencia a través de código encapsulado en solicitudes de servidor Download PDF

Info

Publication number
ES2877363T3
ES2877363T3 ES15864053T ES15864053T ES2877363T3 ES 2877363 T3 ES2877363 T3 ES 2877363T3 ES 15864053 T ES15864053 T ES 15864053T ES 15864053 T ES15864053 T ES 15864053T ES 2877363 T3 ES2877363 T3 ES 2877363T3
Authority
ES
Spain
Prior art keywords
mtis
computer routine
web task
routine
request
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
ES15864053T
Other languages
English (en)
Inventor
Tomasz Janczuk
Matias Woloski
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Auth0 Inc
Original Assignee
Auth0 Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Auth0 Inc filed Critical Auth0 Inc
Application granted granted Critical
Publication of ES2877363T3 publication Critical patent/ES2877363T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/561—Adding application-functional data or data for application control, e.g. adding metadata
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/955—Retrieval from the web using information identifiers, e.g. uniform resource locators [URL]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/52—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow
    • G06F21/53—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow by executing in a restricted environment, e.g. sandbox or secure virtual machine
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/604—Tools and structures for managing or administering access control systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/40—Transformation of program code
    • G06F8/41—Compilation
    • G06F8/43—Checking; Contextual analysis
    • G06F8/433—Dependency analysis; Data or control flow analysis
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/547—Remote procedure calls [RPC]; Web services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1097—Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/133—Protocols for remote procedure calls [RPC]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/34—Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters 
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/54—Indexing scheme relating to G06F9/54
    • G06F2209/549—Remote execution
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H04L67/025—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP] for remote control or remote monitoring of applications

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Library & Information Science (AREA)
  • Databases & Information Systems (AREA)
  • Automation & Control Theory (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Data Mining & Analysis (AREA)
  • Stored Programmes (AREA)
  • Computer And Data Communications (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

Servidor de infraestructura multitenencia, MTIS, (140) configurado para proporcionar un entorno con el fin de ejecutar una rutina de ordenador de una aplicación arbitraria, comprendiendo el MTIS: un procesador; una interfaz de red acoplada al procesador configurada para permitir comunicaciones a través de una red de comunicación; un dispositivo de almacenamiento para contenido y programación; y un programa almacenado en el dispositivo de almacenamiento, configurando la ejecución del programa el servidor de infraestructura multitenencia con el fin de realizar acciones que comprenden: recibir una solicitud (124) de un servidor de tareas web (107) para ejecutar la rutina de ordenador en un contenedor de tarea web, incluyendo la solicitud unos datos de cliente (106) y unos secretos de cliente (112), incluyendo la solicitud, además, la rutina de ordenador a ejecutar o un enlace de un localizador uniforme de recursos, URL, a la rutina de ordenador; ejecutar la rutina de ordenador del contenedor de tarea web en el MTIS, incluyendo la ejecución de la rutina de ordenador asignar un contenedor precalentado para una entidad usuaria de entre una reserva de contenedores precalentados, siendo los contenedores precalentados unos contenedores preparados para asignarse antes de que se reciba la solicitud; tras una ejecución exitosa de la rutina de ordenador, devolver un conjunto de resultados al servidor de tareas web; tras una ejecución no exitosa de la rutina de ordenador, devolver una rutina de ordenador de error al servidor de tareas web; determinar recursos consumidos durante la ejecución de la rutina de ordenador; y destruir el contenedor de tarea web para evitar un almacenamiento persistente de la rutina de ordenador en el MTIS.

Description

DESCRIPCIÓN
Multitenencia a través de código encapsulado en solicitudes de servidor
Antecedentes
Las arquitecturas de aplicaciones informáticas han presentado una tendencia hacia la distribución de diferentes funciones informáticas en múltiples ordenadores. De hecho, la mayoría de aplicaciones de móviles y web actuales se basan en una arquitectura distribuida. Por ejemplo, en una arquitectura de cliente-servidor, la división de la funcionalidad de las aplicaciones entre la parte de presentación (front end) y la parte interna (backend) ayuda a reutilizar recursos informáticos de la parte interna en varios clientes. Esto crea también un límite de confianza entre el cliente y el servidor, lo cual permite que los servidores autoricen el acceso para proteger datos o una funcionalidad. En una aplicación típica de cliente-servidor, el cliente presenta datos a la parte interna para su procesado después de autenticarse, y la parte interna responde después del procesado de la solicitud del cliente usando recursos protegidos.
Una de las partes internas típicas, en la nube, de una aplicación (por ejemplo, móvil o web) proporciona recursos informáticos en bruto (por ejemplo, CPU, memoria, disco, red, etc.) así como las capacidades de sistema operativo y de marco de aplicaciones que son diferentes con respecto a la del cliente. La parte interna encapsula código del servidor que implementa parte de la lógica de la aplicación así como secretos que son requeridos por este código para acceder a datos protegidos o una funcionalidad, tales como cadenas de conexión de bases de datos, interfaces de programación de aplicaciones (API), claves de seguridad, etc.
La gestión de una infraestructura que alberga código de la parte interna puede implicar el dimensionado, el aprovisionamiento y el escalado de diversos servidores, la gestión de actualizaciones del sistema operativo, afrontar problemas de seguridad, la actualización de hardware según se requiera, y, a continuación, la monitorización de todos estos elementos en relación con posibles funcionamientos defectuosos. De este modo, se pone mucho esfuerzo típicamente solo en la logística de la gestión de la parte interna. Este esfuerzo se puede usar mejor en desarrollar, optimizar y/o desplegar aplicaciones informáticas.
Durante los años, la informática en la nube ha aumentado su popularidad debido a que reduce los costes de la Tecnología de la Información (IT), y hace que la capacidad informática de los servidores quede disponible en forma de una mercancía/servicio. Anteriormente, el planteamiento principal para reducir costes consistía en reducir el personal de IT subcontratando funciones informáticas de servidores a proveedores de informática en la nube. No obstante, en la actualidad hay varios proveedores de informática en la nube que están compitiendo, por lo que las reducciones de los costes en estos momentos son principalmente de carácter técnico.
Uno de los planteamientos técnicos para reducir costes es aumentar la densidad de las aplicaciones. Específicamente, el alojamiento de una aplicación presenta costes en recursos, tales como memoria y CPU. Si existe una manera de compartir esos costes de recursos entre aplicaciones, entonces los mismos se pueden repartir entre esas aplicaciones. Por consiguiente, han surgido técnicas de multitenencia para compartir recursos de máquinas virtuales, con lo cual se aumenta la densidad de las aplicaciones.
El coste de aprovisionar y asignar una máquina física es mayor que el coste de aprovisionar y asignar una máquina virtual. A su vez, el coste de aprovisionar y asignar una máquina virtual es mayor que el coste de aprovisionar y asignar un contenedor para múltiples entidades usuarias (multi-tenant). Finalmente, el coste de ejecutar un proceso en un contenedor es a su vez más caro que el coste de ejecutar un hilo. Idealmente, para alguna clase de aplicaciones web ligeras, la densidad de las aplicaciones se podría maximizar aunque ejecutando cada aplicación según cada hilo individual. No obstante, aunque los sistemas operativos permiten que los procesos gestionen recursos, no proporcionan una funcionalidad adecuada para gestionar recursos a nivel de hilo. Específicamente, los activos de información de entidades usuarias diferentes se deben aislar unos de otros, tal como en un contenedor para múltiples entidades usuarias, y el uso de los recursos se debe gestionar y dosificar para mantener la calidad de servicio y permitir una facturación por parte del proveedor de informática en la nube.
Aunque existen soluciones de plataformas como servicio (PaaS) que permiten que los clientes desarrollen, ejecuten y gestiones aplicaciones web sin la complejidad de construir y mantener la infraestructura típicamente asociada al desarrollo y el lanzamiento de una aplicación, las mismas conllevan diversos problemas. Por ejemplo, las plataformas PaaS conocidas pueden no proporcionar una estructura de costes atractiva y puede que se ejecuten sobre un modelo de programación asíncrono, requiriendo un sondeo de los resultados de la computación, lo cual afecta negativamente a la latencia. Además, puede que las arquitecturas PaaS conocidas requieran no solamente la carga del código sino también un almacenamiento persistente del mismo. A continuación, el código se sitúa a la espera de eventos con el fin de completar su tarea. No obstante, un planteamiento de este tipo incluye riesgos de seguridad ya que el código se gestiona en otro sitio, lo cual hace que el mismo sea vulnerable a copias o a ser hackeado. La presente exposición se ha redactado con respecto a estas consideraciones y otras.
El documento “AWS Lambda Developer Guide API Version 2014-11-13” (XP55478195) divulga un servicio informático que ejecuta código como respuesta a eventos tales como cargas de imágenes, una actividad integrada en aplicaciones, clics en sitios web, o salidas de dispositivos conectados. AWS Lambda amplía otros servicios de Amazon Web Service con lógica personalizada, o permite que un usuario cree su propia parte interna que funciona a una escala, con un rendimiento y una seguridad de AWS. AWS Lambda puede ejecutar el código personalizado de un usuario, y se pueden publicar eventos de Amazon S3 a AWS Lambda. Una vez que se ha completado la ejecución del código personalizado, AWS Lambda puede realizar acciones de seguimiento tales como la limpieza de recursos.
El documento EP 3201767 A1 divulga un servicio que gestiona una pluralidad de instancias de máquina virtual para la ejecución de códigos de usuario con baja latencia. La pluralidad de instancias de máquina virtual se puede configurar basándose en un conjunto predeterminado de configuraciones. Dentro de las instancias de máquina virtual pueden crearse uno o más contenedores. Como respuesta a una solicitud de ejecutar código de usuario, el servicio identifica una instancia de máquina virtual preconfigurada y adecuada para ejecutar el código de usuario. El servicio puede asignar la instancia de la máquina virtual identificada al usuario, crear un nuevo contenedor dentro de una instancia ya asignada al usuario o reutilizar un contenedor ya creado para la ejecución del código de usuario. Cuando el código de usuario no se ha activado durante un periodo límite de tiempo, el servicio puede invalidar la asignación de la instancia de la máquina virtual y destruir el contenedor. El tiempo desde la recepción de la solicitud al comienzo de la ejecución del código es inferior a un espacio predeterminado, por ejemplo, 100 ms.
El documento US2012/072762 divulga sistemas y métodos para gestionar dinámicamente solicitudes de capacidad de computación de un proveedor de recursos informáticos. Ilustrativamente, los recursos informáticos pueden incluir capacidades de ejecución de programas, capacidades de almacenamiento o gestión de datos, ancho de banda de redes, etcétera. Los sistemas o métodos asignan automáticamente recursos informáticos para la ejecución de uno o más programas asociados al usuario. Los sistemas y métodos pueden permitir que el usuario realice cambios en los recursos asignados después de que haya comenzado la ejecución de uno o más programas.
Sumario
La invención se define como el servidor de infraestructura multitenencia según la reivindicación 1 y el método según la reivindicación 14. En las reivindicaciones subordinadas se definen varias formas de realización.
Breve descripción de los dibujos
Las figuras de los dibujos representan una o más implementaciones de acuerdo con las presentes enseñanzas, únicamente a título de ejemplo, no a modo de limitación. En las figuras, los números de referencia equivalentes se refieren a elementos iguales o similares.
La figura 1 ilustra una arquitectura de ejemplo para ejecutar un código de una aplicación arbitraria en un entorno multitenencia seguro.
La figura 2 ilustra un diagrama de bloques del marco de datos para ejecutar código en contenedores multitenencia.
La figura 3 ilustra un ejemplo de máquina virtual de tareas web que se puede usar como servidor de infraestructura multitenencia de la figura 1.
La figura 4 ilustra un proceso de flujo de llamadas de ejemplo de alto nivel para ejecutar un código en un entorno de infraestructura multitenencia.
La figura 5 ilustra una red u ordenador anfitrión que puede estar situado en una nube.
La figura 6 ilustra un ordenador con elementos de interfaz de usuario.
Descripción detallada
Esta exposición se refiere en general a métodos y sistemas de ejecución de una rutina de ordenador en un entorno virtual. El entorno informático descrito en la presente memoria recibe la rutina de ordenador en forma de código de ordenador de un desarrollador informático. Se determina qué lenguaje o lenguajes informáticos se están usando en la rutina. Se crea un contenedor específicamente para la rutina, de tal manera que el mismo está previsto para admitir los lenguajes en la rutina y cualquier otra infraestructura utilizada o invocada por la rutina. Por consiguiente, el contenedor envolverá a la rutina en un entorno completo que incluye los elementos a ejecutar, tal como código o un enlace al mismo, herramientas del sistema, bibliotecas del sistema, etc., garantizándose así que la rutina se ejecutará en su entorno de destino virtual. El entorno de destino virtual proporciona los recursos en bruto requeridos para ejecutar la rutina, incluidos memoria, potencia de procesado, conexión en red, etc. A diferencia de planteamientos conocidos, la rutina no se carga para su almacenamiento en reposo, ni se mapea con eventos ni se almacena en reposo en el entorno informático de destino (es decir, máquina virtual). Por el contrario, la rutina se encamina a una máquina virtual con el entorno correspondiente para su ejecución sin expectativas de que el código se ejecute nuevamente. De este modo, el código no se almacena en reposo sino que se destruye después de completar la ejecución del mismo.
Una solicitud para ejecutar la rutina puede ser relativa a una aplicación arbitraria en la medida en la que sea independiente del sistema operativo huésped del entorno de destino virtual. Las solicitudes de ejecución de rutinas de ordenador se pueden procesar en una infraestructura multitenencia, proporcionando así capacidades de aislamiento y dosificación. Las solicitudes pueden estar en un lenguaje de programación arbitrario, siempre que haya disponibles interconexiones entre lenguajes para la infraestructura multitenencia.
Por lo tanto, de manera ventajosa, la necesidad de instalar y ejecutar una rutina de ordenador (por ejemplo, aplicaciones) en el o los propios ordenadores del usuario se hace innecesaria, lo cual simplifica el mantenimiento, la escalabilidad, la seguridad y el soporte. Además, en una forma de realización, el uso de la informática en la nube ayuda a evitar costes de la infraestructura anticipados y permite que los negocios consigan que su código se ejecute más rápido, con una capacidad de gestión mejorada y menos mantenimiento. Puesto que el código a ejecutar está aislado en su contenedor y el contenedor se destruye tras completarse la ejecución, se proporciona seguridad adicional.
Ejemplo de arquitectura del sistema
La figura 1 ilustra un ejemplo de arquitectura para ejecutar una rutina de una aplicación arbitraria en un entorno multitenencia seguro. El sistema 100 incluye un cliente 102, un servidor de tareas web 107, un servidor de infraestructura multitenencia (MTIS) 140 que puede incluir múltiples contenedores, y un servidor de almacenamiento de archivos en línea 132. Existe una red 130 que facilita la comunicación entre los diferentes componentes del sistema 100. La red 120 puede ser, sin carácter limitativo, una red de área local (“LAN”), una red privada virtual (“VPN”), una red celular, o Internet. Por consiguiente, el cliente se puede comunicar con el servidor de tareas web 107 por medio de la red 130 para enviar una rutina de ordenador de una aplicación arbitraria con vistas a su procesado y para recibir los resultados correspondientes del procesado a partir de ello. En una forma de realización, en lugar de enviar la rutina al servidor de tareas web 107, se envía un enlace a un repositorio donde se almacena el código de la rutina, tal como el servidor de almacenamiento de archivos en línea 132.
El servidor de tareas web 107 está configurado para recibir información del cliente 102 y envolver la rutina en un paquete completo que incluye una infraestructura para una ejecución en aislamiento en el MTIS 140. A continuación, el servidor de tareas web 107 envía el “paquete” al MTIS 140. El servidor de tareas web 107 solicita un contenedor que tiene toda la infraestructura que será usada por la rutina de ordenador del MITS 140. A continuación, el servidor de tareas web 107 despacha la rutina de ordenador junto con metadatos en forma de un paquete al contenedor especificado por el MTIS 140. El contenedor a continuación ejecuta la rutina del paquete de acuerdo con los metadatos. El contenedor devuelve los resultados de la ejecución de la rutina retornándolos al servidor de tareas web 107. A continuación, el servidor de tareas web 107 devuelve los resultados al cliente 102 (por ejemplo, en su navegador).
El MTIS 140 puede funcionar en una nube e incluir recursos informáticos en bruto que se usan para ejecutar la rutina de ordenador recibida del servidor de tareas web 107. Esta rutina destinada a ejecutarse es no persistente en la medida en la que no se almacena en el MTIS 140. Por el contrario, la rutina se descarta después de completarse la ejecución de la rutina de ordenador.
Ejemplo de bloques funcionales
A continuación se hace referencia a la figura 2, que ilustra un diagrama de bloques del marco de datos para ejecutar código (por ejemplo, una rutina de ordenador) en contenedores multitenencia. El sistema 100 ilustra un cliente 102 que se comunica con un servidor 104 por medio de una red 130.
El servidor 140 puede funcionar en una nube e incluir recursos informáticos en bruto 142, tales como una CPU, memoria, un disco, etcétera, así como un sistema operativo 144. De este modo, el servidor 140 proporciona recursos informáticos en bruto 142 y un sistema operativo, que pueden interpretarse como un producto en la nube. El servidor 140 proporciona la parte interna para una aplicación en forma de una rutina de ordenador destinada a ejecutarse. Lo que falta en particular en el servidor 140 es código de servidor que implemente parte de la lógica de la aplicación así como secretos que requiere este código para acceder a datos protegidos o una funcionalidad, tales como cadenas de conexión de bases de datos, claves de API, etc. Tanto el código de servidor como los secretos son datos que se serializan juntos en un agrupamiento 108 y que ahora pueden encontrarse en el cliente 102. Además, en una forma de realización, en lugar de almacenar todo el código de servidor en el agrupamiento 108 del cliente 102, el código se externaliza a una ubicación que se puede referenciar con un identificador uniforme de recursos (URL) 110, tal como GitHub® o Amazon Simple Storage Service (S3). De este modo, el código se puede enlazar a un servidor de almacenamiento de archivos en línea 132.
Al agolpamiento 108, que comprende el código (por ejemplo, una rutina de ordenador) para una aplicación arbitraria (o un enlace URL a la misma) 110, y los secretos de cliente 112, se le hace referencia en la presente memoria como token de tarea web 110, que define una lógica de aplicación de la parte interna junto con secretos para su ejecución. En una forma de realización, el mismo está protegido criptográficamente 114 contra manipulaciones indebidas y exposición. Se puede almacenar o pasar de manera segura a través de canales no fiables, como la red 130.
El servidor de tareas web (por ejemplo, 107 en la figura 1) es el que descifra el token de tarea web 110 y proporciona el material ya descifrado al servidor 140 (por ejemplo, MTIS). Por ejemplo, el descifrado lo realiza el servidor de tareas web 107 ya que los contenedores de tareas web en el servidor 140 (por ejemplo, el MTIS) ejecutan código no fiable y, por lo tanto, no reciben las claves criptográficas para descifrar tokens de tareas web 110.
Puesto que los tokens de tareas web 108 pueden incluir un enlace URL 110 al código de servidor en lugar del propio código (por ejemplo, una rutina de ordenador), el tamaño serializado del token es relativamente pequeño teniendo en cuenta los estándares de ancho de banda actuales. Por consiguiente, los tokens de tareas web 108 ofrecen la flexibilidad de poderse repartir como parte de la carga útil en varios protocolos, incluido el protocolo de transferencia de hipertexto (HTTP). En el ejemplo de la figura 1, el token de tarea web se almacena en la propia aplicación del cliente 102. Por consiguiente, al mantener los secretos 112 de la parte interna incluidos en el token de tarea web 108 en el extremo del cliente 102, los secretos permanecen seguros contra su exposición debido al cifrado 114. Por lo tanto, el token de tarea web es resistente a manipulaciones indebidas y a la suplantación de identidad.
Cuando se origina una solicitud 124 en el cliente 102 y la misma se envía al servidor 140 a través de la red 130 para ejecutar una rutina de ordenador para una aplicación arbitraria, la solicitud 124 puede incluir los datos específicos de cliente 106, así como el token de tarea web 108, creando una solicitud de tarea web. Por consiguiente, una solicitud de tarea web es una solicitud 124 del cliente 102, que incluye un token de tarea web 110 además de datos de solicitud de cliente 106 regulares.
En una forma de realización, el servidor 140 recibe la solicitud de tarea web 124 (es decir, que comprende el token de tarea web 108 y los datos de cliente 106), recupera la rutina de ordenador de los medios de almacenamiento de archivos en línea 132, basándose en el URL 110 proporcionado en el token de tarea web 108, y aplica los recursos informáticos 142 adecuados para ejecutar la solicitud de tarea web. Por consiguiente, el servidor 140 proporciona un entorno de ejecución genérico para ejecutar cualquier solicitud de tarea web, en lugar de centrarse en una lógica de aplicación particular. A un servidor, tal como el servidor 140 que proporciona un entorno de ejecución genérico y uniforme para tareas web, se le hace referencia, en ocasiones, en la presente memoria, como MTIS.
En una forma de realización, con el fin de seguir siendo genérico, el MTIS 140 proporciona un entorno de ejecución uniforme para todas las tareas web. De este modo, la lógica de la parte interna de diversas aplicaciones que se ejecutan en el MTIS 140 tiene acceso a la misma funcionalidad proporcionada por el sistema operativo (OS) 144 y paquetes de software preinstalados.
La uniformidad del MTIS 140 junto con la carencia de un estado específico de cada aplicación impuesto por el modelo de la tarea web presenta varias ventajas con respecto a partes internas tradicionales. Por ejemplo, el tiempo de ejecución de una tarea web se puede escalar 104 fácilmente mediante diversas aplicaciones dispares. Permite, por lo tanto, que una capa lógica de aplicación haga uso de algunas de las mismas economías de escala que utilizan los grandes centros de datos a nivel de hardware. Por consiguiente, el MTIS 140 permite una comoditización del procesado lógico de una aplicación a un nivel de abstracción superior al de las PaaS conocidas.
Ejemplo de modelo multitenencia para encajonar (sandboxing) rutinas de ordenador no fiables
En una forma de realización, la arquitectura del MTIS 140 es multitenencia. Multitenencia se refiere a una arquitectura en la que una única instancia de una rutina de ordenador (por ejemplo, software) se ejecuta en un servidor al tiempo que presta servicio a múltiples entidades usuarias. Una entidad usuaria comprende un grupo de usuarios que comparten un acceso común con privilegios específicos para el software. Con una arquitectura multitenencia de este tipo, una aplicación de software proporciona a cada entidad usuaria una cuota de los datos, configuración, gestión de usuarios, funcionalidad individual de entidades usuarias, así como propiedades no funcionales. Como se ha indicado anteriormente, la arquitectura multitenencia del MTIS 140 descrita en la presente memoria hace que aumente la densidad de las aplicaciones.
Una de las consideraciones en la arquitectura multitenencia del MTIS 140 es cómo evitar que una rutina de ordenador maliciosa (o simplemente mal escrita) de una entidad usuaria acceda a datos de otra entidad usuaria. A este respecto, la solicitud de tarea web descrita en la presente memoria puede invocar un encajonamiento en el MTIS 140. Un encajonamiento es un mecanismo de seguridad para separar programas en ejecución. Proporciona un conjunto de recursos controlado de manera ajustada para que programas huéspedes se ejecuten en los mismos, tales como un espacio dedicado en una memoria. Con ese fin, puede usarse Docker® para crear un encajonamiento seguro (CONTENEDOR) en torno a la solicitud de la tarea web. Por ejemplo, Docker separa aplicaciones de la infraestructura usando tecnología de contenedores, de manera similar a cómo las máquinas virtuales separan el sistema operativo de la parte puramente física. La solicitud de tarea web se puede implementar en forma de un contenedor Docker que proporciona un enlace a una rutina de ordenador y envuelve la rutina de ordenador en un sistema de archivos completo que incluye esencialmente los componentes para ejecutar, tales como el tiempo de ejecución, herramientas del sistema, bibliotecas del sistema, etc., garantizando así que se ejecute en su entorno de destino (es decir, el MTIS 140).
En una forma de realización, la rutina de ordenador personalizada que se ejecuta usando solicitudes de tareas web 124 está en el contexto de una solicitud HTTP. El tiempo de ejecución puede limitarse al tiempo de vida típico de una solicitud HTTP Expresado de otra manera, las solicitudes de tareas web 124 tienen una duración suficientemente corta para ser satisfechas por el ciclo de solicitud/respuesta HTTP o un ciclo equivalente.
Por ejemplo, la solicitud de tarea web 124 acepta una solicitud HTTP POST del cliente 102 que incluye el código de servidor (o un enlace al mismo) en el cuerpo de la solicitud de tarea web 124. En una forma de realización, la solicitud de tarea web 124 especifica también el nombre del contenedor de la tarea web, que indica el límite de aislamiento en el que se ejecutará la rutina de ordenador en el MTIS 140. Puede haber un mapa de 1:1 del cliente con el contenedor de la tarea web, lo cual significa que la rutina de ordenador relacionada con un abonado está siempre aislada de la rutina de ordenador de otro abonado. El MTIS 140 ejecuta la rutina de ordenador personalizada en un entorno aislado, al que se hace referencia, en ocasiones, en la presente memoria, como contenedor de tarea web, y devuelve una respuesta con los resultados. En una forma de realización, la respuesta está en Notación de Objetos JavaScript (JSON). De este modo, la rutina de ordenador personalizada proporcionada por medio de la solicitud de tarea web 124 se ejecuta en un entorno uniforme sobre todas las entidades usuarias.
Una solicitud de tarea web 124 incluye la rutina de ordenador (o un enlace a la misma) así como datos contextuales requeridos durante su ejecución. Por ejemplo, el cliente 102 presenta un cierre de una función JavaScript. El MTIS 140 invoca esa función y proporciona un único parámetro de retrollamada (callback). Cuando la rutina de ordenador personalizada en la solicitud de tarea web ha acabado de ejecutarse en el contenedor de tarea web, llama a la retrollamada y proporciona una indicación de un error o un único valor de resultado. En una forma de realización, ese valor de resultado se serializa a continuación en forma de JSON y se devuelve al cliente 102 en la respuesta HTTP.
En una forma de realización, el MTIS 140 se basa en Node.js, que permite que una rutina de ordenador personalizada utilice un conjunto fijo de módulos de Node.js preaprovisionados en el entorno de la tarea web. El conjunto de módulos soportados puede ser proporcionado por los requisitos específicos de diversos escenarios de extensibilidad. La uniformidad del entorno informático sobre todas las entidades usuarias en el MTIS 140 permite el mantenimiento de una reserva de contenedores de tareas web precalentados, preparados para ser asignados a entidades usuarias cuando llega una solicitud 124. Esto reduce la latencia de un arranque en frío.
El MTIS 140 está configurado para reducir la cantidad de tara en la asignación de recursos para procesar la solicitud de tarea web 124. La tara de asignación de recursos puede presentarse en forma de engendramiento (spawning) de máquinas virtuales, engendramiento de procesos, engendramiento de hilos y asignación de memoria. Por consiguiente, el MTIS 140 puede usar la estructuración de recursos en reservas.
En una forma de realización, pueden aislarse entornos de rutinas de ordenador usando compartimentos de infraestructuras de terceros tales como los proporcionados por Docker (una fuente abierta). Docker simplemente aísla el entorno por abstracción, pero no proporciona multitenencia. También pueden formarse reservas de máquinas virtuales por medio de la infraestructura en la nube del proveedor y/o mediante una solicitud del MTIS 140.
El MTIS 140 puede engendrar una reserva de procesos, y en lugar de desasignar procesos, puede devolver el proceso a la reserva. No obstante, para reducir la tara en la nube, en la práctica, el número de procesos asignados puede asignarse en valores de una sola cifra, ya que se considera que las solicitudes son de un solo hilo. La gestión de los procesos también puede ser gestionada por el entorno de ejecución, tal como la Máquina Virtual de Java o la versión de ejecución de Node.js®.
El MTIS 140 también puede usar primitivas de aislamiento y contexto, tales como v8::isolate y v8::context para garantizar la ejecución de la rutina informática de una manera aislada. En una forma de realización, el MTIS 140 puede gestionar su propia memoria. Alternativamente, el entorno de ejecución, tal como la Máquina Virtual de Java o Node.js®, puede gestionar su propia memoria. Obsérvese que el entorno de ejecución puede tener su propio asignador de memoria y su propia recolección de basura.
En una forma de realización, puede implementarse la seguridad usando primitivas de aislamiento. Específicamente, un entorno de ejecución puede ejecutar la rutina informática en un encajonamiento respectivo. El MTIS 140 podría aplicar seguridad y autenticación adicionales. Más típicamente, la autenticación inicial puede ser con respecto a una cuenta pública en la infraestructura en la nube. De este modo, no es necesario que la autenticación se produzca según cada solicitud individual, con lo cual se mejora el rendimiento.
En una forma de realización, las interconexiones entre lenguajes son gestionadas por el entorno de ejecución (es decir, el MTIS 140). Las interconexiones pueden ser nativas con respecto al entorno de ejecución, o alternativamente pueden ser mediante un módulo de expansión, típicamente en forma de una biblioteca de enlaces dinámicos. También se pueden descubrir dinámicamente entornos de ejecución (con lenguajes diferentes) ya que los encajonamientos, que pueden estar preconfigurados con diversos entornos de ejecución, pueden enumerar esos entornos de ejecución de manera programática. Por consiguiente, el MTIS 140 puede determinar qué se admite, y responder rápidamente con un mensaje de error en lugar de tener que engendrar/invocar un encajonamiento.
La precompilación puede ser una optimización implementada por medio del MTIS 140. Por ejemplo, la rutina de ordenador incorporada en una solicitud de tarea web 124 puede estar en código de bytes en lugar de código fuente. Cuando se invoquen procedimientos almacenados, una base de datos en el lado del servidor puede tener un procedimiento almacenado precompilado (obsérvese que el procedimiento almacenado puede residir en el MTIS 140). De esta manera, puede hacerse que una solicitud de tarea web 124 dependa meramente de parámetros de la rutina de ordenador enviada.
En varias formas de realización, el sistema multitenencia descrito en la presente memoria proporciona diversas garantías para una ejecución segura de rutinas de ordenador. En primer lugar, se produce un aislamiento de datos en el que se evita que la rutina de ordenador de una entidad usuaria acceda a la rutina o datos de ordenador de otra entidad usuaria. Por ejemplo, si una entidad usuaria ejecuta una rutina o datos de ordenador que accede a una base de datos personalizada usando una cadena de conexión o URL con una contraseña incorporada, se evita que la rutina de ordenador de otra entidad usuaria que se ejecute en el mismo sistema descubra esa contraseña.
En segundo lugar, se proporciona un consumo controlado de recursos para mitigar ataques autenticados del tipo Denegación de Servicio (DOS). Con ese fin, en una forma de realización, el encajonamiento de la solicitud de tarea web 124 limita la cantidad de memoria, CPU, y otros recursos del sistema que puede usar una entidad usuaria cualquiera.
A continuación se hace referencia a la figura 3, que ilustra un ejemplo de máquina virtual (VM) de tareas web que se puede usar como el MTIS 140 de la figura 1. Para aislar la rutina y los datos de ordenador de una entidad usuaria con respecto a otra, la rutina de ordenador de cada entidad usuaria se ejecuta en su propio contenedor de tarea web (por ejemplo, Docker) en un encajonamiento 310. Cuando llega una solicitud HTTP a una VM de tareas web, tal como el MTIS 140, la misma es procesada en primer lugar por un proxy 306. El proxy 306 mantiene un estado que representa la asociación entre entidades usuarias y contenedores. En una forma de realización, el proxy 306 mira la configuración de etcd para determinar si ya se ha asignado un contenedor de tarea web para una entidad usuaria particular. En caso afirmativo, el proxy 306 reenvía la solicitud a ese contenedor de tarea web 310. En caso negativo, el proxy asigna un nuevo contenedor de tarea web para esa entidad usuaria de entre una reserva de contenedores de tareas web precalentados disponibles en el cluster de tareas web. A continuación, el proxy registra esa asociación en etcd (es decir, un demonio que se ejecuta sobre todos los ordenadores en un cluster y proporciona un registro de configuración dinámico, permitiendo que se compartan diversos datos de configuración entre los miembros del cluster) con vistas a posteriores solicitudes.
La reserva precalentada de contenedores de tareas web la posibilita el entorno de ejecución uniforme para todas las entidades usuarias. El hecho de poder escoger un contenedor precalentado de entre una reserva reduce la latencia del arranque en frío en comparación con el aprovisionamiento de un contenedor sobre la marcha, incluso si se tiene en cuenta la latencia de arranque de los contenedores Docker, que ya es baja.
En una forma de realización, cualquier contenedor de tarea web individual es solo un simple servidor HTTP que permite procesar múltiples solicitudes simultáneas en nombre de una única entidad usuaria. Las solicitudes que se ejecutan dentro de un contenedor de tarea web específico no están aisladas entre sí. El tiempo de vida de los contenedores de tareas web lo gestiona por el demonio controlador, que se ejecuta en un contenedor Docker de confianza y, por lo tanto, puede finalizar cualquier contenedor de tarea web de un cluster siguiendo una política de gestión de tiempos de vida preconfigurada.
En una forma de realización, además de ejecutar la rutina de ordenador de cada entidad usuaria en su propio contenedor Docker 310, se configuran reglas de cortafuegos de salida en un cluster de tareas web. Estas reglas evitan que una rutina de ordenador no fiable en un contenedor de tarea web se comunique con otros contenedores de tareas web o la infraestructura de tareas web. El establecimiento de las reglas del cortafuegos es posible debido a que el servidor HTTP del contenedor de tarea web se está ejecutando en una red local separada de la red del anfitrión por un puente 308 (por ejemplo, creado mediante Docker). En una forma de realización, la rutina de ordenador que se ejecuta en el contenedor de tarea web puede iniciar llamadas salientes hacia la internet pública. Esto permite una comunicación saliente desde la rutina de ordenador personalizada a fuentes de datos y servicios externos, tales como la base de datos de un cliente o servicios periféricos de empresas.
Para limitar el consumo de memoria y de CPU, se puede usar un mecanismo de grupo de control (cgroups) (por ejemplo, proporcionado por Docker®). Debe señalarse que cgroups son mecanismos admitidos por Linux, mientras que Docker® es una tecnología que se construye por encima de cgroups. Además, cada contenedor de tarea web puede crear un usuario de Linux transitorio y configura límites de Módulos de Autenticación Conectables (PAM) para ese usuario en el arranque. Estos dos mecanismos juntos ayudan a evitar una variedad de ataques sobre la memoria y la CPU, tales como las bombas fork.
Ejemplo de proceso de flujo de llamadas
Con la visión general anterior del sistema multitenencia a través de código encapsulado en solicitudes de servidor, puede resultar útil a continuación considerar una argumentación, de alto nivel, de ejemplos de procesos de flujo de llamadas. Con ese fin, la figura 4 ilustra un ejemplo de proceso de flujo de llamadas de alto nivel para ejecutar un código (por ejemplo, una rutina de ordenador) en un entorno de una infraestructura multitenencia, en el que la rutina de ordenador ejecutada es no persistente. El proceso de flujo de llamadas 400 se ilustra en forma de un conjunto de etapas en un flujo de llamadas lógico, que representa una secuencia de operaciones que se pueden implementar en hardware, software o una combinación de los mismos. En el contexto del software, las etapas representan instrucciones ejecutables por ordenador que, cuando son ejecutadas por uno o más procesadores, realizan las operaciones mencionadas. En general, las instrucciones ejecutables por ordenador pueden incluir rutinas, programas, objetos, componentes, estructuras de datos y similares que realizan funciones particulares o implementan tipos de datos abstractos particulares. El orden en el que se describen las operaciones no está destinado a considerarse limitativo, y un número cualquiera de los bloques descritos se puede combinar en cualquier orden y/o en paralelo para implementar el proceso. Con fines descriptivos, el proceso 400 se describe en referencia al sistema 100 de la figura 1. En el ejemplo de flujo de llamadas 400, hay un cliente 102, un servidor de tareas web 107, y un servidor de infraestructura multitenencia (MTIS) 140 en una nube.
En la etapa 408, un desarrollador prepara un segmento de código (por ejemplo, una rutina de ordenador) destinado a ejecutarse en su dispositivo informático, representado en el flujo 400 como el cliente 102. En una forma de realización, la rutina de ordenador se almacena en un servidor de almacenamiento de archivos en línea 132.
En la etapa 410, se establece una conexión con el servidor de tareas web 107 y se envía una solicitud a un punto extremo bien definido a, donde la rutina de ordenador para una aplicación arbitraria a ejecutar es un parámetro de la solicitud. La solicitud de tarea web 124 incluye un token de tarea web 108 así como datos de cliente 106. En varias formas de realización, el token de tarea web 108 puede comprender la rutina de ordenador (o un enlace URL a unos medios de almacenamiento de archivos en línea que almacenan la rutina de ordenador 130) y secretos de cliente 112 asociados a la rutina de ordenador. En una forma de realización, si el cliente 102 no puede acceder al servidor de tareas web 107, entonces se devuelve al cliente 102 un error de conexión fallida. Con ese fin, la rutina de ordenador puede tener un manejador para afrontar este error.
En la etapa 412, el servidor de tareas web 107 recibe el token de tarea web junto con los datos de cliente 106 y determina el tipo de rutina de ordenador usado. Sobre la base de la rutina de ordenador, el servidor de tareas web 107 crea una solicitud de tarea web 124 que incluye el token de tarea web 108 y los datos de cliente. En varias formas de realización, el token de tarea web puede invocar un contenedor multitenencia (por ejemplo, tal como Docker) que envuelve la rutina de ordenador en un entorno completo que incluye los componentes en los que ejecutarse en aislamiento en el MTIS 140. En ocasiones, a este contenedor se le hace referencia en la presente memoria como contenedor de tarea web.
En una forma de realización, el servidor de tareas web 107 es un servidor HTTP, la conexión durante la comunicación 410 entre el cliente 102 y el servidor de tareas web 107 es una conexión HTTP, y la solicitud de tarea web 124 que incluye el token de tarea web y los datos 106 es una solicitud HTTP. Alternativamente, pueden usarse otros protocolos, o Llamadas a Procedimientos Remotos (RPC), siempre que solamente se expongan al desarrollador un único punto extremo generalizado.
En la etapa 414, el servidor de tareas web 107 envía la solicitud de tarea web 124 al MTIS 140. A este respecto, el servidor de tareas web 107 solicita un contenedor que tiene toda la estructura que debe usar la rutina de ordenador del MTIS 140. En una forma de realización, el MTIS 140 puede incluir interconexiones entre lenguajes para diversos lenguajes admitidos. Por ejemplo, el MTIS 140 puede tener una interconexión para JavaScript e interconexiones para C#. Cuando un lenguaje no admitido llegue en una solicitud, el MTIS 140 puede proporcionar un mensaje de error adecuado.
En la etapa 416, el MTIS 140 extrae la rutina de ordenador a ejecutar y ejecuta la rutina de ordenador en un entorno aislado (es decir, un contenedor de tarea web) del MTIS 140. El contenedor de tarea web se puede ejecutar en un entorno de encajonamiento del MTIS 140. El MTIS 140 construye también una respuesta en un formato que es compatible con los protocolos usados por el servidor de tareas web 107. En varias formas de realización, la respuesta puede estar en XML, JSON, y similares. De este modo, el MTIS proporciona un entorno de ejecución genérico y uniforme para la solicitud de tarea web recibida.
En una forma de realización, el MTIS realiza un seguimiento de los recursos (por ejemplo, CPU, memoria, etc.) que se han consumido durante la ejecución de la rutina de ordenador en el contenedor de tarea web del MTIS 140 asociado a la identificación (ID) de solicitud, con fines relativos a la facturación (es decir, etapa 418). El MTIS 140 puede usar la ID de solicitud generada por el servidor de tareas web 107 y asociarla a una ID de Hilo o bien de la versión de ejecución de JavaScript, o bien del sistema operativo, o una generada internamente por el MTIS 140. En una forma de realización, asociando los recursos del hilo usados a la ID de solicitud, se logra una medición basada en los recursos consumidos por cada solicitud. No es necesario limitar el seguimiento de los recursos a la CPU, la memoria (por ejemplo, memoria de acceso aleatorio (RAM), disco duro), sino que los mismos pueden incluir cualquier recurso medible tal como recursos de red utilizados durante la ejecución de la rutina de ordenador.
En una forma de realización, en la etapa 420, el MTIS envía una respuesta al servidor de tareas web 107. La respuesta puede ser un resultado calculado basado en la rutina de ordenador ejecutada en el MTIS 140. Si el MTIS no puede satisfacer la solicitud, o puede que no satisfaga la solicitud a tiempo, el MTIS puede devolver una respuesta al servidor de tareas web con una respuesta adecuada (es decir, mensaje de error). De este modo, la respuesta del MTIS puede ser un resultado calculado basado en la rutina de ordenador ejecutada o un mensaje de error adecuado.
En la etapa 422, la respuesta se reenvía desde el servidor de tareas web 107 al cliente 102. De manera alternativa o adicional, la respuesta se puede reenviar directamente desde el MTIS al cliente 102.
Opcionalmente, en la etapa 424, el MTIS 140 puede recibir una confirmación desde el servidor de tareas web en relación con que el resultado ha sido recibido por este último. En la etapa 426, el MTIS 140 lleva a cabo una desasignación de recursos, según resulte adecuado. En una forma de realización, un contenedor que no ha sido usado no se devuelve a la reserva; por el contrario, el mismo se descarta y es sustituido. El MTIS 140 destruye el contenedor de tarea web, garantizando así que la rutina de ordenador no se almacena en reposo.
Ejemplos de casos prácticos
Con la explicación anterior del sistema y el método de encapsulado de una rutina de ordenador en una solicitud de servidor, puede resultar útil proporcionar una descripción de alto nivel de algunos ejemplos de casos prácticos. Los conceptos y el sistema descritos en la presente memoria se pueden aplicar a diversos casos prácticos. Por ejemplo, se pueden aplicar a aplicaciones distribuidas, en las que una aplicación puede estar diseñada en componentes separados, estructurados cada uno de ellos para funcionar de manera independiente con respecto a otros. Esos componentes separados pueden enviar la rutina de ordenador destinada a ejecutarse por medio del MTIS 140 a diferentes instancias.
En un ejemplo, el sistema descrito en la presente memoria se puede usar para derivaciones de descongestión. Con ese fin, una aplicación puede ejecutar una rutina de manera o bien local o bien remota usando el MTIS 140. En situaciones en las que los recursos informáticos locales no están disponibles o son insuficientes, la aplicación puede derivar solicitudes informáticas a la nube por medio del MTIS 140.
En un ejemplo, los conceptos descritos en la presente memoria se pueden usar para redactar guiones de instrucciones de servicios WEB. Una aplicación puede proporcionar un mecanismo para que los usuarios finales elaboren guiones de instrucciones que pongan a su disposición diferentes funcionalidades incorporadas en la rutina de ordenador. Algunos de los guiones de instrucciones se pueden ejecutar en la nube por medio del MTIS 140.
En un ejemplo, el sistema descrito en la presente memoria se puede usar en aplicaciones de ejecución asíncrona. En un escenario de este tipo, no es necesario que la rutina de ordenador ejecutada en el MTIS 140 se ejecute de forma síncrona. A este respecto, el servidor de tareas web 107 puede actuar como un despachador para procesos de larga duración/larga ejecución.
En un ejemplo, los conceptos descritos en la presente memoria se pueden usar para seguridad/aplicaciones verticales. Puede implementarse una API de Seguridad para ejecutarse en una aplicación de servidor de infraestructura multitenencia que mantenga un encajonamiento. En una forma de realización, el MTIS 140 puede admitir cifrado para proteger la conexión entre un cliente y la aplicación del servidor de infraestructura multitenencia. Puesto que la rutina de ordenador no reside en el MTIS 140 y puesto que todas las rutinas de ordenador se ejecutan en un encajonamiento seguro, el MTIS 140 proporciona un entorno de ejecución seguro para funciones de autenticación según se expone mediante una API de seguridad. En cuanto a la seguridad, en una implementación, el MTIS 140 se puede usar para implementar funciones de autenticación, autorización, auditoría y/o medición en un nivel de proxy en una aplicación de múltiples capas.
Ejemplo de plataforma informática
Tal como se ha descrito anteriormente, en ordenadores conectados para una comunicación de datos por medio de la red 130, actuando como servidor de cliente 102, servidor de tareas web 107 y MTIS 140, según se muestra en la figura 5, se pueden implementar funciones para establecer una conexión con un servidor de tareas web, enviar una solicitud con el fin de ejecutar una rutina de ordenador, enviar y recibir mensajes, enviar y recibir tokens de tareas web, crear contenedores de tareas web, ejecutar una rutina de ordenador en un entorno aislado, y otras funciones. Aunque pueden usarse dispositivos de propósito especial, dichos dispositivos también se pueden implementar usando una o más plataformas de hardware destinadas a representar una clase general de dispositivo de procesado de datos usado comúnmente con el fin de ejecutar programación de “servidores” de manera que se implementen funciones tales como las funciones descritas en la presente memoria, aunque con una conexión de red adecuada para la comunicación de datos.
Las figuras 5 y 6 proporcionan ilustraciones de diagramas de bloques funcionales de plataformas de hardware de ordenadores de propósito general que también se pueden aplicar para la informática en la nube. La figura 5 ilustra una red o plataforma de ordenador anfitrión, como la que se puede usar típicamente para implementar un servidor, tal como un servidor de tareas web 107 o MTIS 140. La figura 6 representa un dispositivo con elementos de interfaz de usuario, como los que se pueden usar para implementar un ordenador personal o un dispositivo informático de cliente tal como el cliente 102. Se cree que la estructura general y el funcionamiento general de un equipo tal como el que se muestra en las figuras 5 y 6 deben resultar evidentes a partir de las ilustraciones de alto nivel.
Un ordenador de propósito general configurado como un servidor, por ejemplo, incluye una interfaz de comunicación de datos para una comunicación de datos por paquetes a través de la red 130. El ordenador servidor incluye también una unidad de procesado central (CPU), en forma de uno o más procesadores, para ejecutar instrucciones de programas. Típicamente, la plataforma del servidor incluye un bus de comunicación interno, medios de almacenamiento de programas y medios de almacenamiento de datos para diversos archivos de datos destinados a ser procesados y/o comunicados por el servidor, aunque normalmente el servidor recibe programación y datos a través de comunicaciones de red. Los elementos de hardware, los sistemas operativos y los lenguajes de programación de dichos servidores son de carácter convencional. Evidentemente, las funciones del servidor se pueden implementar de una manera distribuida en una serie de plataformas similares, para distribuir la carga de procesado.
Tal como se ha descrito anteriormente, las solicitudes al MTIS se pueden realizar desde una máquina de cliente. Una máquina de cliente puede ser cualquier dispositivo con un procesador, memoria y una conexión de red suficientes para conectarse a un servidor en la nube, ya sea de manera directa o mediante Internet, similar al de la figura 6. Típicamente, habrá un sistema operativo. Las configuraciones típicas son una unidad de procesado central, una RAM y conectividad Wi-Fi o de Ethernet. La memoria será soportes legibles por ordenador y/o tendrá acceso a otros soportes legibles por ordenador, y ejecutará una aplicación de cliente compuesta por código ejecutable por ordenador residente en la memoria y/u otros soportes legibles por ordenador.
De manera similar, un servidor en la nube, tal como el representado en la figura 5, puede ser un dispositivo con un procesador, memoria y una conexión de red suficientes para conectarse a una máquina de cliente ya sea directamente o mediante Internet. Igual que con una máquina de cliente, típicamente habrá un sistema operativo. Las configuraciones típicas son una unidad de procesado central, una RAM y conectividad Wi-Fi o de Ethernet. La memoria será soportes legibles por ordenador y/o tendrá acceso a otros soportes legibles por ordenador, y ejecutará una aplicación de cliente compuesta por código ejecutable por ordenador que reside en la memoria y/u otros soportes legibles por ordenador.
Generalmente, el servidor en la nube ejecutará un entorno de virtualización que puede crear máquinas virtuales. En cada máquina virtual, puede haber un sistema operativo, o entorno a nivel de sistema. Cada máquina virtual puede engendrar procesos, cada uno de los cuales puede engendrar hilos. Un entorno de ejecución, tal como una Máquina Virtual de Java, o versión de ejecución de .NET puede ejecutarse en una máquina virtual y gestionar procesos e hilos.
Los soportes legibles por ordenador, tales como la RAM y la ROM representadas en las figuras 5 y 6 incluyen, por lo menos, dos tipos de soportes legibles por ordenador, a saber soportes de almacenamiento en ordenador y soportes de comunicaciones. Los soportes de almacenamiento en ordenador incluyen soportes extraíbles y no extraíbles, volátiles y no volátiles, implementados en cualquier método o tecnología para el almacenamiento de información tal como instrucciones legibles por ordenador, estructuras de datos, módulos de programas u otros datos. Los soportes de almacenamiento en ordenador incluyen, aunque sin carácter limitativo, RAM, ROM, EEPROM, memoria flash u otra tecnología de memorias, CD-ROM, discos versátiles digitales (DVD) u otros medios de almacenamiento ópticos, casetes magnéticos, cinta magnética, medios de almacenamiento en disco magnéticos u otros dispositivos de almacenamiento magnéticos, o cualquier otro soporte sin capacidad de transmisión que se pueda usar para almacenar información con vistas a un acceso por parte de un dispositivo informático. Por contraposición, los soportes de comunicación pueden incorporar instrucciones legibles por ordenador, estructuras de datos, módulos de programa u otros datos en una señal de datos modulada, tal como una onda portadora, u otro mecanismo de transmisión. Según se define en la presente memoria, los soportes de almacenamiento en ordenador no incluyen soportes de comunicación.
Las funcionalidades de software implican programación, incluido código ejecutable así como datos almacenados asociados, por ejemplo, archivos usados para aplicaciones en el servidor de tareas web 107 y el MTIS 140 con el fin de enviar una solicitud para ejecutar una rutina de ordenador, enviar y recibir mensajes, enviar y recibir tokens de tareas web, crear contenedores de tareas web, ejecutar una rutina de ordenador en un entorno aislado, y otras funciones. El código de software es ejecutable por el dispositivo informático. Durante su funcionamiento, el código se almacena dentro del dispositivo informático. No obstante, en otras ocasiones, el software se puede almacenar en otras ubicaciones y/o se puede transportar para cargarse en el sistema del dispositivo informático adecuado. La ejecución de dicho código por parte de un procesador del dispositivo informático permite que el dispositivo informático realice varias funciones, esencialmente según la forma aplicada en las implementaciones descritas e ilustradas en la presente memoria.
Por lo tanto, aspectos de los métodos de recepción y procesado de datos de nodos según se ha expresado anteriormente en líneas generales se pueden incorporar en la programación. Aspectos de programas de la tecnología pueden considerarse como “productos” o “artículos de fabricación” típicamente en forma de código ejecutable y/o datos asociados que se transportan o incorporan en un tipo de soporte no transitorio legible por máquina.
Conclusión
Se entenderá que los términos y expresiones usados en la presente memoria tienen el significado común acorde a dichos términos y expresiones con respecto a sus áreas correspondientes de investigación y estudio excepto cuando en la presente memoria se hayan expuesto otros significados específicos. Los términos relacionales tales como primero y segundo y similares se pueden usar simplemente para diferenciar una entidad o acción con respecto a otra sin requerir o implicar necesariamente ninguna de estas relaciones u órdenes concretos entre dichas entidades o acciones. Los términos “comprende”, “comprendiendo”, o cualquier otra variante de los mismos, están destinados a cubrir una inclusión no exclusiva, de tal manera que un proceso, método, artículo u aparato que comprende una lista de elementos no incluye únicamente sus elementos sino que puede incluir otros elementos no enumerados expresamente o inherentes a dicho proceso, método, artículo o aparato. Un elemento precedido por “uno” o “una”, sin otras restricciones, no excluye la existencia de elementos idénticos adicionales en el proceso, método, artículo o aparato que comprende el elemento.
El Resumen de la Exposición se proporciona para permitir que el lector determine rápidamente la naturaleza de la exposición técnica. Se presenta entendiendo que el mismo no se usará para interpretar o limitar el alcance de las reivindicaciones. Además, en la anterior Descripción Detallada, puede observarse que diversas características se agrupan entre sí en varias formas de realización con el fin de optimizar la exposición. Este método de exposición no debe interpretarse de manera que transmita una intención de que las formas de realización reivindicadas requieren más características que las mencionadas expresamente en cada reivindicación. Por el contrario, el alcance de la invención queda definido por las reivindicaciones adjuntas.

Claims (18)

REIVINDICACIONES
1. Servidor de infraestructura multitenencia, MTIS, (140) configurado para proporcionar un entorno con el fin de ejecutar una rutina de ordenador de una aplicación arbitraria, comprendiendo el MTIS:
un procesador;
una interfaz de red acoplada al procesador configurada para permitir comunicaciones a través de una red de comunicación;
un dispositivo de almacenamiento para contenido y programación; y
un programa almacenado en el dispositivo de almacenamiento, configurando la ejecución del programa el servidor de infraestructura multitenencia con el fin de realizar acciones que comprenden:
recibir una solicitud (124) de un servidor de tareas web (107) para ejecutar la rutina de ordenador en un contenedor de tarea web, incluyendo la solicitud unos datos de cliente (106) y unos secretos de cliente (112), incluyendo la solicitud, además, la rutina de ordenador a ejecutar o un enlace de un localizador uniforme de recursos, URL, a la rutina de ordenador;
ejecutar la rutina de ordenador del contenedor de tarea web en el MTIS, incluyendo la ejecución de la rutina de ordenador asignar un contenedor precalentado para una entidad usuaria de entre una reserva de contenedores precalentados, siendo los contenedores precalentados unos contenedores preparados para asignarse antes de que se reciba la solicitud;
tras una ejecución exitosa de la rutina de ordenador, devolver un conjunto de resultados al servidor de tareas web;
tras una ejecución no exitosa de la rutina de ordenador, devolver una rutina de ordenador de error al servidor de tareas web;
determinar recursos consumidos durante la ejecución de la rutina de ordenador; y
destruir el contenedor de tarea web para evitar un almacenamiento persistente de la rutina de ordenador en el MTIS.
2. MTIS según la reivindicación 1, en el que la solicitud no incluye la rutina de ordenador sino el enlace del localizador uniforme de recursos, URL, a la rutina de ordenador.
3. MTIS según la reivindicación 2, en el que la ejecución del programa configura además el MTIS para realizar acciones que comprenden: recuperar una rutina de ordenador del URL proporcionado.
4. MTIS según cualquiera de las reivindicaciones anteriores, en el que la determinación de los recursos consumidos incluye:
obtener una identificación, ID, de solicitud asociada al contenedor de tarea web; y
asociar la ID de solicitud a una ID de hilo para medir los recursos consumidos según cada solicitud.
5. MTIS según cualquiera de las reivindicaciones anteriores, en el que los secretos de cliente y uno de entre la rutina de ordenador a ejecutar o el URL a la rutina de ordenador están protegidos criptográficamente contra manipulaciones indebidas y exposición.
6. MTIS según cualquiera de las reivindicaciones anteriores, en el que el contenedor de tarea web incluye todas las dependencias de la rutina de ordenador para su ejecución en un entorno aislado en el MTIS.
7. MTIS según la reivindicación 6, en el que el entorno aislado es un encajonamiento en el MTIS.
8. MTIS según cualquiera de las reivindicaciones anteriores, en el que los recursos consumidos incluyen potencia de procesamiento y memoria usados durante la ejecución de la rutina de ordenador.
9. MTIS según cualquiera de las reivindicaciones anteriores, en el que la destrucción del contenedor de tarea web se produce como respuesta a la recepción de una confirmación, desde el servidor de tareas web, de que el contenedor de tarea web ha recibido el conjunto de resultados o la rutina de ordenador de error.
10. MTIS según cualquiera de las reivindicaciones anteriores, en el que la rutina de ordenador es independiente del sistema operativo del MTIS.
11. MTIS según cualquiera de las reivindicaciones anteriores, en el que el servidor de tareas web es un servidor HTTP y la solicitud es una solicitud HTTP.
12. MTIS según cualquiera de las reivindicaciones anteriores, en el que el conjunto de resultados está en Notación de Objetos JavaScript, JSON.
13. MTIS según cualquiera de las reivindicaciones anteriores, en el que el MTIS proporciona aislamiento de datos para cada entidad usuaria de tal manera que se evita que una rutina de ordenador de una entidad usuaria acceda a una rutina de ordenador o datos de otra entidad usuaria.
14. Método de ejecución de una rutina de ordenador de una aplicación arbitraria, comprendiendo el método: recibir una solicitud (124) de un servidor de tareas web (107) para ejecutar la rutina de ordenador en un contenedor de tarea web de un servidor de infraestructura multitenencia, MTIS, (140), incluyendo la solicitud unos datos de cliente (106) y unos secretos de cliente (112), incluyendo la solicitud, además, la rutina de ordenador a ejecutar o un enlace de un localizador uniforme de recursos, URL, a la rutina de ordenador; ejecutar la rutina de ordenador del contenedor de tarea web en el MTIS, incluyendo la ejecución de la rutina de ordenador asignar un contenedor precalentado para una entidad usuaria de entre una reserva de contenedores precalentados, siendo los contenedores precalentados unos contenedores preparados para asignarse antes de que se reciba la solicitud;
tras una ejecución exitosa de la rutina de ordenador, devolver un conjunto de resultados al servidor de tareas web;
tras una ejecución no exitosa de la rutina de ordenador, devolver una notificación de error al servidor de tareas web;
determinar recursos consumidos durante la ejecución de la rutina de ordenador; y
destruir el contenedor de tarea web para evitar un almacenamiento persistente de la rutina de ordenador en el MTIS.
15. Método según la reivindicación 14, en el que el contenedor de tarea web incluye todas las dependencias de la rutina de ordenador para su ejecución en un entorno aislado en el MTIS.
16. Método según la reivindicación 14 o 15, en el que la destrucción del contenedor de tarea web se produce como respuesta a la recepción de una confirmación, desde el servidor de tareas web, de que el contenedor de tarea web ha recibido el conjunto de resultados o la notificación de error.
17. Método según cualquiera de las reivindicaciones 14 a 16, en el que el conjunto de resultados está en Notación de Objetos JavaScript, JSON.
18. Método según cualquiera de las reivindicaciones 14 a 17, que comprende, además, proporcionar aislamiento de datos para cada entidad usuaria de tal manera que se evita que una rutina de ordenador de una entidad usuaria acceda a una rutina de ordenador o datos de otra entidad usuaria.
ES15864053T 2014-11-25 2015-11-25 Multitenencia a través de código encapsulado en solicitudes de servidor Active ES2877363T3 (es)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US201462084511P 2014-11-25 2014-11-25
US14/951,223 US10516733B2 (en) 2014-11-25 2015-11-24 Multi-tenancy via code encapsulated in server requests
PCT/US2015/062635 WO2016086111A1 (en) 2014-11-25 2015-11-25 Multi-tenancy via code encapsulated in server requests

Publications (1)

Publication Number Publication Date
ES2877363T3 true ES2877363T3 (es) 2021-11-16

Family

ID=56011438

Family Applications (1)

Application Number Title Priority Date Filing Date
ES15864053T Active ES2877363T3 (es) 2014-11-25 2015-11-25 Multitenencia a través de código encapsulado en solicitudes de servidor

Country Status (11)

Country Link
US (6) US10516733B2 (es)
EP (2) EP3863262A1 (es)
JP (1) JP6722184B2 (es)
KR (1) KR102372568B1 (es)
AR (1) AR102797A1 (es)
AU (2) AU2015353500B2 (es)
CA (1) CA2968858A1 (es)
DK (1) DK3210150T3 (es)
ES (1) ES2877363T3 (es)
MX (1) MX2017006842A (es)
WO (1) WO2016086111A1 (es)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20230035701A1 (en) * 2014-11-25 2023-02-02 Okta, Inc. Multi-tenancy via code encapsulated in server requests

Families Citing this family (44)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9678773B1 (en) 2014-09-30 2017-06-13 Amazon Technologies, Inc. Low latency computational capacity provisioning
US9600312B2 (en) 2014-09-30 2017-03-21 Amazon Technologies, Inc. Threading as a service
US9146764B1 (en) 2014-09-30 2015-09-29 Amazon Technologies, Inc. Processing event messages for user requests to execute program code
US9537788B2 (en) 2014-12-05 2017-01-03 Amazon Technologies, Inc. Automatic determination of resource sizing
US9733967B2 (en) 2015-02-04 2017-08-15 Amazon Technologies, Inc. Security protocols for low latency execution of program code
US9588790B1 (en) 2015-02-04 2017-03-07 Amazon Technologies, Inc. Stateful virtual compute system
US11132213B1 (en) 2016-03-30 2021-09-28 Amazon Technologies, Inc. Dependency-based process of pre-existing data sets at an on demand code execution environment
US10855725B2 (en) * 2016-06-02 2020-12-01 Microsoft Technology Licensing, Llc Hardware-based virtualized security isolation
US10102040B2 (en) 2016-06-29 2018-10-16 Amazon Technologies, Inc Adjusting variable limit on concurrent code executions
US10360410B2 (en) * 2016-11-14 2019-07-23 International Business Machines Corporation Providing containers access to container daemon in multi-tenant environment
CN108111469B (zh) * 2016-11-24 2020-06-02 阿里巴巴集团控股有限公司 一种在集群中建立安全通道的方法和装置
US10318314B2 (en) * 2017-02-24 2019-06-11 International Business Machines Corporation Techniques for managing software container dependencies
EP3396543A1 (en) * 2017-04-26 2018-10-31 Nokia Solutions and Networks Oy Method to allocate/deallocate resources on a platform, platform and computer readable medium
US10643004B2 (en) * 2017-05-16 2020-05-05 Apple Inc. Techniques for enabling a software application to access files at a computing device while enforcing privacy measures
EP3652642B1 (en) * 2017-07-11 2022-06-22 Telefonaktiebolaget LM Ericsson (Publ) Methods and arrangements for robot device control in a cloud
US11366941B2 (en) * 2017-07-13 2022-06-21 Tata Consultancy Services Limited Systems and methods for designing unified architecture models for architecting digital products and digital services
GB201716173D0 (en) 2017-10-04 2017-11-15 Palantir Technologies Inc Creation and execution of customised code for a data processing platform
KR102146602B1 (ko) * 2017-12-22 2020-08-20 건국대학교 산학협력단 도커를 이용한 컨테이너 기반 딥러닝 개발 플랫폼 제공 방법 및 장치
US10742524B2 (en) * 2018-01-11 2020-08-11 Monza Cloud, LLC Framework for standardizing development and deployment of services
US10853115B2 (en) 2018-06-25 2020-12-01 Amazon Technologies, Inc. Execution of auxiliary functions in an on-demand network code execution system
US11146569B1 (en) 2018-06-28 2021-10-12 Amazon Technologies, Inc. Escalation-resistant secure network services using request-scoped authentication information
US10915343B2 (en) * 2018-06-29 2021-02-09 Atlassian Pty Ltd. Server computer execution of client executable code
US11099870B1 (en) 2018-07-25 2021-08-24 Amazon Technologies, Inc. Reducing execution times in an on-demand network code execution system using saved machine states
US11243953B2 (en) 2018-09-27 2022-02-08 Amazon Technologies, Inc. Mapreduce implementation in an on-demand network code execution system and stream data processing system
US11099917B2 (en) 2018-09-27 2021-08-24 Amazon Technologies, Inc. Efficient state maintenance for execution environments in an on-demand code execution system
US11943093B1 (en) 2018-11-20 2024-03-26 Amazon Technologies, Inc. Network connection recovery after virtual machine transition in an on-demand network code execution system
US11010188B1 (en) 2019-02-05 2021-05-18 Amazon Technologies, Inc. Simulated data object storage using on-demand computation of data objects
US10871956B2 (en) 2019-02-12 2020-12-22 Open Text Corporation Methods and systems for packaging and deployment of applications in a multitenant platform
US11861386B1 (en) * 2019-03-22 2024-01-02 Amazon Technologies, Inc. Application gateways in an on-demand network code execution system
EP3967008A4 (en) * 2019-05-09 2022-12-21 Services Pétroliers Schlumberger CUSTOMER ISOLATION WITH CLOUD-NATIVE FEATURES
US11119809B1 (en) 2019-06-20 2021-09-14 Amazon Technologies, Inc. Virtualization-based transaction handling in an on-demand network code execution system
US11190609B2 (en) 2019-06-28 2021-11-30 Amazon Technologies, Inc. Connection pooling for scalable network services
US11159528B2 (en) 2019-06-28 2021-10-26 Amazon Technologies, Inc. Authentication to network-services using hosted authentication information
US11586470B2 (en) * 2019-08-07 2023-02-21 International Business Machines Corporation Scalable workflow engine with a stateless orchestrator
US11119826B2 (en) 2019-11-27 2021-09-14 Amazon Technologies, Inc. Serverless call distribution to implement spillover while avoiding cold starts
US11714682B1 (en) 2020-03-03 2023-08-01 Amazon Technologies, Inc. Reclaiming computing resources in an on-demand code execution system
US11640461B2 (en) 2020-03-06 2023-05-02 Rubrik, Inc. Secure runtime for virtual machines
US11875187B2 (en) * 2020-03-06 2024-01-16 Rubrik, Inc. Secure runtime for virtual machines
US11550713B1 (en) 2020-11-25 2023-01-10 Amazon Technologies, Inc. Garbage collection in distributed systems using life cycled storage roots
US11593270B1 (en) 2020-11-25 2023-02-28 Amazon Technologies, Inc. Fast distributed caching using erasure coded object parts
CN112579098B (zh) * 2020-12-25 2024-02-06 平安银行股份有限公司 软件发布方法、装置、电子设备及可读存储介质
DE102021204757A1 (de) * 2021-05-11 2022-11-17 WAGO Verwaltungsgesellschaft mit beschränkter Haftung Verwaltung von Laufzeitcontainern für ein industrielles Automatisierungssystem
US11388210B1 (en) 2021-06-30 2022-07-12 Amazon Technologies, Inc. Streaming analytics using a serverless compute system
KR102569582B1 (ko) * 2022-11-22 2023-08-23 주식회사 디지캡 속성 기반 암호화를 이용한 속성 정보의 선택적 공개 및 영지식 증명 방법

Family Cites Families (51)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6922685B2 (en) 2000-05-22 2005-07-26 Mci, Inc. Method and system for managing partitioned data resources
US7716674B1 (en) 2000-10-06 2010-05-11 Apple Inc. Streaming server administration protocol
US7444620B2 (en) 2003-02-28 2008-10-28 Bea Systems, Inc. Systems and methods for a common runtime container framework
US20060149761A1 (en) 2004-12-09 2006-07-06 Lg Electronics Inc. Structure of objects stored in a media server and improving accessibility to the structure
US8281401B2 (en) 2005-01-25 2012-10-02 Whitehat Security, Inc. System for detecting vulnerabilities in web applications using client-side application interfaces
US8499023B1 (en) 2005-03-23 2013-07-30 Oracle America, Inc. Servlet-based grid computing environment using grid engines and switches to manage resources
WO2008073618A2 (en) 2006-11-06 2008-06-19 Devicevm, Inc. Instant on platform
US7899559B2 (en) 2007-02-27 2011-03-01 Rockwell Automation Technologies, Inc. Language-based organization of controller engine instances
KR101116615B1 (ko) * 2007-03-28 2012-03-07 삼성전자주식회사 자바 가상 머신 상에서 이뤄지는 애플리케이션 및 스레드의자원 관리 시스템 및 방법
US8347405B2 (en) * 2007-12-27 2013-01-01 International Business Machines Corporation Asynchronous java script and XML (AJAX) form-based authentication using java 2 platform enterprise edition (J2EE)
CN101674156B (zh) 2008-09-12 2013-09-11 领特德国有限公司 用于通信系统的重发方案
US8843997B1 (en) 2009-01-02 2014-09-23 Resilient Network Systems, Inc. Resilient trust network services
US8296419B1 (en) 2009-03-31 2012-10-23 Amazon Technologies, Inc. Dynamically modifying a cluster of computing nodes used for distributed execution of a program
CA2675666A1 (en) 2009-08-27 2009-11-05 Ibm Canada Limited - Ibm Canada Limitee Accelerated execution for emulated environments
US8881227B2 (en) * 2010-03-30 2014-11-04 Authentic8, Inc. Secure web container for a secure online user environment
US9104484B2 (en) 2010-04-21 2015-08-11 Salesforce.Com, Inc. Methods and systems for evaluating bytecode in an on-demand service environment including translation of apex to bytecode
US8627426B2 (en) 2010-04-26 2014-01-07 Vmware, Inc. Cloud platform architecture
US8661120B2 (en) 2010-09-21 2014-02-25 Amazon Technologies, Inc. Methods and systems for dynamically managing requests for computing capacity
US8468548B2 (en) 2010-12-17 2013-06-18 Microsoft Corporation Multi-tenant, high-density container service for hosting stateful and stateless middleware components
JP5750972B2 (ja) 2011-03-25 2015-07-22 富士ゼロックス株式会社 情報処理装置、プログラムおよび情報処理システム
US9450838B2 (en) 2011-06-27 2016-09-20 Microsoft Technology Licensing, Llc Resource management for cloud computing platforms
US20130031144A1 (en) * 2011-07-26 2013-01-31 Salesforce.Com, Inc. Systems and methods for creating support cases in a multi-tenant database system environment
WO2013059399A1 (en) 2011-10-20 2013-04-25 Monsanto Technology Llc Plant stand counter
US9047476B2 (en) 2011-11-07 2015-06-02 At&T Intellectual Property I, L.P. Browser-based secure desktop applications for open computing platforms
US8819210B2 (en) 2011-12-06 2014-08-26 Sap Portals Israel Ltd Multi-tenant infrastructure
US8751800B1 (en) 2011-12-12 2014-06-10 Google Inc. DRM provider interoperability
US8539506B2 (en) 2012-02-09 2013-09-17 Microsoft Corporation Dynamic injection of code into running process
US10031782B2 (en) 2012-06-26 2018-07-24 Juniper Networks, Inc. Distributed processing of network device tasks
US20140095974A1 (en) 2012-09-28 2014-04-03 Sap Ag Secure html javascript code snippet usage in application integration
US9542546B2 (en) * 2012-09-28 2017-01-10 Volusion, Inc. System and method for implicitly resolving query scope in a multi-client and multi-tenant datastore
US9210054B2 (en) * 2012-11-14 2015-12-08 International Business Machines Corporation Secure metering and accounting for cloud services
US9922192B1 (en) 2012-12-07 2018-03-20 Bromium, Inc. Micro-virtual machine forensics and detection
CN104050201B (zh) * 2013-03-15 2018-04-13 伊姆西公司 用于多租户分布式环境中的数据管理的方法和设备
US20140330936A1 (en) 2013-05-02 2014-11-06 International Business Machines Corporation Secure isolation of tenant resources in a multi-tenant storage systemwith inter-server communication
US9201908B2 (en) * 2013-08-22 2015-12-01 Sap Portals Israel Ltd Multi-layered multi-tenancy database architecture
US10262151B2 (en) 2014-03-17 2019-04-16 Citrix Systems, Inc. User-agnostic backend storage for cloud-based applications
EP3518570B1 (en) 2014-03-19 2020-11-04 Bluefin Payment Systems, LLC Systems and methods for creating fingerprints of encryption devices
US8966464B1 (en) 2014-03-21 2015-02-24 Amazon Technologies, Inc. Isolating tenants executing in multi-tenant software containers
US10516667B1 (en) 2014-06-03 2019-12-24 Amazon Technologies, Inc. Hidden compartments
US9754116B1 (en) 2014-09-03 2017-09-05 Amazon Technologies, Inc. Web services in secure execution environments
US9146764B1 (en) 2014-09-30 2015-09-29 Amazon Technologies, Inc. Processing event messages for user requests to execute program code
US10048974B1 (en) 2014-09-30 2018-08-14 Amazon Technologies, Inc. Message-based computation request scheduling
US9323556B2 (en) 2014-09-30 2016-04-26 Amazon Technologies, Inc. Programmatic event detection and message generation for requests to execute program code
US9830193B1 (en) 2014-09-30 2017-11-28 Amazon Technologies, Inc. Automatic management of low latency computational capacity
US9600312B2 (en) 2014-09-30 2017-03-21 Amazon Technologies, Inc. Threading as a service
US9413774B1 (en) 2014-10-27 2016-08-09 Palo Alto Networks, Inc. Dynamic malware analysis of a URL using a browser executed in an instrumented virtual machine environment
US10599423B2 (en) 2014-11-20 2020-03-24 Red Hat, Inc. Source code management for a multi-tenant platform-as-a-service (PaaS) system
US10516733B2 (en) 2014-11-25 2019-12-24 Auth0, Inc. Multi-tenancy via code encapsulated in server requests
US10576733B2 (en) 2017-02-14 2020-03-03 M&R Printing Equipment, Inc. Tuneable flat panel UV exposure system for screen printing
US10445207B2 (en) 2017-07-31 2019-10-15 Oracle International Corporation System and method to execute and manage load tests using containers
US11977761B2 (en) 2020-02-21 2024-05-07 Salesforce, Inc. Predictive allocation of ephemeral containers for cloud computing services

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20230035701A1 (en) * 2014-11-25 2023-02-02 Okta, Inc. Multi-tenancy via code encapsulated in server requests
US11736568B2 (en) * 2014-11-25 2023-08-22 Auth0, Inc. Multi-tenancy via code encapsulated in server requests
US11968259B2 (en) 2014-11-25 2024-04-23 Auth0, Inc. Multi-tenancy via code encapsulated in server requests

Also Published As

Publication number Publication date
AU2015353500A1 (en) 2017-06-08
EP3210150B1 (en) 2021-04-07
US20220377140A1 (en) 2022-11-24
KR102372568B1 (ko) 2022-03-10
AU2015353500B2 (en) 2020-12-10
MX2017006842A (es) 2018-08-01
US20200092369A1 (en) 2020-03-19
US20230388379A1 (en) 2023-11-30
US20230035701A1 (en) 2023-02-02
AR102797A1 (es) 2017-03-22
AU2021201497A1 (en) 2021-03-25
DK3210150T3 (da) 2021-06-07
US11736568B2 (en) 2023-08-22
US11622003B2 (en) 2023-04-04
EP3210150A1 (en) 2017-08-30
AU2021201497B2 (en) 2022-08-18
US11582303B2 (en) 2023-02-14
US20230072584A1 (en) 2023-03-09
EP3210150A4 (en) 2018-07-04
WO2016086111A1 (en) 2016-06-02
JP2017539015A (ja) 2017-12-28
US11968259B2 (en) 2024-04-23
US10516733B2 (en) 2019-12-24
KR20170107431A (ko) 2017-09-25
JP6722184B2 (ja) 2020-07-15
US20160150053A1 (en) 2016-05-26
EP3863262A1 (en) 2021-08-11
CA2968858A1 (en) 2016-06-02

Similar Documents

Publication Publication Date Title
ES2877363T3 (es) Multitenencia a través de código encapsulado en solicitudes de servidor
US11461124B2 (en) Security protocols for low latency execution of program code
US11146569B1 (en) Escalation-resistant secure network services using request-scoped authentication information
US10203990B2 (en) On-demand network code execution with cross-account aliases
US10277708B2 (en) On-demand network code execution with cross-account aliases
US9471775B1 (en) Security protocols for low latency execution of program code
US9727725B2 (en) Security protocols for low latency execution of program code
US10044756B2 (en) Enabling an on-premises resource to be exposed to a public cloud application securely and seamlessly
US9426155B2 (en) Extending infrastructure security to services in a cloud computing environment
US10872145B2 (en) Secure processor-based control plane function virtualization in cloud systems