Machine Translated by Google Modelado empresarial y arquitecturas de sistemas de información vol. 14, núm. 1 (2019). DOI:10.18417/emisa.14.1 Impulsores y barreras para la adopción de microservicios: una encuesta entre profesionales en Alemania 1 Impulsores y barreras para la adopción de microservicios: una encuesta entre profesionales en Alemania Holger Knoche*,a, Wilhelm Hasselbringa a Grupo de Ingeniería de Software, Universidad de Kiel, 24118 Kiel, Alemania Resumen. Los microservicios son un estilo de arquitectura para software que actualmente recibe mucha atención tanto en la industria como en el mundo académico. Varias empresas emplean arquitecturas de microservicios con gran éxito y hay una gran cantidad de publicaciones en blogs que elogian sus ventajas. Especialmente los llamados sistemas a escala de Internet los utilizan para satisfacer sus enormes requisitos de escalabilidad y para ofrecer rápidamente nuevas funciones a sus usuarios. Pero los microservicios no solo son populares entre los grandes sistemas a escala de Internet. Muchas empresas tradicionales también están considerando si los microservicios son una opción viable para sus aplicaciones. Sin embargo, estas empresas pueden tener otras motivaciones para emplear microservicios y ver otras barreras que podrían impedirles adoptar microservicios. Además, estos impulsores y barreras posiblemente difieran entre los sectores de la industria. En este artículo, presentamos los resultados de una encuesta sobre impulsores y barreras para la adopción de microservicios entre profesionales en Alemania. Además de los impulsores y barreras generales, nos enfocamos particularmente en el uso de microservicios para modernizar el software existente, con especial énfasis en las implicaciones para el rendimiento y la transaccionalidad del tiempo de ejecución. Observamos diferencias interesantes entre los primeros usuarios que enfatizan la escalabilidad de sus sistemas a escala de Internet, en comparación con las empresas tradicionales que enfatizan la mantenibilidad de sus sistemas de TI. Palabras clave. Arquitectura de microservicios • Encuesta • Modernización de software • Adopción de microservicios Comunicado por S. Strecker. Recibido el 05-08-2017. Aceptado después de 3 revisiones el 28-11-2018. 1. Introducción A día de hoy, numerosas empresas de renombre, como Amazon2, Spotify3 y Uber4, utilizan microservicios. Con Los microservicios son un estilo arquitectónico que ha ganado mucha atención en los últimos años. El amplio interés en los microservicios comenzó alrededor de 2014 y ha ido en constante aumento desde entonces (Balalaie et al. 2016). Sin embargo, las implementaciones de este estilo arquitectónico existen desde hace mucho más tiempo, este estilo arquitectónico, estas empresas afirman haber logrado la escalabilidad necesaria para brindar sus servicios a millones de usuarios en todo el mundo. Además de la escalabilidad (Hasselbring 2016), los microservicios también pueden permitir tanto la agilidad como la confiabilidad (Hasselbring y Steinacker 2017). aunque el término en sí no se acuñó hasta 2012 (Lewis y Fowler 2014). Por ejemplo, uno de los primeros usuarios más conocidos, el proveedor de transmisión de video Lo que llama especialmente la atención sobre el desarrollo de microservicios es el hecho de que muchas Netflix, comenzó a introducir una arquitectura de microservicio en 2008 para aprovechar las ventajas de la empresas están haciendo que sus conocimientos y herramientas computación en la nube.1 2 Vea la charla de Chris Munns en I Love APIs 2015, * Autor correspondiente. diapositivas disponibles en https://www.slideshare.net/apigee/ilove-apis-2015-microservices-at-amazon-54487258 3 Vea la Correo electrónico. [email protected] charla de Kevin Goldsmith en GOTO 2015 , disponible en https:// kiel.de 1 Vea la charla de Ruslan Meshenberg en GOTO 2016, www.youtube.com/watch?v=7LGPeBgNFuU 4 Ver https:// eng.uber.com/soa disponible en https://www.youtube.com/watch?v=57UK46qfBLY Machine Translated by Google Revista internacional de modelado conceptual vol. 14, núm. 1 (2019). DOI:10.18417/emisa.14.1 Holger Knoche, 2 Wilhelm Hasselbring disponible públicamente. Por ejemplo, Netflix5 y Otto6 ya tienen activos de software existentes, investigamos publican blogs de tecnología, en los que se presentan más a fondo hasta qué punto los microservicios se ideas y experiencias actuales. Además, muchas bibliotecas perciben como una herramienta para la modernización del y componentes de infraestructura para desarrollar y software, qué objetivos se persiguen al introducir ejecutar microservicios a escala se publican de forma microservicios en el software existente y cómo se califica gratuita como software de código abierto. Ejemplos de el impacto potencial en el rendimiento del tiempo de dicho software incluyen la biblioteca Archaius para la ejecución y la transaccionalidad . gestión de la configuración,7 la puerta de enlace Zuul El resto de este trabajo se estructura de la siguiente edge,8 o la plataforma de instrumentación de contenedores manera. Insecto. 2, se presenta información básica sobre Kubernetes.9 Finalmente, los proveedores de la nube como Amazon Web Services permiten obtener relacionado se discute en la Secc. 3, y nuestro enfoque y los recursos informáticos requeridos rápidamente y con diseño de investigación se describen en la Secc. 4. Los microservicios y conceptos relacionados. El trabajo poco esfuerzo. Por lo tanto, el umbral de entrada para resultados y hallazgos se presentan en la Secc. 5. Las adoptar microservicios es bastante bajo. amenazas a la validez y las implicaciones de los resultados Como consecuencia, muchas empresas actualmente se discuten en la Secc. 6. Secta. 7 concluye el documento. están considerando si los microservicios son una opción viable para sus sistemas de software. Sin embargo, muchos de estos sistemas no son “a escala de Internet”; en cambio, son utilizados por un número conocido, limitado y estable de usuarios. Por lo tanto, estas empresas pueden considerar los microservicios por otros motivos además de los primeros en adoptarlos. Aún más interesantes son las barreras esperadas que pueden impedir que estas empresas adopten microservicios. Varios autores advierten contra la consideración de los microservicios como viables para todos los sistemas de software, ya que existen numerosas compensaciones a considerar (Killalea 2016; Singleton 2016). Además, las razones a favor y en contra de los microservicios pueden variar considerablemente entre diferentes industrias. Aunque la adopción de microservicios se analiza ampliamente en publicaciones de blogs y otros medios en línea , todavía hay pocos datos de investigación sobre el tema. Si bien existen algunos estudios sobre la adopción de microservicios en la práctica, muchos de ellos solo se han realizado con pocos participantes y aún quedan varias preguntas abiertas. Para comprender mejor las razones por las que las empresas "tradicionales" están considerando la adopción de microservicios, realizamos una encuesta entre profesionales del desarrollo de software en Alemania. Dado que muchas empresas 5 https://medium.com/netflix-techblog 6 https:// dev.otto.de 7 https://github.com/Netflix/archaius 2. Fondo 2.1 Propiedades de las arquitecturas de microservicios No existe una definición comúnmente aceptada de arquitecturas de microservicios. En cambio, generalmente se caracterizan por un conjunto de propiedades comunes,10 que Lewis y Fowler (2014) describen en detalle . Estas propiedades se resumen brevemente a continuación. Posteriormente, se presenta una definición de trabajo del término para el ámbito de nuestro estudio. Como sugiere el término "microservicio", los servicios son los componentes básicos y el principal medio de modularización en las arquitecturas de microservicios. Servicios se ejecutan en contextos de procesos separados y se pueden implementar, reemplazar y retirar individualmente. Cada microservicio se centra en proporcionar una única función empresarial, siguiendo el principio de responsabilidad única (SRP). Los servicios están construidos en torno a las capacidades comerciales por equipos multifuncionales, que son responsables de todos los aspectos del servicio, desde el desarrollo hasta la operación productiva. Además, los equipos conservan esta responsabilidad durante toda la vida útil del servicio, a diferencia de los proyectos tradicionales, en los que la responsabilidad suele transferirse a otro equipo después de la finalización del proyecto. Esta diferencia se suele resumir como “productos, no proyectos”. 8 https://github.com/Netflix/zuul 9 http:// kubernetes.io/ 10 Como se mencionó en la charla de Martin Fowler en GOTO 2014, disponible en https://www.youtube.com/watch?v=wgdBVIX9ifA Machine Translated by Google Modelado empresarial y arquitecturas de sistemas de información vol. 14, núm. 1 (2019). DOI:10.18417/emisa.14.1 Impulsores y barreras para la adopción de 3 microservicios: una encuesta entre profesionales en Alemania A su vez, a los equipos se les otorga un alto grado de autonomía. En particular, la gobernanza centralizada y la gestión están disponibles en bibliotecas como Hystrix.12 Ejemplos de tales patrones son circuit breaker13 y bulkhead14 , que se utilizan comúnmente para aliviar los de datos se abandonan en la medida de lo posible y factible. Esto permite que el equipo elija las herramientas adecuadas efectos de las dependencias no disponibles o lentas. para el trabajo, como, por ejemplo, lenguajes de programación Otra ventaja importante de esta resiliencia es que permite o bases de datos apropiados. Además, las decisiones se pueden implementar los servicios en un orden arbitrario. cambiar o revertir sin afectar a otros equipos. Un alto grado de Para garantizar que sus microservicios sean lo suficientemente automatización de la implementación y la infraestructura permite a los equipos implementar nuevas versiones de sus servicios resistentes, algunas empresas incluso introducen deliberadamente según su propia decisión. fallas en sus entornos productivos, una disciplina a la que a veces se hace referencia como " ingeniería del caos".15 Por Esta autonomía del equipo, sin embargo, solo es posible debido a un estricto aislamiento técnico y un acoplamiento flexible. Cada microservicio es técnicamente autónomo, lo que significa ejemplo, Simian Army16 de Netflix consta de una serie de herramientas para causar diferentes tipos de errores. La más conocida de ellas es la que su unidad de implementación contiene todo lo necesario herramienta Chaos Monkey, que termina aleatoriamente las para ejecutar el servicio, a menudo incluso el sistema operativo. máquinas virtuales y los contenedores de aplicaciones . A diferencia de los llamados sistemas autocontenidos,11 los Las implementaciones de microservicios son esencialmente microservicios no necesitan ser funcionalmente autocontenidos, es decir, pueden invocar a otros microservicios para proporcionar sin estado, con la excepción de cachés de tiempo corto para su función empresarial. La comunicación entre servicios necesaria mejorar el rendimiento y la resiliencia. Junto con el orden de se produce únicamente mediante interfaces definidas basadas implementación arbitrario, esto permite que las infraestructuras en tecnologías y formatos de datos independientes de la de implementación automatizadas (consulte la Sección 2.3) plataforma . Las implementaciones de microservicios suelen inicien, detengan y muevan instancias de servicio con pocas depender de tecnologías de comunicación ligeras, principalmente tecnologías web como HTTP/REST o soluciones de mensajería como Kafka o Rab bitMQ. Por lo general, se desaconsejan las soluciones ricas en funciones, como los buses de servicios empresariales, ya que pueden tentar a trasladar la lógica comercial de los servicios a la infraestructura de comunicación. En cambio, los microservicios abogan por mantener la lógica comercial completamente dentro de los servicios ("puntos finales restricciones. Bases de datos y Los cachés distribuidos, a veces denominados " servicios completos de estado", generalmente se separan en contenedores dedicados. A menudo, especialmente las bases de datos se operan incluso de forma tradicional. Para resumir, usamos la siguiente definición para el término "microservicio" para el resto de este papel. inteligentes y conductos tontos"). Definición 1 (Microservicio) Un microservicio es un componente de software técnicamente autónomo e independiente que se ejecuta en su propio contexto de proceso y tiene sus propios Al ser una arquitectura altamente distribuida, los medios de persistencia. Está desarrollado y dirigido por un microservicios son particularmente susceptibles a fallas parciales. Por lo tanto, los microservicios deben diseñarse para hacer equipo multifuncional y autónomo responsable de su frente con gracia a la falta de disponibilidad de los servicios necesarios para evitar fallas en cascada, una propiedad comúnmente conocida como resiliencia. Han surgido varios patrones para este propósito (Nygard 2007), y las implementaciones bien probadas 12 https://github.com/Netflix/Hystrix 13 https://docs.microsoft.com/en-us/azure/architecture/paÿ golondrinas/disyuntor 14 https://docs.microsoft.com/en-us/azure/architecture/paÿ golondrinas/mamparo 15 11 http://scs-architecture.org http://principlesofchaos.org/ 16 https://github.com/Netflix/SimianArmy Machine Translated by Google Revista internacional de modelado conceptual vol. 14, núm. 1 (2019). DOI:10.18417/emisa.14.1 Holger Knoche, 4 Wilhelm Hasselbring ciclo de vida completo. Un microservicio proporciona una Este mecanismo de virtualización liviano permite el función comercial única, que se expone mediante interfaces aprovisionamiento de una nueva instancia de servicio en independientes de la plataforma. segundos, mientras que la configuración de una máquina virtual tradicional generalmente toma varios minutos. Por lo 2.2 Microservicios, DevOps y entrega continua Es obvio que las propiedades descritas anteriormente no tanto, la virtualización basada en contenedores se ha convertido en una herramienta importante para lograr una alta elasticidad. Para aprovechar al máximo esta elasticidad, han surgido pueden ser provistas únicamente por medios tecnológicos, herramientas de administración de clústeres automatizadas. como una arquitectura de software particular. Ejemplos bien conocidos de este tipo de herramientas son El requisito de equipos autónomos y multifuncionales capaces de implementar sus servicios de forma rápida y automática a su propia discreción muestra que Los microservicios están estrechamente relacionados con las nociones de DevOps (Hüttermann 2012) y Continuous Delivery (Humble y Farley 2011). Sin embargo, existen diferentes opiniones sobre la precisión con la que se relacionan estas nociones. Fowler (2014) ve la cultura DevOps como un requisito previo para la adopción de microservicios, mientras que Wolff (2016) argumenta que los microservicios no requieren la adopción de DevOps. Bajo et al. considere la entrega continua como una práctica de DevOps y observe que muchas empresas que ya han adoptado la entrega continua ahora se están moviendo hacia una arquitectura de microservicio (Bass et al. 2015, p. 66). Balalaie et al. (2016), por otro lado, ven a los microservicios como un habilitador para DevOps. Estamos más de acuerdo con la última opinión, ya que, según nuestra experiencia, los cambios organizacionales necesarios para DevOps son casi imposibles de implementar sin pruebas concretas de los beneficios tecnológicos para la organización en particular. Por lo tanto, también consideramos las implicaciones organizativas de los microservicios en nuestra encuesta, como el papel de los microservicios como facilitador de DevOps o el cambio de tareas para los equipos de desarrollo y operaciones. 2.3 Infraestructura de implementación para microservicios Kuber netes,18 Docker Swarm y DC/OS.19 Estas herramientas brindan características tales como escalado automático, detección de servicios y redespliegue en caso de falla del nodo y, por lo tanto, facilitan en gran medida la operación de microservicios. aplicaciones basadas Pero como se mencionó antes, dicha administración automatizada generalmente requiere que los microservicios se puedan implementar en un orden arbitrario. 2.4 Implicaciones de coherencia de los microservicios Como se señaló anteriormente, la autonomía otorgada a los equipos de microservicios incluye la elección del bases de datos subyacentes. Si bien este enfoque de persistencia políglota permite aprovechar las fortalezas de los diferentes tipos de bases de datos, como las bases de datos relacionales o de gráficos, también tiene algunas desventajas importantes, especialmente con respecto a la consistencia. Una desventaja importante es que las actualizaciones consistentes a través de los límites del servicio son muy difíciles de lograr. En las bases de datos centralizadas tradicionales, dichas actualizaciones se implementan mediante transacciones de bases de datos, que garantizan las conocidas propiedades ACID (Atomicidad, Consistencia, Aislamiento y Durabilidad) . Desafortunadamente, estas propiedades son notoriamente difíciles de mantener para la persistencia distribuida, donde varias bases de datos diferentes pueden verse afectadas por una sola transacción. Dichos casos generalmente se manejan utilizando un protocolo de compromiso de dos La popularidad de la arquitectura de microservicios también ha dado lugar a algunos desarrollos tecnológicos importantes en el campo de la implementación y las operaciones. Uno de estos desarrollos es el surgimiento de la virtualización basada en contenedores, a menudo utilizada como sinónimo fases (2PC), donde los participantes primero votan si la transacción se puede comprometer antes, siempre que no haya objeciones, de proceder al compromiso real. Debido a la gran cantidad de coordinación y sincronización requerida para este de su implementación más conocida, Docker.17 17 https://www.docker.com/ 18 http://kubernetes.io/ 19 https://dcos.io/ Machine Translated by Google Modelado empresarial y arquitecturas de sistemas de información vol. 14, núm. 1 (2019). DOI:10.18417/emisa.14.1 Impulsores y barreras para la 5 adopción de microservicios: una encuesta entre profesionales en Alemania protocolo, las confirmaciones de dos fases pueden limitar severamente para modernizar las aplicaciones de software monolíticas la escalabilidad. existentes . Además, hay informes de experiencia de varias No todas las bases de datos proporcionan transacciones, sin mencionar la capacidad de participar en transacciones empresas que han reemplazado con éxito (partes de) su software existente por microservicios, o están en proceso de hacerlo. distribuidas. Especialmente muchas de las llamadas bases de datos NoSQL tienen poco o ningún soporte de transacciones a Aunque algunas empresas, por ejemplo, el minorista en línea cambio de una alta escalabilidad. Dado que no se puede alemán Otto, lograron una reescritura completa de su aplicación garantizar una consistencia sólida , los sistemas que utilizan tales bases de datos a menudo se construyen para proporcionar una consistencia eventual , lo que significa que si no se producen más actualizaciones de un elemento de datos, todas las lecturas de este elemento finalmente devolverán el valor de la última (Hasselbring y Steinacker 2017), la mayoría de los autores recomiendan utilizar un enfoque incremental (Knoche y Has selbring 2018); algunos autores incluso consideran una mala práctica un enfoque no incremental (Car rasco et al. 2018). Para proporcionar un ejemplo concreto, Stine (2015) propone un actualización (Vogels). 2009). Como consecuencia, se prefiere la coordinación sin enfoque que comprende tres fases principales: transacciones entre servicios para los microservicios (Lewis y Fowler 2014). En estos entornos, se emplean estrategias como la compensación explícita o el enfoque Try-Cancel Confirm 1. Las nuevas características se implementan solo como (TCC) (Pardon y Pautasso 2014) para abordar la coherencia de microservicios . No se agregan nuevas características al mono los datos. lit. Con una compensación explícita, los cambios se realizan de manera optimista y se revierten explícitamente mediante una operación de compensación si es necesario (p. ej., se elimina un cliente creado anteriormente). TCC hace uso de entidades que representan explícitamente bloqueos temporales (por ejemplo, una reserva de vuelo válida por 5 minutos) que debe confirmarse en caso de éxito (por ejemplo, la reserva se convierte en una reserva). Otro inconveniente es que puede resultar muy difícil crear 2. Se crea una capa de interfaz que permite que los microservicios recién creados accedan a la funcionalidad del monolito. Esta capa de interfaz sirve como capa anticorrupción (ver Evans 2007) para separar claramente los modelos de dominio antiguo y nuevo. 3. La funcionalidad se elimina gradualmente del monolito y se vuelve a implementar como microservicios. Stine sugiere comenzar con los servicios con mayor copias de seguridad coherentes de los diferentes almacenes de necesidad de cambio. Este proceso continúa hasta que el datos. Esto puede tener un impacto significativo en las estrategias monolito se reemplaza por completo o solo contiene una de recuperación ante desastres, ya que el sistema no se puede funcionalidad estable que no justifica el esfuerzo de revertir a un estado consistente simplemente restaurando las extracción. copias de seguridad. Por lo tanto, se deben tomar las medidas adecuadas para garantizar la seguridad de los datos Una mirada más cercana a este enfoque revela varios desafíos almacenados. Técnicamente, la replicación puede disminuir el importantes y destaca que tal modernización está lejos de ser riesgo de pérdida de datos debido a fallas, lo que reduce la trivial. En particular, el propio monolito comienza a depender probabilidad de tener que restaurar copias de seguridad. de los nuevos microservicios con la tercera fase. Esto puede Conceptualmente, la versión temporal de los datos permite tener consecuencias importantes: reconstruir estados consistentes al menos hasta un punto específico en el tiempo. 2.5 Microservicios como medio para la modernización del software • La capa anticorrupción ahora se usa bidirec cionalmente. • Las llamadas anteriormente nativas dentro del monolito pueden Un aspecto particularmente interesante de los microservicios es tener que ser reemplazadas por llamadas de servicio y pueden que varios autores, como Newman (2015) y Wolff (2016), los volverse significativamente más lentas debido a la sobrecarga consideran como un medio viable de invocación. Machine Translated by Google Revista internacional de modelado conceptual vol. 14, núm. 1 (2019). DOI:10.18417/emisa.14.1 Holger Knoche, Wilhelm 6 Hasselbring • Los accesos a la base de datos dentro del monolito pueden tener que ser reestructurados o reemplazados por llamadas de servicio. • El monolito ahora también debe ser capaz de hacer frente a las dependencias no disponibles. Además, las restricciones discutidas anteriormente sobre la transaccionalidad y la coherencia ahora también se aplican al monolito en sí mismo, ya que, por ejemplo, ya no puede asumir diferencias en cuanto a la metodologa. Mientras que Taibi et al. eligió un enfoque más cualitativo con pocos participantes, nuestro estudio utiliza un enfoque cuantitativo con un número significativamente mayor de participantes. Ghofrani y Lübke (2018) realizaron una encuesta con 25 participantes profesionales sobre los desafíos en el diseño de microservicios y sugerencias sobre cómo resolverlos. Si bien que todos sus cambios están contenidos dentro de las este estudio aborda los impulsores y los desafíos para la transacciones ACID. Estas restricciones pueden representar un adopción de microservicios, los resultados solo se analizan muy desafío importante para las modernizaciones de los microservicios brevemente y, especialmente, los desafíos se basan solo en y, por lo tanto, también se investigan en nuestra encuesta. unas pocas respuestas. Di Francesco et al. (2018) informan sobre una 3 Trabajo relacionado encuesta con 18 participantes profesionales sobre las actividades y los desafíos al migrar una pieza de Siendo una disciplina que ha recibido atención académica recientemente , todavía hay poca investigación empírica que apunte particularmente a los microservicios. Pahl y Jamshidi ( 2016 ), Alshuqayran et al. (2016) y Di Francesco et al. (2017). Los últimos dos estudios también enumeran los desafíos y problemas de implementación a los que se dirigen los microservicios software existente a microservicios utilizando una variante adaptada del modelo de herradura (Razavian y Lago 2010). Aunque este estudio también aborda la modernización mediante microservicios, vemos algunas diferencias importantes en nuestro estudio. Mientras que Di Francesco et al. investigamos acciones y problemas concretos mientras aplicamos una estrategia que se abordan comúnmente en la literatura. Sin de modernización dada, nos enfocamos en identificar embargo, estos desafíos y problemas no se discuten las razones que llevan a la decisión de modernizar. No en detalle. Además, pueden no ser representativos de se aborda el tema de los cambios en la transaccionalidad la situación real en la práctica, como Di Francesco et y la consistencia de los datos, que investigamos en nuestro estudio. al. encuentran que la mayoría de las publicaciones fueron escritas solo por autores de la academia. Además de estos estudios académicos, también hay encuestas industriales parcialmente relacionadas con los microservicios. Las encuestas realizadas por NGINX (2016) y Lightbend, Inc. (2016) informan sobre el uso de Scherman et al. (2016) realizaron una encuesta con 42 microservicios en producción. El último estudio también participantes profesionales sobre el estado actual de la investiga brevemente los impulsores y las barreras para la práctica en aplicaciones basadas en servicios. adopción de microservicios, pero solo con muy poco detalle. Sin embargo, este estudio se centró principalmente en los detalles de implementación, como los protocolos y formatos Para resumir, si bien ya hay algunas investigaciones de datos utilizados, las métricas de seguimiento recopiladas empíricas sobre la adopción de microservicios en la y los lenguajes de programación preferidos. No se abordan práctica, todavía vemos muchas oportunidades y la las motivaciones y barreras para la adopción de microservicios . necesidad de seguir investigando en esta área. Muchos de Taibi et al. (2017) informan sobre un estudio basado en los estudios existentes se han realizado con muy pocos participantes y, por lo tanto, deben complementarse con entrevistas con 21 participantes profesionales sobre estudios adicionales para verificar los hallazgos (consulte motivaciones, problemas y procesos para adoptar la Sección 6.2). Además, aún no se han investigado las microservicios. Aunque este estudio tiene cierta implicaciones para la transaccionalidad y la consistencia, superposición con el nuestro, no aborda el aspecto de la que difieren significativamente entre los monolitos migración del software existente hacia una arquitectura de tradicionales y los microservicios (consulte la Sección 2.4) . microservicio. Además, hay fundamentos Machine Translated by Google Modelado empresarial y arquitecturas de sistemas de información vol. 14, núm. 1 (2019). DOI:10.18417/emisa.14.1 Impulsores y barreras para la adopción de 7 microservicios: una encuesta entre profesionales en Alemania 4 Diseño y método de investigación Los cuestionarios comprendían un total de 19 preguntas (ver Apéndice A), y fueron diseñados para tomar de 10 a 15 minutos 4.1 Preguntas de investigación En en completarse. Las preguntas fueron seleccionadas por uno este estudio, nuestro objetivo es investigar los impulsores y las de los autores del estudio en base a los hallazgos en la barreras para los microservicios en general, así como los objetivos literatura, la experiencia de discusiones con profesionales y su para usar los microservicios como medio de modernización del propia experiencia profesional en la modernización de software. software. Esto dio como resultado la selección de las siguientes preguntas de investigación: RQ1: ¿Cuáles son los principales impulsores para que las empresas adopten microservicios? Luego, el cuestionario fue revisado por otro investigador y un desarrollador de software profesional, ambos ya preocupados por los microservicios. Después de la revisión, dos desarrolladores de software profesionales probaron el cuestionario en cuanto a RQ2: ¿ Cuáles son las principales barreras que impiden que las usabilidad y comprensión. empresas adopten microservicios? RQ3: ¿ Cuáles son los objetivos importantes del uso de microservicios para modernizar los conjuntos de software 4.3 Observaciones metodológicas existentes y difieren de los impulsores generales para la Varias preguntas de nuestro cuestionario pedían a los adopción? encuestados que clasificaran la importancia de diferentes RQ4: ¿Cómo se califica el impacto potencial en el rendimiento del tiempo de ejecución y la transaccionalidad/consistencia de los datos en los entornos de modernización? aspectos para decisiones particulares. Dado que esperábamos que algunos aspectos fueran decisivos, es decir, considerados tan importantes que por sí solos pudieran conducir a una decisión, utilizamos una escala de 4.2 Método de investigación Para responder a las preguntas de investigación presentadas, realizamos una encuesta entre profesionales de Alemania. Para calificación de cuatro puntos capaz de capturar respuestas tan extremas. Elegimos usar cuatro puntos ya que esto permitía etiquetas claramente separadas, fáciles de entender y, al ser un número par, evitaba las tendencias centrales. aumentar la relevancia de las respuestas, decidimos dirigirnos principalmente a profesionales que ya estaban preocupados por los microservicios. Por lo tanto, visitamos reuniones y conferencias de la industria relacionadas con los microservicios para adquirir encuestados personalmente y contactamos a los oradores de dichas conferencias por correo y redes sociales profesionales. También publicitamos nuestra encuesta en un conocido sitio alemán de noticias para desarrolladores, heise developer.20 Además, se pidió a los encuestados que enviaran la encuesta a otros profesionales relacionados con los microservicios. Un intento de adquirir encuestados de grupos temáticos de microservicios en la red social profesional XING no tuvo éxito debido a las tasas de respuesta muy bajas. Para comparar la importancia de los ítems, calculamos una puntuación como la media ponderada de las respuestas de cada ítem, así como la desviación estándar de la puntuación. Por lo tanto, interpretamos implícitamente estos elementos ordinales como escalados por intervalos. Somos conscientes de que esta interpretación de tales ítems está en disputa y, desde un punto de vista estadístico, no es del todo sólida (ver Knapp 1990). Como señala Stevens (1946), esto se debe principalmente a que los intervalos entre las opciones son de tamaño desigual. Esto es particularmente cierto para nuestra escala debido a las opciones extremas que, como consecuencia, están infraponderadas en las puntuaciones. Por lo tanto, usamos las puntuaciones y las desviaciones estándar solo para un orden aproximado de los aspectos, así como para indicar Para la encuesta, utilizamos cuestionarios en papel y en la web. El cuestionario en papel se utilizó en las reuniones en las que pudimos reclutar personalmente a los encuestados, mientras que el cuestionario web se utilizó para el contacto a través de medios electrónicos. el grado en que las respuestas difieren para un ítem determinado. Para comprobar las hipótesis relativas a los ítems, empleamos pruebas estadísticas apropiadas para datos ordinales (pruebas de signos y pruebas de suma de rangos de 20 https://www.heise.de/developer/ Wilcoxon). Con el fin de mantener la coherencia del texto, informamos sólo los Machine Translated by Google Revista internacional de modelado conceptual vol. 14, núm. 1 (2019). DOI:10.18417/emisa.14.1 Holger Knoche, 8 Wilhelm Hasselbring Tabla 3: Encuestados y departamentos valores de p en el texto; los detalles sobre las pruebas (hipótesis y estadísticas de prueba) se pueden encontrar en el Apéndice # de B. Se proporciona una etiqueta de prueba (p. ej., T1) para cada Departamento valor de p para facilitar la navegación en el apéndice. Además, algunos números en los gráficos de barras % de encuestados encuestados Desarrollo 68 96% Operaciones 15 21% apiladas tuvieron que ajustarse en un punto porcentual para tener en cuenta el redondeo, ya que los gráficos requerían que Las respuestas se agruparon manualmente en las los porcentajes sumaran exactamente el 100 %. siguientes categorías de la industria: 5 Resultados y Hallazgos • Desarrollo y Consultoría de Software: Encuestados de 5.1 Información demográfica En total, 71 empresas cuyo producto principal es el software. Dado que encuestados participaron en nuestra encuesta. Como se muchas de estas empresas también realizan consultoría muestra en la Tab. 1, aproximadamente la mitad de los relacionada con el software, esta industria también se encuestados se preocuparon por los microservicios durante agregó a esta categoría. menos de un año, un tercio durante uno o dos años y una • Energía y Manufactura: Esta categoría representa empresas quinta parte durante más de dos años. El resto de los de ramas tradicionales de la industria, como fabricantes de encuestados no proporcionó respuestas o las respondió de forma inválida. automóviles y proveedores de energía. Tabla 1: Tiempo relacionado con microservicios • Servicios Financieros: En esta categoría se agrupan los # de Experiencia % de encuestados encuestados de bancos y compañías de seguros . encuestados 24% Hasta 6 meses 6 meses a 12 meses 12 a 24 17 14 20% meses 20 28% Más de 24 meses 12 17% 8 11% Inválido / sin respuesta • Venta al por menor y comercio electrónico: encuestados de empresas de venta al por menor en línea y otras empresas de comercio electrónico . • Otra o ninguna respuesta: encuestados que trabajan en En cuanto a los puestos y departamentos, el 70 % de los encuestados afirmó trabajar como arquitecto, el 13 % como otras industrias y encuestados que no respondieron esta pregunta. consultor, el 56 % como desarrollador y el 15 % como líder de equipo . La gran mayoría de los encuestados, casi el 96%, El agrupamiento se hizo para evitar grupos pequeños trabajaba en departamentos de desarrollo, el 21% trabajaba en con pocos participantes. La categoría “Retailing / E- departamentos de operaciones. Los números detallados se Commerce” se estableció a pesar de tener muy muestran en la Tab. 2 y Tab. 3. El pocos participantes, ya que especialmente el a los encuestados se les permitió dar múltiples respuestas a comercio minorista en línea es una de las industrias ambas preguntas. pioneras de microservicios. Estas categorías y las cifras respectivas se muestran en la Tab. 4. Tabla 2: Encuestados y roles laborales Tabla 4: Encuestados e industrias Role # de % de encuestados Arquitecto Consultor Desarrollador Jefe de equipo encuestados 50 # de 70% 9 13% 40 56% 11 15% nombrar la industria en la que trabajan. encuestados 23% Desarrollo / Consultoría 16 Energía / Manufactura Servicios financieros 11 15% 20 28% Venta minorista / comercio electrónico Se pidió además a los encuestados que % de encuestados Otro / Sin respuesta 6 8% 18 25% Machine Translated by Google Modelado empresarial y arquitecturas de sistemas de información vol. 14, núm. 1 (2019). DOI:10.18417/emisa.14.1 Impulsores y barreras para la adopción de microservicios: una encuesta entre profesionales en Alemania 5.2 Uso actual de microservicios Al 9 por lo tanto, esperamos que las empresas consideren los microservicios como una herramienta para su esfuerzo por comienzo de nuestro cuestionario, nos la nube. Debido a la fuerte separación de componentes , se preocupaba el alcance actual del uso de espera que los microservicios sean menos propensos que microservicios en las respectivas empresas e industrias. Como es evidente en la figura 1, casi un tercio (27 %) los monolitos tradicionales a desarrollar dependencias de todos los encuestados afirmaron que ellos o sus entrelazadas, mejorando así la capacidad de mantenimiento clientes ya utilizan microservicios en gran medida.21 El (ver Newman 2015). Esto es particularmente importante resto de los encuestados afirmaron usar microservicios para las aplicaciones empresariales, que suelen estar en en menor medida, o no usar microservicios en absoluto, uso durante varios años y, por lo tanto, pueden ser un en partes iguales (37%). impulsor importante para la adopción de microservicios. Además, nos interesaba saber si la libre Una mirada a las cifras específicas de la industria revela la elección del lenguaje de programación y la persistencia que el grado de uso difiere considerablemente entre las industrias. Si bien los microservicios parecen (ver Lewis y Fowler 2014), a menudo denominada Si son muy utilizados por la industria minorista y de comercio programación políglota y persistencia políglota, en realidad electrónico (mediana: uso en gran medida), solo se usan se consideran un impulsor para la adopción de microservicios, con moderación en la industria de servicios financieros ya que también tienen varias desventajas, como se analiza más adelante. (mediana: sin uso). Al ponderar las respuestas de ÿ1 (ningún uso) a 1 (uso en gran medida), estas diferencias son estadísticamente significativas (T1: p = 0,002 y T2: p = 0,010, respectivamente). Como se describe en la Secc. 2.2, los microservicios también están estrechamente relacionados con las nociones más organizativas de DevOps y Entrega continua. Las empresas pueden adoptar microservicios para que sirvan como habilitadores de DevOps y 5.3 Impulsores para la adopción de microservicios Continuous Delivery (ver Chen 2018). En particular, Para identificar impulsores importantes para la adopción estos enfoques prometen un “tiempo de comercialización” de microservicios, les pedimos a los encuestados que corto para las nuevas funciones, lo que puede ser calificaran nueve propiedades comúnmente atribuidas a crucial para las empresas que enfrentan una los microservicios con respecto a su importancia en la competencia intensa (Chen 2015). Otra ventaja decisión de adoptar microservicios. Estos posibles organizativa atribuida a los microservicios es una mejor impulsores se analizan a continuación; las propiedades alineación de los equipos de desarrollo y los artefactos reales están resaltadas en cursiva. de software (ver Newman 2015; Wolff 2016), denominada mejora organiza Una de las propiedades más citadas de los microservicios es la alta escalabilidad y elasticidad (ver, por ejemplo, Dado que se sabe que la desalineación organizacional es perjudicial para la calidad (Nagappan et al. 2008), se espera Hasselbring y Steinacker 2017) debido a que los servicios que mejorar esta alineación provoque un aumento en la se implementan de forma independiente. Por lo tanto, las calidad. Finalmente, al ser una arquitectura de vanguardia , instancias se pueden agregar y eliminar automáticamente las empresas podrían adoptar microservicios para aumentar mediante herramientas de administración de clústeres como su atractivo como empleador. Kubernetes. Una propiedad muy relacionada con la escalabilidad es que los microservicios se consideran una La calificación de estos conductores se realizó utilizando arquitectura nativa de la nube, es decir, permiten aprovechar nuestra escala de calificación de cuatro puntos, con etiquetas las ventajas de la nube y la virtualización basada en cruciales, relevantes, poco relevantes e irrelevantes. Se contenedores. Como se señaló en la introducción, el pidió a los encuestados que eligieran la opción crucial para conocido adoptador Netflix introdujo microservicios por esta los lazos de propiedades que, en su opinión, serían misma razón, y suficientes por sí solos para adoptar microservicios. Pestaña. 5 resume las respuestas de las diferentes 21 Nótese que los clientes se incluyeron para dar cuenta de los consultores que podrían estar solo interesados en microservicios industrias, ordenadas por el puntaje general. La puntuación en proyectos de clientes. se calcula como el promedio ponderado de Machine Translated by Google Revista internacional de modelado conceptual vol. 14, núm. 1 (2019). DOI:10.18417/emisa.14.1 Holger Knoche, 10 Wilhelm Hasselbring General 27% 44% 25% Desarrollo / Consultoría 18% Energía / Manufactura Servicios financieros 31% 27% 55% 10% 35% 55% 17% 83% Comercio minorista / comercio electrónico Otro / Desconocido 0% 37% 36% 33% 10% 28% 20% 30% 40% 50% 60% 70% 39% 80% 90% 100% Gran extensión Menor extensión Sin uso Figura 1: Uso actual de microservicios en diferentes industrias (% de encuestados) las respuestas, con pesos que van desde 3 (crucial) a 0 de adopción en esta industria. Sin embargo, no hay una (irrelevante). diferencia significativa con respecto a esta pregunta entre los Como se desprende de la tabla, se encontró que los "usuarios intensivos" y otros en todas las industrias ( T13). principales impulsores generales para la adopción de microservicios eran la escalabilidad, la capacidad de Algunos conductores también tienen una calificación mantenimiento y el tiempo de comercialización, cada uno notablemente baja en ciertas industrias. Particularmente de los cuales fue calificado como crucial por sorprendentes son el tiempo de comercialización y la idoneidad aproximadamente un tercio de los encuestados. La para la virtualización en la industria energética y manufacturera, diferencia entre los impulsores primario y secundario es que tienen una calificación considerablemente más baja que estadísticamente significativa (T3: p < 0,001). Los factores en otras industrias (T10: p = 0,023 y T9: p = 0,012, respectivamente). secundarios son el papel potencial como facilitador de la La correlación cruzada de los ítems utilizando el coeficiente entrega continua y DevOps, la idoneidad para los entornos de correlación de rangos de Spearman reveló algunas de nube y la virtualización basada en contenedores, y la correlaciones notables, pero de medias a bajas. El más alto mejora organizativa. La persistencia políglota y la fue entre la programación políglota y la persistencia (rs = 0,47, programación políglota se califican como un poco menos p < 0,001), que encontramos sorprendentemente bajo ya que relevantes. El efecto potencial de aumentar el atractivo ambas nociones parecen estar estrechamente relacionadas. como empleador se percibe como menos importante; la Todos los resultados de correlación cruzada se muestran en la Tab. 10 en el Apéndice. Sin embargo, las cifras de Tab. 5 sugieren brecha con los impulsores secundarios es significativa (T4: p = 0,004). Las cifras específicas de la industria de Tab. 5 que estos dos artículos pueden percibirse de manera muestran que para las empresas de desarrollo y diferente en diferentes industrias. Mientras que la consultoría, la idoneidad de las plataformas de programación políglota se clasifica significativamente virtualización se califica significativamente más alta que más alto que la persistencia políglota en la industria de la en las otras industrias (T5: p = 0,014). Estas empresas energía y la manufactura (T11: p = 0,029), la persistencia también parecen percibir la mantenibilidad como el políglota se califica de manera notable, pero no impulsor clave de los microservicios; sin embargo, la significativamente más alta, en la industria de servicios diferencia con los otros impulsores primarios no es financieros, así como en las demás industrias (T14). significativa (T12). La programación políglota tiene una calificación considerablemente más alta en las industrias 5.4 Barreras para la adopción de microservicios de energía y manufactura (T6: p = 0.012) y comercio Con el fin de identificar las barreras importantes para la electrónico (T7: p = 0.027). Este último también valora el adopción de microservicios, se procedió de la misma manera atractivo como empleador muy por encima del resto (T8: que con los controladores. Sin embargo, las barreras a la adopción son mucho menos discutidas en la literatura. Por lo tanto, tuvimos p = 0,018), lo que resulta especialmente interesante por el alto grado Machine Translated by Google Modelado empresarial y arquitecturas de sistemas de información vol. 14, núm. 1 (2019). DOI:10.18417/emisa.14.1 Impulsores y 11 barreras para la adopción de microservicios: una encuesta entre profesionales en Alemania Tabla 5: Impulsores para la adopción de microservicios en diferentes industrias Desarrollo / General Consultante Energía / Financiero Industria Servicios Venta minorista / comercio electrónico Otro / Desconocido Dakota del Sur Puntuación (media) Puntuación (media) Puntuación (media) Puntuación (media) Puntuación (media) Puntuación (media) Alta escalabilidad y elasticidad 2,14 0,72 2,19 2,18 2,15 2,67 Alta mantenibilidad 2,11 0,75 2,31 2,10 2,15 2,17 1,89 Corto tiempo de comercialización 2,07 0,82 2,12 1,45 2,10 2,67 2,17 Habilitador para CD y DevOps Idoneidad para Cloud y Docker 1,61 0,89 1,69 1,27 1,70 1,83 1,56 1,55 0,89 2,00 1,09 1,35 1,50 1,67 Mejora Organizacional 1,37 0,81 1,31 1,18 1,50 1,83 1,22 Programación políglota 1,28 0,90 1,00 1,82 1,15 2,00 1,11 Persistencia políglota 1,27 0,83 1,06 1,09 1,40 1,33 1,39 Atractivo como empleador 0,87 0,86 1,00 0,55 0,85 1,67 0,72 1,89 confiar más en la experiencia personal de un proyecto bases de datos – son difíciles de lograr. Nociones como industrial y discusiones con los practicantes en cuanto a los la programación políglota y la persistencia requieren conductores. Dado que los elementos contienen barreras que los desarrolladores dominen múltiples lenguajes de abstractas, como la resistencia al cambio, así como desafíos programación y soluciones de persistencia. Y debido a para implementar medidas concretas, decidimos separarlos su naturaleza altamente distribuida, los microservicios en dos preguntas separadas . Los elementos que les pedimos generan implementaciones más complejas que los a los encuestados que calificaran se analizan a continuación. monolitos tradicionales (ver Wolff 2016), es decir, una Una vez más, los elementos en sí están resaltados en cursiva. mayor cantidad de instancias en ejecución, así como implementaciones más frecuentes e interacciones más complejas. Según nuestra experiencia, las resistencias tanto del personal de operaciones como de los desarrolladores pueden Otro problema con los equipos que eligen sus herramientas de forma autónoma es que las empresas deben garantizar ser una gran barrera para la adopción de microservicios, ya suficientes contratos de licencia y soporte. Para las que los microservicios son, en cierto modo, muy diferentes a arquitecturas de microservicios, los componentes de software lo que los desarrolladores y operadores están acostumbrados. que tienen licencia por instancia en ejecución, como algunas Por ejemplo, observamos que el concepto de consistencia soluciones comerciales de monitoreo, pueden ser eventual es difícil de aceptar para desarrolladores que han particularmente costosos. Las implicaciones organizacionales estado trabajando con consistencia estricta durante muchos de la adopción de microservicios pueden ser además años. Además, especialmente el personal de operaciones a incompatibles con el cumplimiento y las regulaciones. menudo es escéptico sobre la madurez de las nuevas Por ejemplo, es posible que se requiera que las empresas tecnologías, así como sobre la compatibilidad con los sistemas anuncien aquí determinados procesos de lanzamiento, de software existentes. realicen revisiones de código obligatorias o tengan juntas Además de resistirse al cambio, tanto los asesoras de cambios (ver Chen 2015), lo que puede ser difícil desarrolladores como los operadores pueden carecer de de conciliar con los equipos que lanzan software por su propia las habilidades para adoptar microservicios. El alto grado decisión. Además, pueden surgir problemas de responsabilidad, de autonomía del equipo conlleva un alto grado de responsabilidad.especialmente cuando se ejecutan microservicios en la nube Es posible que ahora los equipos deban ocuparse de (ver Esposito et al. 2016). numerosas cuestiones transversales que antes realizaban La calificación de estos ítems se hizo de manera similar a los drivers, con la diferencia de que se equipos especializados, como seguridad, protección de datos, supervisión, administración de bases de datos, coherencia y copias de seguridad. Especialmente esto último puede ser un desafío con la persistencia distribuida, ya que calificaría la relevancia para abstenerse de adoptar microservicios . Como se desprende de Tab. 6, habilidades insuficientes tanto del personal de operaciones como de desarrollo, así como las copias de seguridad consistentes , que son simples en un sistema centralizado Machine Translated by Google Revista internacional de modelado conceptual vol. 14, núm. 1 (2019). DOI:10.18417/emisa.14.1 Holger Knoche, Wilhelm 12 Hasselbring ya que la resistencia de las operaciones se considera la principal barrera conjuntos de habilidades son las barreras más importantes, con general para la adopción de microservicios, seguida de la complejidad puntajes muy similares (1.71, 1.70, 1.71 y 1.64). de la implementación. Sin embargo, los puntajes generales de los ítems Los desafíos concretos de implementación también se calificaron en una son bastante bajos, y solo las habilidades insuficientes del personal de escala de cuatro puntos. Sin embargo, dado que los encuestados debían operaciones se calificaron significativamente como relevantes (T15: p = calificar la dificultad de la implementación, las etiquetas fueron simple, 0,036). media, difícil e imposible. Los desafíos a calificar se describen a Los elementos restantes tienen una calificación bastante baja en general. continuación. Sin embargo, el cumplimiento y las regulaciones, así como las resistencias de los desarrolladores, se ven de manera muy Para lograr el grado deseado de autonomía del equipo, velocidad de diferente en diferentes industrias, como lo muestran las altas entrega y tiempo de comercialización, se requieren canalizaciones de desviaciones estándar para estos elementos. implementación automatizadas . Como observaron Leppänen et al. La correlación cruzada de los ítems reveló se correlaciones muy significativas, pero de medias a bajas. Los más altos estaban entre el conjunto de habilidades y la resistencia al desarrollo y las operaciones (rs = 0,42, p < 0,001 y rs = 0,40, p < 0,001), lo que no sorprende. (2015), dichas canalizaciones demuestran ser difíciles de implementar en la práctica y, por lo tanto, pueden plantear un desafío de implementación significativo . Como señalaron Gmeiner et al. (2015), las canalizaciones de implementación requieren un alto grado de automatización de pruebas debido a su ejecución frecuente. Esto no solo se aplica a las pruebas unitarias, sino que también es necesario Las cifras específicas de la industria sugieren que la falta de copias de seguridad consistentes es especialmente importante para las empresas de servicios financieros, donde recibió la tercera puntuación automatizar las pruebas de integración y otras etapas de prueba . Según nuestra experiencia, muchas empresas aún dependen en gran medida de las pruebas manuales en estas etapas. más alta de todas las barreras. Fue calificado como relevante por el 60% Para ejecutar las canalizaciones y las pruebas, así como lograr de los encuestados y recibió una puntuación significativamente más alta elasticidad en la producción, es necesario proporcionar recursos que en las otras industrias (T16: p = 0,003). rápidamente según la demanda. Esto a menudo significa un cambio tecnológico y organizativo significativo , ya que observamos que El cumplimiento y las regulaciones pueden ser un problema en la industria del desarrollo y la consultoría, donde el 25 % de los encuestados la calificó como crucial , y en la industria de servicios financieros, donde recibió la puntuación más alta de todas las industrias con una mediana de relevante. Sin embargo, las diferencias de puntuación en ambas industrias no son estadísticamente significativas (T18 y T19, respectivamente). Por proporcionar nuevos recursos y crear entornos de prueba es a menudo un proceso burocrático que involucra trabajo manual y una cantidad considerable de trámites burocráticos. De manera similar a la automatización de pruebas, la creación y configuración de la infraestructura necesaria también debe automatizarse , lo que lleva a descripciones formales de entornos comúnmente denominados Infraestructura como código. el contrario, este artículo recibió , con mucho, el más bajo en general en la industria de energía y manufactura, y significativamente más bajo que en las otras industrias (T17: p = 0.005). Las cifras específicas de funciones y departamentos, que no se incluyen por razones de brevedad, revelan que los consultores El segundo conjunto de desafíos que investigamos tiene que ver con el cambio de tareas de operaciones a los equipos de desarrollo. Por un lado, esto implica que las tareas de operaciones sean realizadas por equipos de desarrollo, incluidas tareas impopulares como el servicio de y líderes calificaron la falta de habilidades como particularmente buscapersonas. Por otro lado, hay un cambio de tareas para los equipos alta. Por ejemplo, el 44 % de los consultores calificó como de operaciones, ya que varias de sus tareas comunes se automatizan cruciales las habilidades operativas insuficientes (puntuación: como parte de las canalizaciones de implementación o se hacen cargo 2,11). Los clientes potenciales se mostraron particularmente de los equipos multifuncionales. Un desafío estrechamente relacionado escépticos acerca de las habilidades insuficientes de los es que ejecutar aplicaciones distribuidas no es fácil y puede ser muy desarrolladores, que fueron calificadas como cruciales por un 36 diferente de ejecutar aplicaciones tradicionales. % (puntuación: 1,82). Una observación notable de las cifras específicas del departamento es que ambos departamentos están de acuerdo en la insuficiencia Machine Translated by Google Modelado empresarial y arquitecturas de sistemas de información vol. 14, núm. 1 (2019). DOI:10.18417/emisa.14.1 Impulsores y barreras 13 para la adopción de microservicios: una encuesta entre profesionales en Alemania Tabla 6: Barreras para la adopción de microservicios en diferentes industrias Desarrollo / General Consultante Energía / Financiero Industria Servicios Venta minorista / comercio electrónico Otro / Desconocido Dakota del Sur Puntuación (media) Puntuación (media) Puntuación (media) Puntuación (media) Puntuación (media) Puntuación (media) Habilidades de operaciones insuficientes 1,71 0,82 2,06 1,27 1,53 1,67 1,89 Resistencia por Ops 1,66 0,87 1,88 1,64 1,68 1,33 1,56 Habilidades de desarrollo insuficientes 1,63 0,95 1,69 1,00 1,79 1,67 1,78 Complejidad de implementación 1,41 0,79 1,62 0,73 1,35 1,00 1,83 Cumplimiento y Regulaciones 1,21 1,11 1,38 0,45 1,50 1,17 1,22 Problemas de compatibilidad 1,13 0,96 1,06 1.09 1,05 0,50 1,50 Copias de seguridad consistentes 1,13 0,88 1,00 0,73 1,60 1,00 1,00 Madurez de la tecnología 0,97 0,78 1,06 0,73 1,05 0,83 1,00 Resistencia por desarrolladores 0,97 1,06 1,06 1,18 1,10 0,50 0.78 Soporte Contratos / Licencias 0,89 0,77 0,56 0,73 1,20 0,50 1.06 monolitos Por lo tanto, las tareas no solo cambian, sino Apoyar la programación políglota también es calificado que también cambian. como notablemente más difícil por los encuestados de Además, seleccionamos algunos desafíos tecnológicos la industria de servicios financieros (T22: p < 0,001). que consideramos como barreras potenciales basados en La correlación cruzada de los ítems no reveló ninguna nuestras experiencias de proyectos industriales. correlación particularmente notable. Con el fin de analizar si Muchas empresas han empleado la persistencia centralizada los participantes atribuyeron los desafíos a barreras durante varios años. Por lo tanto, implementar una específicas, además cruzamos los ítems de ambas preguntas. persistencia descentralizada y políglota puede ser un gran Sorprendentemente , la correlación más fuerte se encontró cambio de paradigma. De manera similar, apoyar la entre los respaldos consistentes y la programación políglota programación políglota puede requerir herramientas , procesos (rs = 0,49, p < 0,001), lo que puede indicar que algunos y conocimientos adicionales. Y como los microservicios son encuestados confundieron la programación políglota con la susceptibles de fallar parcialmente, se requiere suficiente persistencia políglota. monitoreo del tiempo de ejecución , lo que permite detectar y localizar problemas rápidamente. Sin embargo, dicha supervisión requiere una preparación cuidadosa para recopilar 5.5 Aplicabilidad de los microservicios Las la información requerida sin una degradación significativa del aplicaciones comerciales a menudo se ejecutan como rendimiento del tiempo de ejecución. instalaciones locales y no en la nube. Esto se debe a múltiples Como se muestra en la Tab. 7 a continuación, la ejecución de razones, una de las cuales es la preocupación o las aplicaciones distribuidas y el cambio de tareas para los regulaciones con respecto al almacenamiento de datos equipos de operaciones recibieron la puntuación general más personales potencialmente en cualquier parte del mundo. alta de los encuestados, seguidos por el monitoreo, el Dado que los microservicios generalmente se consideran una aprovisionamiento de recursos ad-hoc y la persistencia descentralizada. arquitectura de software nativa de la nube, se pidió a los encuestados que calificaran la idoneidad de los microservicios Pero ninguno de los desafíos parece ser percibido como un "tapón del espectáculo", ya que los puntajes generales son bajos y ninguno de los elementos recibió una calificación notable. para instalaciones locales para software desarrollado por cantidad de calificaciones imposibles . Sin embargo, existen diferencias considerables entre las industrias por un tercero. La intención principal detrás de esta pregunta era investigar hasta qué punto los microservicios se consideran con respecto a desafíos particulares. Por ejemplo, el viables para los productos de software que se venden o se aprovisionamiento ad hoc recibió una puntuación mucho licencian para que los ejecute el cliente respectivo. Como ellos mismos y con licencia, es decir, software desarrollado más alta en la industria de servicios financieros que en señalaron Olsson et al. (2012), la entrega continua de otras industrias (T20: p = 0,037), en particular, la software a los clientes puede requerir nuevos modelos de industria de desarrollo y consultoría (T21: p = 0,003). participación. Por lo tanto, los Machine Translated by Google Revista internacional de modelado conceptual vol. 14, núm. 1 (2019). DOI:10.18417/emisa.14.1 Holger Knoche, 14 Wilhelm Hasselbring Tabla 7: Desafíos de implementación para la adopción de microservicios en diferentes industrias Desarrollo / General Consultante Energía / Financiero Industria Servicios Venta minorista / comercio electrónico Otro / Desconocido Dakota del Sur Puntuación (media) Puntuación (media) Puntuación (media) Puntuación (media) Puntuación (media) Puntuación (media) Ejecución de aplicaciones distribuidas 1.49 Cambio 0,63 1,62 1,36 1,35 1,50 1,61 de tareas de operaciones 1.46 Establecimiento de 0,73 1,75 1,09 1,45 1,67 1,39 monitoreo 1.38 Aprovisionamiento de recursos 1.31 0,64 1,38 1,00 1,40 1,17 1,67 Persistencia descentralizada 1.31 Automatización de 0,77 0,88 1,27 1,55 1,00 1,56 pruebas 1.22 Tareas de operaciones por equipos de 0,73 1,25 1,00 1,30 1,50 1,50 desarrollo 1.13 Creación de canalizaciones 1.10 1.04 0,65 1,31 1,09 1,15 1,17 1,28 0.87 0,78 1,25 1,00 1,16 1,17 1,06 0,74 0,81 1,27 1,15 0,83 1,28 Infraestructura como código 0,79 0,81 0,82 1,10 0,83 1,41 Programación políglota 0,84 0,69 0,73 1,45 0,33 0,67 a los participantes se les insinuó la elasticidad y las Cuando se les preguntó si solo agregarían nuevas implementaciones frecuentes, y podían calificar los funcionalidades o también reemplazarían la funcionalidad microservicios para que se adaptaran perfectamente, bien, existente por microservicios, el 85% de los encuestados moderadamente o nada al escenario respectivo. afirmó que también reemplazarían la funcionalidad existente. Como se muestra en la Tab. 8, la gran mayoría (81 %) de los De manera similar a los impulsores de la adopción de encuestados considera que los microservicios son adecuados para microservicios, intentamos identificar objetivos de el software de desarrollo propio que se ejecuta en las instalaciones. modernización importantes que persiguen las empresas. Por el contrario, solo el 39% de los encuestados los califica como Con este fin, preguntamos a los encuestados si perseguirían tales para el software con licencia. Con base en las discusiones y los siguientes objetivos de modernización de forma las sugerencias dadas a los participantes, asumimos que esta principal, secundaria o no en absoluto mediante la diferencia se debe en gran parte a las dificultades esperadas de introducción de microservicios . La selección de objetivos ejecutar y actualizar con frecuencia aplicaciones complejas y se basa en los controladores de Sect. 5.3 para permitir comparaciones entre los resultados: distribuidas que son desarrolladas y entregadas por un tercero. 1. Mejorar la capacidad de mantenimiento de las 5.6 Objetivos de modernización para aplicaciones existentes Como se señaló anteriormente, aplicaciones 2. Mejorar el tiempo de comercialización de nuevas funciones 3. Mejorar la escalabilidad de las los microservicios también se consideran una opción aplicaciones 4. Mejorar la calidad general de las viable para modernizar el software existente. Dos tercios aplicaciones 5. Hacer preparativos para la entrega continua o de los encuestados afirmaron que había planes o proyectos para introducir microservicios en las aplicaciones DevOps 6. Introducir nueva tecnología a las aplicaciones 7. existentes; los números detallados se muestran en la Fig. 2. Mejorar la motivación del equipo Particularmente notable fue que el 92% de los Las respuestas se resumen en la Tab. 9; los pesos para encuestados que declararon usar microservicios en menor medida el puntaje varían de 2 (principalmente) a 0 (nada ). medida respondió a esta pregunta con un sí, a diferencia Como es obvio en la tabla, el principal objetivo general de los "usuarios intensivos" (79 %) y los no usuarios (32 %). de modernización es mejorar la capacidad de Estos números sugieren que las empresas que ya están usando mantenimiento, seguido de mejorar el tiempo de microservicios en cierta medida planean aumentar su uso de comercialización de nuevas funciones y escalabilidad. microservicios, mientras que es poco probable que aquellas que La diferencia de puntuación entre la mantenibilidad y el aún no han adoptado microservicios lo hagan en un futuro cercano. tiempo de comercialización es estadísticamente significativa (T23: p = 0,003). Mejora de la calidad y preparación de la entr Machine Translated by Google Modelado empresarial y arquitecturas de sistemas de información vol. 14, núm. 1 (2019). DOI:10.18417/emisa.14.1 Impulsores y barreras para la 15 adopción de microservicios: una encuesta entre profesionales en Alemania Tabla 8: Aplicabilidad de microservicios para instalaciones on-premise Desarrollo / General Consultante Energía / Financiero Industria Servicios Venta minorista / comercio electrónico Otro / Desconocido Dakota del Sur Puntuación (media) Puntuación (media) Puntuación (media) Puntuación (media) Puntuación (media) Puntuación (media) Software de desarrollo propio en las instalaciones 1,95 0,57 2.13 1,80 2,05 1,83 1,73 Software con licencia en las instalaciones 1,36 0,68 1.31 1,36 1,45 1,33 1,34 33% 67% General 31% 69% Desarrollo / Consultoría 27% 73% Energía / Manufactura 44% 56% Servicios financieros 100% Comercio minorista / comercio electrónico 39% 61% Otro / Desconocido 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% sí No Figura 2: Planes para introducir microservicios en aplicaciones existentes en diferentes industrias (% de encuestados) y DevOps también se consideran importantes. La introducción 5.7 Rendimiento y transaccionalidad Una propiedad de nuevas tecnologías y la mejora motivacional se califican fundamental de los microservicios es que cada servicio se como significativamente menos importantes que las otras ejecuta en su propio contexto de proceso. Por lo tanto, las metas (T24: p = 0,002). Una pregunta abierta adjunta sobre llamadas de servicio implican al menos interprocesos, en la mayoría de los casos incluso comunicación de red. qué nuevas tecnologías querían introducir los encuestados no arrojó resultados notables. Especialmente, se sabe que la comunicación de red es mucho más lenta que las llamadas a métodos en proceso La correlación cruzada reveló una correlación notable entre mejorar la mantenibilidad y mejorar la calidad (rs = 0,42, p < 0,001), lo que no sorprende. Se encontraron correlaciones más notables, pero más bajas, entre la mejora de la motivación del equipo y la introducción de nueva tecnología (rs = 0,34, p = 0,003) , así como la mejora del tiempo de comercialización (rs = 0,33, p = 0,005). (Litoiu 2004). Los contenedores y las redes superpuestas, que se usan comúnmente en las arquitecturas de microservicios, pueden agregar una penalización de rendimiento adicional (Kratzke 2015). Por lo tanto, mover la funcionalidad existente a los microservicios podría provocar una degradación considerable del rendimiento del software existente. Sin embargo, solo el 36% de los encuestados esperaba que esta degradación fuera grave o incluso crítica. El 51% Como se muestra en la Tab. 9, la relevancia de los objetivos difiere ligeramente entre las industrias. Esto también es cierto para los roles. La observación más notable de las cifras específicas del rol, que no se incluyen por razones esperaba solo una degradación menor, el 13% ninguna degradación en absoluto. Los números detallados se muestran en la Fig. 3. La introducción de llamadas de servicio remoto también de espacio, es que los líderes califican la calidad y la puede afectar el rendimiento de la aplicación de una segunda preparación para Continuous Delivery/DevOps (ambos 73 manera. Como lo muestra Knoche (2016), prolongar los % principalmente, puntaje: 1,73) significativamente más alto contextos de transacción existentes puede aumentar el grado (T25: p = 0,030 y T26: p = 0.042, respectivamente) que los de contención de bloqueo dentro de una base de datos y roles restantes. reducir el rendimiento general de la transacción. Como se señaló en Machine Translated by Google Revista internacional de modelado conceptual vol. 14, núm. 1 (2019). DOI:10.18417/emisa.14.1 Holger Knoche, Wilhelm Hasselbring dieciséis Tabla 9: Objetivos de modernización para aplicaciones existentes Desarrollo / General Consultante Puntaje Energía / Financiero Industria Servicios Otro / Venta minorista / Desconocido comercio electrónico Puntaje Puntaje Puntaje Puntaje Puntaje (significar) (significar) (significar) (significar) (significar) Dakota del Sur (significar) Mejorar la mantenibilidad 1,79 0,48 1.81 2.00 1,85 1.50 1.67 Mejore el tiempo de comercialización 1,54 0,63 1.88 1,09 1,60 1,83 1.33 Mejorar la escalabilidad 1,46 0,58 1,44 1,64 1,60 1,50 1,22 Mejorar calidad 1,39 0,64 1,06 1,64 1,50 1,50 1,39 Preparar CD y DevOps 1,39 0,69 1,56 1,45 1,25 1,67 1,28 Introducir nueva tecnología 1,04 0,75 0,88 1,09 0,90 1,50 1,17 Mejorar la motivación del equipo 0,97 0,68 0,94 0,82 1,10 1,50 0,78 General 5% 31% 13% Desarrollo / Consultoría 13% 50% 11% 17% 50% 33% 10% 5% 45% 33% Comercio minorista / comercio electrónico 0% 18% 64% Servicios financieros Otro / Desconocido 12% 62% 18% Energía / Manufactura 13% 51% 39% 20% 30% 40% 50% 60% 70% 17% 80% 90% 100% Crítico Grave Menor No Figura 3: Degradación esperada del rendimiento debido a la comunicación entre procesos y de red (% de encuestados) el ejemplar proceso de modernización en la Secc. 2.5, las esto puede percibirse como una pérdida, especialmente invocaciones de servicio se insertan de forma incremental en entornos de modernización. En general, el 13 % de los en el monolito modernizado, que aún contiene sus encuestados calificó la falta de disponibilidad de tales contextos transaccionales originales. Incluso si los servicios transacciones como un problema crítico y el 45 % como invocados no participan en la transacción, la sobrecarga un problema grave. El 32 % lo consideró un problema de invocación puede dar lugar a una prolongación de los contextos de transacción del monolito. La mayoría de los encuestados (66%) consideró que esto era un problema potencial, pero esperaba que ocurriera solo menor y el 10 % no vio ningún problema. Como es obvio en la Figura 5, el problema se considera particularmente crítico en el sector de energía y manufactura, donde fue calificado como tal por el 36% de los encuestados. en casos específicos. El 18 % de los encuestados vio esto como un problema grave, especialmente en la industria de servicios financieros, donde el 30 % de los encuestados lo calificó como tal. La menor preocupación fue expresada por A diferencia de las transacciones entre servicios, las transacciones internas de servicios no se desaconsejan en absoluto en las arquitecturas de microservicios. 79% de la re los encuestados de la industria energética y manufacturera. los encuestados consideraron muy importante (27%) o Los números detallados se muestran en la Fig. 4. importante (52%) incorporar límites transaccionales durante el diseño del servicio. Ningún encuestado consideró este tema Como se discutió anteriormente, la transaccionalidad ACID entre servicios se desaconseja en las arquitecturas de sin importancia. Como es evidente en la Fig. 6, las cifras varían entre los sectores de la industria, con una calificación microservicios y, por lo general, no está disponible. Dado que notablemente baja en el sector minorista y de comercio las transacciones ACID son omnipresentes en el software comercial, electrónico. Machine Translated by Google Modelado empresarial y arquitecturas de sistemas de información vol. 14, núm. 1 (2019). DOI:10.18417/emisa.14.1 Impulsores y barreras para la 17 adopción de microservicios: una encuesta entre profesionales en Alemania General Desarrollo / Consultoría 18% 66% 19% 63% dieciséis% 18% 27% 73% Energía / Manufactura Servicios financieros 30% 10% 60% 100% Comercio minorista / comercio electrónico Otro / Desconocido 22% 0% 17% 61% 10% 20% 30% 40% 80% 90% 100% 50% 60% 70% Grave Solo en casos puntuales No Figura 4: Degradación esperada del rendimiento en contextos transaccionales existentes (% de encuestados) General 13% 32% 45% 44% Desarrollo / Consultoría 38% Servicios financieros 10% 0% 18% 19% 55% 35% 17% 10% 17% 33% 50% Comercio minorista / comercio electrónico Otro / Desconocido 18% 27% 36% Energía / Manufactura 10% 44% 20% 30% 40% 33% 50% 60% 70% 6% 80% 90% 100% Crítico Grave Menor No Figura 5: Relevancia de la falta de disponibilidad de la transaccionalidad ACID entre servicios (% de encuestados) 5.8 Respuestas a las preguntas de investigación Para concluir los hallazgos de la encuesta, presentamos las respuestas a las preguntas de investigación introducidas en la Secc. 4.1 a continuación. RQ1: Se encontró que los principales impulsores para para software de terceros que se ejecuta como una instalación local . RQ3: Se descubrió que el objetivo principal para la modernización del software mediante microservicios era mejorar la capacidad de mantenimiento, seguido de un que las empresas adopten microservicios son la tiempo de comercialización más corto y una mejor escalabilidad, la mantenibilidad y el tiempo de escalabilidad. La modernización parece ser un escenario comercialización. La capacidad de servir como habilitador relevante para la adopción de microservicios, ya que dos para la entrega continua y DevOps, la idoneidad para la virtualización y las mejoras organizacionales se calificaron como impulsores secundarios. RQ2: Los conjuntos de habilidades insuficientes tanto de los desarrolladores como de las operaciones, así como la resistencia del personal de operaciones, se tercios de los encuestados afirmaron que existen planes o proyectos para introducir microservicios en las aplicaciones existentes. RQ4: Si bien los encuestados no consideraron muy relevante el impacto potencial en el desempeño en entornos de modernización, se encontró que el perciben como las barreras más importantes para la impacto en la transaccionalidad es un problema importante. adopción de microservicios. Dependiendo de la industria, La mayoría de los encuestados calificó la pérdida de la los problemas de respaldo y cumplimiento también se transaccionalidad ACID entre servicios como una limitación consideran importantes. Además, el escenario de grave, y más de las tres cuartas partes consideran implementación de la aplicación puede impedir la adopción importante incorporar los límites transaccionales en el de microservicios. En particular , los microservicios no se consideran adecuados diseño del servicio. Machine Translated by Google Revista internacional de modelado conceptual vol. 14, núm. 1 (2019). DOI:10.18417/emisa.14.1 Holger Knoche, 18 Wilhelm Hasselbring General 27% 25% Desarrollo / Consultoría 50% 18% Energía / Manufactura Servicios financieros Comercio minorista / comercio electrónico 0% 9% 20% 50% 17% 33% 33% 10% 25% 73% 30% Otro / Desconocido 21% 52% 50% 17% 50% 20% 30% 40% 50% 60% 70% 80% 90% 100% Muy importante Importante No demasiado importante Poco importante Figura 6: Importancia de los límites de transacción para el diseño del servicio (% de encuestados) 6 Discusión La encuesta no representativa22 realizada por el portal para desarrolladores Stack Overflow indica que, en 6.1 Amenazas a la Validez Para discutir las amenazas a la validez de esta encuesta, nos basamos en el esquema presentado por Runeson y Höst (2008). Vemos la mayor amenaza para la validez de construcción en la mala interpretación de las preguntas de la encuesta, en particular, diferentes interpretaciones de los ítems que los participantes debían calificar. Esta amenaza fue particular, la industria de servicios financieros puede estar sobrerrepresentada en nuestra muestra. Además, cabe esperar diferentes grados de heterogeneidad empresarial en los diferentes sectores de la industria, pero no pueden cuantificarse debido al anonimato del estudio. Por lo tanto, es posible que algunos resultados estén sesgados por un gran número de participantes de la misma empresa Otra amenaza puede resultar del tamaño de la muestra. Aunque estamos muy contentos con el número mitigada por un cuidadoso diseño del cuestionario, discusión interna y pruebas. total de encuestados, algunos grupos eran demasiado Además, el cuestionario contenía varios términos que pequeños para obtener resultados estadísticamente significativos. pueden considerarse "palabras de moda" (incluido el En particular, el grupo "Retail / E-Commerce", que se propio término "microservicios"), que pueden ser estableció solo debido al papel pionero de esta industria particularmente sospechosos de mala interpretación . para los microservicios, tuvo muy pocos participantes y, Sin embargo, decidimos usar estos términos porque por lo tanto, los resultados pueden estar sesgados. sentimos que estos términos eran con los que los participantes estaban más familiarizados y el uso de términos diferentes podría haber causado confusión adicional. En cuanto a la validez externa, vemos la amenaza Como realizamos múltiples pruebas estadísticas en el mismo conjunto de datos, los resultados pueden estar sujetos a la acumulación de errores alfa, es decir, la más importante en el tamaño y la estructura de la probabilidad de rechazar incorrectamente la hipótesis muestra. Dado que la muestra solo contenía profesionales nula en una de estas pruebas es en realidad más alta de Alemania, la generalización de los resultados a otros que la tasa de error alfa individual para cada una. prueba. países puede ser limitada. Como los encuestados se Este efecto es particularmente importante cuando se adquirieron mediante una combinación de muestreo de extraen conclusiones de múltiples pruebas al mismo conveniencia y de bola de nieve, la muestra no fue tiempo (p. ej., un fármaco se considera eficaz cuando representativa. Creemos, sin embargo, que debido a la conduce a una mejora significativa de una de varias población objetivo muy específica, este método de enfermedades). Sin embargo, como ninguna conclusión de este muestreo fue la mejor opción con respecto a la precisión y la tasa de respuesta. Una comparación con la estructura muestral de un gran, pero también 22 Ver https://www.stackoverflowbusiness.com/de/talent/ ressourcen/die-stack-overflow-entwicklerumfrage-2017 (en alemán) Machine Translated by Google Modelado empresarial y arquitecturas de sistemas de información vol. 14, núm. 1 (2019). DOI:10.18417/emisa.14.1 Impulsores y barreras para la adopción de 19 microservicios: una encuesta entre profesionales en Alemania tipo se extraen en este estudio, el efecto de los hallazgos La naturaleza distribuida de los microservicios se considera falsamente significativos se limita a ese resultado en particular. el principal desafío. El tiempo de respuesta y el rendimiento, junto con la seguridad, plantearon las mayores Otra amenaza surge de la decisión de apuntar preocupaciones con respecto a las propiedades no funcionales. principalmente a los profesionales que ya están Esta es una diferencia notable en nuestros resultados, ya que preocupados por los microservicios. Si bien su nuestros encuestados no esperaban que el rendimiento fuera un conocimiento existente sobre microservicios puede problema al introducir microservicios, y también difiere de otros reducir el riesgo de mala interpretación y aumentar la informes de práctica como (Gouigoux y Tamzalit 2017). El aspecto solidez de sus respuestas, también puede conducir a un de la modernización mediante microservicios no se investiga en sesgo positivo hacia este estilo arquitectónico. Por lo esta encuesta. tanto, también incluimos datos de siete encuestados que informaron no tener un conocimiento significativo de los Di Francesco et al. (2018) informan sobre varios desafíos con los sistemas de software preexistentes que pueden microservicios. Sin embargo, dado que los microservicios impulsores de la modernización. Si bien se son actualmente un tema de “bombo”, podría existir un cierto sesgoconsiderarse a favor de los microservicios. esperado. considera que el tiempo de comercialización prolongado es Una amenaza para la confiabilidad puede resultar del hecho de que adquirimos un número significativo de encuestados al hablar con ellos personalmente. Aunque tuvimos mucho cuidado de no sugerir nada sobre las preguntas a los encuestados, este riesgo no se puede descartar por completo. el principal desafío, tres de los cinco principales desafíos se refieren directa o indirectamente a la falta de capacidad de mantenimiento (acoplamiento alto, efectos secundarios inesperados de los cambios). En cuanto a la implementación de microservicios, la configuración de la infraestructura requerida, el cambio en la mentalidad del desarrollador y el monitoreo distribuido son los tres desafíos principales. 6.2 Comparación con los resultados de otros estudios Esto se corresponde razonablemente con nuestros hallazgos de que las habilidades insuficientes de los desarrolladores, la Como se discutió en la Secc. 3, hay varios otros estudios ejecución de aplicaciones distribuidas y el monitoreo son barreras cuyos resultados complementan los hallazgos de este importantes para la adopción de microservicios. Las barreras estudio. En los siguientes párrafos, discutimos las similitudes y diferencias entre debidas al personal de operaciones, que fueron calificadas como los hallazgos de esos estudios y los nuestros. Al igual que en nuestro estudio, Taibi et al. (2017) las más altas por nuestros participantes, no se mencionan en este estudio. La encuesta industrial realizada por NGINX (2016) informa que aproximadamente un tercio de los encuestados encuentran que la mantenibilidad y la escalabilidad son los usan microservicios en producción, un tercio investiga principales impulsores de la adopción de microservicios. microservicios y un tercio no los usa en absoluto. Esto Según sus resultados, una mejora en la mantenibilidad es coincide bastante bien con nuestros números sobre la también el beneficio más importante que se logra realmente. adopción de microservicios, pero debido a los diferentes El corto tiempo de comercialización, el tercer impulsor métodos de muestreo y población objetivo, estas similitudes deben considerarse con cuidado. principal identificado por nuestro estudio, no se investiga. La idoneidad para DevOps, así como una mejor organización del Un estudio de Lightbend, Inc. (2016) informa cifras equipo, también se identifican como impulsores secundarios en similares sobre los planes para el uso de microservicios. su estudio. En cuanto a las barreras, se considera que el traslado También informa sobre los impulsores de la adopción de de la funcionalidad del monolito a los microservicios y la división microservicios y menciona la agilidad y velocidad de de la base de datos son los más importantes. Las barreras relacionadas con las personas, como la resistencia o la falta de desarrollo, así como la elasticidad, como los más importantes, y establece que el uso de microservicios para modernizar habilidades, que recibieron la puntuación más alta en nuestro ción es particularmente importante para las grandes empresas. estudio, solo se investigaron marginalmente. Ghofrani y Lübke (2018) identifican la escalabilidad y la agilidad como los impulsores principales, mientras que la El cambio cultural se menciona como una de las principales barreras para la adopción de microservicios, especialmente para las grandes empresas. No se nombran otras barreras. Machine Translated by Google Revista internacional de modelado conceptual vol. 14, núm. 1 (2019). DOI:10.18417/emisa.14.1 Holger Knoche, 20 Wilhelm Hasselbring La importancia del cambio cultural, que puede generar En cuanto a los modos de operación, los resultados resistencia, también se destaca en la investigación empírica de la Secc. 5.5 implica que los microservicios no se sobre DevOps (Riungu-Kalliosaari et al. consideran muy viables para el software con licencia 2016; Smeds et al. 2015), así como informes de tradicional, es decir, el software desarrollado por un experiencia sobre la adopción de Continuous Delivery tercero y ejecutado por el cliente. Por lo tanto , los (Neely y Stolt 2013). Al comparar nuestro estudio con estudios anteriores sobre la adopción de arquitecturas orientadas a servicios (SOA), se hace evidente que las motivaciones para la proveedores de dicho software podrían querer considerar ofrecerlo como un servicio (SaaS) al pasar a microservicios en lugar de proporcionarlo para que lo opere el cliente. Los resultados de la Secc. 5.7 indican además que adopción de SOA eran bastante diferentes de las la consistencia y la transaccionalidad deben ser motivaciones para emplear microservicios. Un estudio cuidadosamente consideradas durante el diseño del realizado por MacLennan y Van Belle (2014) informa que los impulsores importantes son la mejora de la agilidad servicio. Especialmente cuando se va a emplear la persistencia políglota, se debe decidir si se requieren organizativa, la reutilización, la representación estandarizada transacciones ACID y dónde, y dónde es suficiente la de datos, la integración de sistemas heredados y la mejora consistencia eventual. Para este último caso, además, es de los procesos empresariales . Si bien la agilidad mejorada necesario elegir e implementar estrategias para tratar las está estrechamente relacionada con nociones como el inconsistencias (ver Secc. 2.4). tiempo de comercialización corto (Becker et al. 2009), la integración heredada y los procesos comerciales apenas 7 Conclusiones y Trabajo Futuro se analizan en el contexto de los microservicios . De manera similar, varios de los desafíos del estudio se refieren a la En este documento, hemos identificado impulsores y gobernanza (centralizada), que se evita en la medida de lo barreras importantes para la adopción de microservicios posible en entornos de microservicios . El fuerte enfoque en la industria de software alemana y resaltado algunas en la integración (empresarial) también está respaldado por los hallazgos de Joachim (2011). diferencias sin tabla entre los sectores de la industria. Se encontró que los impulsores principales eran la escalabilidad, 6.3 Implicaciones de los resultados la mantenibilidad y el tiempo de comercialización, mientras Los resultados de nuestro estudio indican varias que el conjunto de habilidades del personal de desarrollo y implicaciones para las empresas que consideran la adopción de microservicios. Con base en nuestros los encuestados consideraron que varios desafíos de resultados sobre las barreras y los desafíos de implementación eran difíciles, no se identificaron obstáculos . operaciones se identificó como la principal barrera. Aunque implementación presentados en la Secc. 5.3 y secc. 5.4, las empresas deben prestar especial atención a los cambios culturales y relacionados con las personas que implican los Con respecto a los impulsores, observamos diferencias interesantes entre los primeros usuarios que enfatizan la microservicios. La resistencia potencial tanto por parte de escalabilidad de sus sistemas de "escala de Internet", en los desarrolladores como del personal de operaciones debe comparación con las empresas tradicionales que enfatizan investigarse y abordarse con anticipación. Y se debe tener la mantenibilidad de sus sistemas de TI. En particular, cuidado de que los equipos de desarrollo sean realmente para la adopción de microservicios como un medio para capaces de realizar las nuevas tareas que se les asignen, la modernización del software, la mantenibilidad parece ser el factor La degradación del rendimiento que ahora pueden incluir aspectos de operación como garantizar la seguridad y laprincipal. protección. debido a las invocaciones remotas se considera un Además, observamos que el tema del cumplimiento y las regulaciones puede estar subestimado. Aunque este problema menor, mientras que la falta de transaccionalidad ítem no recibió una puntuación particularmente alta (1,21), entre servicios parece ser una preocupación grave. la desviación estándar alta (1,11) indica que existen Como trabajo futuro, sería recomendable replicar un estudio similar con la industria del software en otros países y compararlo con la situación alemana. diferentes opiniones sobre este tema. Machine Translated by Google Modelado empresarial y arquitecturas de sistemas de información vol. 14, núm. 1 (2019). DOI:10.18417/emisa.14.1 Impulsores y barreras para la adopción de microservicios: una encuesta entre profesionales en Alemania valioso. El material de estudio está disponible en Zen Chen L. (2018) Microservicios: arquitectura para entrega odo,23 para que otros investigadores puedan replicar y continua y DevOps. En: Actas de la Conferencia Internacional IEEE sobre Arquitectura de Software (ICSA) ampliar nuestro trabajo. También está disponible un informe técnico en alemán sobre los resultados de este estudio.24 de 2018. IEEE, págs. 39–397 Otras oportunidades para el trabajo futuro incluyen una investigación más detallada de los impulsores y las barreras identificadas en este estudio. Por ejemplo, sería valioso comprender mejor las razones precisas de las resistencias para poder abordar Di Francesco P., Lago P., Malavolta I. (2017) Investigación sobre arquitectura de microservicios: tendencias, enfoque y potencial para la adopción industrial. En: Actas de la Conferencia Internacional IEEE sobre Arquitectura de Software (ICSA) de 2017. IEEE, págs. 21– ellos correctamente. Otro tema interesante sería investigar 30 si el uso de enfoques modernos como los microservicios puede ser una forma de aumentar el atractivo como empleador. Referencias Di Francesco P., Lago P., Malavolta I. (2018) Migración hacia arquitecturas de microservicios: un estudio industrial. En: Actas de la Conferencia internacional IEEE 2018 sobre software Ar arquitectura (ICSA). IEEE, págs. 29–2909 Alshuqayran N., Ali N., Evans R. (2016) Un estudio de mapeo sistemático en la arquitectura de microservicios. En: Actas de la 9ª Conferencia Internacional sobre Informática y Aplicaciones Orientadas a Servicios (SOCA). IEEE, págs. 44–51 Balalaie A., Heydarnoori A., Jamshidi P. (2016) La arquitectura de microservicios permite DevOps: migración a una arquitectura nativa de la nube. En: IEEE Espósito C., Castiglione A., Choo KR (2016) Desafíos en la entrega de software en la nube como microservicios. En: IEEE Cloud Computing 3(5), págs. 10– 14 Evans E. (2007) Diseño impulsado por el dominio: abordar la complejidad en el corazón del software. Addison Wesley, río Upper Saddle Software 33(3), págs. 42–52 Fowler M. (2014) Requisitos previos del microservicio http: // Bass L., Weber I., Zhu L. (2015) DevOps: la perspectiva de martinfowler.com/bliki/MicroservicePrerequisitoÿ sitios.html Último acceso: 2018-11-30 un arquitecto de software. Addison-Wesley, Nueva York Ghofrani J., Lübke D. (2018) Desafíos de la arquitectura Becker A., Buxmann P., Widjaja T. (2009) Valor potencial y desafíos de las arquitecturas orientadas a servicios : una perspectiva de usuario y proveedor. En: Actas de la 17ª Conferencia Europea sobre Sistemas de Información de microservicios: una encuesta sobre el estado de la práctica. En: Actas del 10º Taller de Europa Central sobre Servicios y su Composición (ZEUS). Actas del taller CEUR, Aquisgrán, págs. 1–8 (ECIS). 88. Biblioteca electrónica AIS https://aisel.aisnet.org/ ecis2009/88 Carrasco A., van Bladel B., Demeyer S. (2018) Migración hacia los microservicios: olores de migración y arquitectura. En: Actas del 2º Taller Internacional sobre Refactorización (IWoR). Gmeiner J., Ramler R., Haslinger J. (2015) Pruebas automatizadas en el canal de entrega continua: un estudio de caso de una empresa en línea. En: Actas de la 8ª Conferencia Internacional IEEE sobre Talleres de Prueba, Verificación y Validación de Software (ICSTW). IEEE, págs. 1a6 ACM, Nueva York, págs. 1–6 Chen L. (2015) Entrega continua: Enormes beneficios, pero Gouigoux JP, Tamzalit D. (2017) From Monolith to Microservices: Lessons Learned on an Indus también desafíos. En: Software IEEE 32(2), págs. 50–54 Migración de prueba a una Arquitectura Orientada a Web. En: Actas de la Conferencia internacional IEEE 2017 sobre 23 https://doi.org/10.5281/zenodo.820146 24 ver http://eprints.uni-kiel.de/38682/ talleres de arquitectura de software (ICSAW). IEEE, págs. 62–65 21 Machine Translated by Google Revista internacional de modelado conceptual vol. 14, núm. 1 (2019). DOI:10.18417/emisa.14.1 Holger 22 Knoche, Wilhelm Hasselbring Hasselbring W. (2016) Microservicios para la Leppänen M., Mäkinen S., Pagels M., Eloranta VP, Itkonen escalabilidad : Resumen de la charla magistral. En: Actas de la 7ª Conferencia Internacional ACM/SPEC J., Mäntylä MV, Männistö T. (2015) sobre Ingeniería de Rendimiento (ICPE). ACM, págs. 133– 134 Las Carreteras y Caminos Rurales al Despliegue Continuo. En: IEEE Software 32(2), págs. 64–72 Hasselbring W., Steinacker G. (2017) Arquitecturas de Lewis J., Fowler M. (2014) Microservicios http: //martinfowler. com/articulos/microservicios.html microservicios para escalabilidad, agilidad y confiabilidad Último acceso: 2018-11-30 en el comercio electrónico. En: Actas de la Conferencia Internacional de Software IEEE 2017 Talleres de Arquitectura (ICSAW). IEEE, págs. 243– 246 Lightbend, Inc. (2016) Tendencias de desarrollo empresarial 2016 https:// info.lightbend.com/COLL 20XX - Empresa - Desarrollo - Tendencias - 2016 - Humble J., Farley D. (2011) Entrega continua. Informe_RES-LP.html Último acceso: 2018-11-30 Addison-Wesley, río Upper Saddle Litoiu M. (2004) Migración a servicios web: un enfoque de Hüttermann M. (2012) DevOps para desarrolladores. Apress, Nueva York ingeniería de rendimiento. En: Revista de Mantenimiento y Evolución de Software: Investigación Joachim N. (2011) Una revisión bibliográfica de la y Práctica 16(1–2), págs. 51–70 investigación sobre arquitecturas orientadas a servicios (SOA): características, determinantes de adopción, MacLennan E., Van Belle J.-P. (2014) Factores que mecanismos de gobierno e impacto empresarial. En: Actas afectan la adopción organizacional de la arquitectura de la 7ma Conferencia de las Américas sobre Sistemas de orientada a servicios (SOA). En: Sistemas de Información (AMCIS). 339. Biblioteca electrónica AIS https:// Información y Gestión de Negocios Electrónicos 12(1), pp. 71–100 aisel.aisnet.org/amcis2011_submissions/ 339 Killalea T. (2016) Los dividendos ocultos de los microservicios. En: Comunicaciones de la ACM 59(8), págs. 42–45 Knapp TR (1990) Tratamiento de escalas ordinales Nagappan N., Murphy B., Basili V. (2008) La influencia de la estructura organizativa en la calidad del software. En: Actas de la 30.ª Conferencia Internacional ACM/IEEE sobre Ingeniería de Software (ICSE). IEEE, págs. 521–530 como escalas de intervalo: un intento de resolver la controversia. En: Investigación de Enfermería 39(2), pp. 121– 123 Neely S., Stolt S. (2013) ¿Entrega continua? ¡Fácil! Simplemente cambie todo (bueno, tal vez no sea tan fácil). En: Actas de la Conferencia Agile 2013. IEEE, Knoche H. (2016) Combinación de la supervisión a nivel de págs. 121–128 aplicación y de base de datos para analizar el impacto en el rendimiento de la contención de bloqueo de base de datos. Newman S. (2015) Creación de microservicios. En: Softwaretechnik-Trends 36(4), págs. 25–27 O'Reilly, Sebastopol Knoche H., Hasselbring W. (2018) Uso de microservicios para la modernización del software heredado. En: IEEE Software 35(3), págs. 44–49 NGINX (2016) El futuro del desarrollo y la entrega de aplicaciones es ahora https://www.nginx. com/resources/ library/app-dev-encuesta/ Último acceso : 2018-11-30 Kratzke N. (2015) Acerca de los microservicios, los contenedores y su impacto subestimado en el rendimiento de la red. En: Actas de la 6ª Conferencia Nygard MT (2007) ¡Suéltalo! – Diseñar e implementar Internacional sobre Computación en la Nube, GRID y software listo para producción. La estantería pragmática, Virtualización. IARIA, págs. 165–169 Raleigh Machine Translated by Google Modelado empresarial y arquitecturas de sistemas de información vol. 14, núm. 1 (2019). DOI:10.18417/emisa.14.1 Impulsores y barreras para la adopción de microservicios: una encuesta entre profesionales en Alemania Olsson HH, Alahyari H., Bosch J. (2012) Subiendo la Smeds J., Nybom K., Porres I. (2015) DevOps: una "escalera al cielo": un estudio de casos múltiples que definición e impedimentos de adopción percibidos. explora las barreras en la transición del desarrollo ágil En: Actas de la Conferencia Internacional sobre hacia la implementación continua de software. En: Actas Procesos Ágiles en Ingeniería de Software y de la 38.ª Conferencia Euromicro sobre Ingeniería de Programación Extrema (XP). Springer, Berlín, págs. Software y Aplicaciones Avanzadas. IEEE, págs. 392– 166–177 399 Pahl C., Jamshidi P. (2016) Microservicios: un estudio de 23 Stevens SS (1946) Sobre la teoría de las escalas y la medida. En: Science 103 (2684), págs. 677– 680 mapeo sistemático. En: Actas de la 6.ª Conferencia internacional sobre ciencia de servicios y computación en Stine M. (2015) Migración a arquitecturas de aplicaciones la nube (CLOSER). ACM, págs. 137– 146 nativas de la nube. O'Reilly, Pekín Pardon G., Pautasso C. (2014) Transacciones distribuidas atómicas: un diseño RESTful. En: Actas de la 23ª Conferencia Internacional sobre World Wide Web. ACM, págs. 943–948 Taibi D., Lenarduzzi V., Pahl C. (2017) Procesos, motivaciones y problemas para migrar a arquitecturas de microservicios: una investigación empírica. En: IEEE Cloud Computing 4(5), págs. 22–32 Vogels W. (2009) Eventualmente consistente. En: Communications of the ACM 52(1), pp. 40–44 Razavian M., Lago P. (2010) Comprensión de la migración SOA mediante un marco conceptual. En: Journal of Systems Integration 1(3), págs. 33–44 Riungu-Kalliosaari L., Mäkinen S., Lwakatare LE, Tiihonen J., Männistö T. (2016) Beneficios y desafíos de la adopción de DevOps en la práctica: un estudio de caso. En: Actas de la Conferencia Internacional sobre Mejora de Procesos de Software Centrada en Productos (PROFES). Springer, Berlín, págs. 590–597 Runeson P., Höst M. (2008) Directrices para la realización y presentación de informes de estudios de casos de investigación en ingeniería de software. En: Ingeniería de software empírica 14(2), p. 131 Schermann G., Cito J., Leitner P. (2016) All the Services Large and Micro: Revisiting Indus trial Practice in Services Computing. En: Actas de los talleres de la Conferencia Internacional sobre Informática Orientada a Servicios (ICSOC) . Springer, Berlín, págs. 36–47 Singleton A. (2016) La economía de los microservicios . En: IEEE Cloud Computing 3(5), págs. 16–20 Wolff E. (2016) Microservicios: arquitecturas de software flexibles. Addison Wesley, Boston Esta obra tiene una licencia Creative Commons “Atribución-CompartirIgual 4.0 Licencia internacional” . Machine Translated by Google Revista internacional de modelado conceptual vol. 14, núm. 1 (2019). DOI:10.18417/emisa.14.1 24 Preguntas de una encuesta 1. Resistencia de los equipos de desarrollo A continuación se incluye una traducción de las preguntas 2. Habilidades de desarrollador insuficientes utilizadas en la encuesta con sus opciones de respuesta. Las 3. Resistencia de los equipos de operaciones preguntas cuyos resultados no se utilizan en este documento 4. Habilidades de operaciones insuficientes están marcadas con un asterisco (ÿ). 5. Mayor esfuerzo para apoyar y licenciar bases de datos, etc. Pregunta 1 ¿ Desde cuando te preocupan los microservicios ? 6. Mayor complejidad de implementación 7. Incompatibilidad con el cumplimiento y la regulación • Desde ÿ meses / ÿ años • Aún no ciones 8. Madurez insuficiente de las tecnologías Pregunta 2 ¿Su empresa o cliente ya emplea microservicios? 9. Dificultad de realizar copias de seguridad coherentes debido a la persistencia distribuida 10. Incompatibilidades con el software existente • Sí, en gran medida • Sí, en menor medida • No Pregunta 5 ¿Qué tan difícil cree que es implementar los siguientes aspectos relacionados con los microservicios? Pregunta 3 (Opciones de respuesta para cada ítem: simple, ¿Qué importancia cree que tienen las siguientes propiedades medio, difícil, imposible) comúnmente atribuidas a los microservicios para la decisión de emplear microservicios? ( Opciones de respuesta para cada ítem: 1. Creación de una canalización de implementación automatizada irrelevante, poco relevante, relevante, crucial) 2. Aprovisionamiento ad-hoc de recursos (p. ej., para pruebas de integración automatizadas) 1. Escalabilidad/elasticidad fácil y específica 2. “Tiempo 3. Persistencia descentralizada/distribuida 4. Tener de comercialización” corto (es decir, tiempo desde el desarrollo tareas de operaciones realizadas por desarrollo hasta la implementación productiva) 3. Alta capacidad de mantenimiento 4. Elección del lenguaje de programación específico del servicio ("Programación políglota") equipos 5. Cambio de tareas y responsabilidades para ops equipos 6. Ejecutar aplicaciones muy distribuidas en producción 5. Elección de base de datos / solución de persistencia específica del servicio ("Polyglot Persistence") 7. Automatización de pruebas de integración y pruebas adicionales. 6. Habilitador para la entrega continua/DevOps 7. Idoneidad para la implementación en la nube y la virtualización basada en contenedores etapas 8. Descripción formal de la infraestructura (“Infraestructura como Código”) 8. Mejora de las estructuras organizativas 9. Mejora del atractivo como empleador Pregunta 4 9. Soporte para varios lenguajes de programación. ("Programación Políglota") 10. Establecimiento de un seguimiento suficiente ¿Qué tan relevantes cree que son las siguientes barreras para la decisión de emplear microservicios? Pregunta 6 (ÿ) (Opciones de respuesta para cada ítem: irrelevante, Los microservicios suelen estar relacionados con las aplicaciones poco relevante, relevante, crucial) web , pero no se limitan a ellas. Que tan bien Machine Translated by Google Modelado empresarial y arquitecturas de sistemas de información vol. 14, núm. 1 (2019). DOI:10.18417/emisa.14.1 25 ¿Cree que los microservicios son adecuados para los Pregunta 10 siguientes tipos de aplicaciones? (Opciones de respuesta (Si eligió "Obtener acceso a nuevas tecnologías" arriba): ¿ A para cada ítem: nada, moderadamente, bien, perfectamente) qué tecnologías le gustaría tener acceso? (Pregunta abierta) 1. Aplicaciones web públicas 2. Aplicaciones web internas 3. Pregunta 11 ¿Agregaría solo nueva funcionalidad o también reemplazaría Aplicaciones cliente-servidor 4. la funcionalidad existente por microservicios ? Aplicaciones heredadas 5. Aplicaciones por lotes Pregunta 7 La mayoría de las aplicaciones de microservicio conocidas se ejecutan en la nube. Sin embargo, muchas empresas ejecutan software de desarrollo propio o con licencia en su propio • No, solo agregaría nueva funcionalidad • Sí, también reemplazaría la funcionalidad existente Pregunta 12 (ÿ) (Si también reemplazara la funcionalidad existente): ¿Espera poder reutilizar partes de la implementación existente? hardware. ¿Qué tan bien cree que los microservicios son adecuados para tales situaciones (por ejemplo, con respecto a la elasticidad y las implementaciones frecuentes)? • Sí, en gran medida • Sí, en ( Opciones de respuesta para cada ítem: nada, moderadamente, menor medida bien, perfectamente) • No, pero me gustaría • No, 1. Ejecutar software de desarrollo propio en su propio disco no quiero aunque pudiera mercancía 2. Ejecución de software con licencia en hardware propio Pregunta 8 Pregunta 13 Los microservicios conducen a un aumento en la comunicación entre procesos o de red. ¿Espera que esto cause una disminución en el rendimiento del tiempo de ejecución? ¿Ya existen planes o proyectos en su empresa para introducir microservicios en las aplicaciones existentes ? • Sí, crítico • Sí, grave • Sí, • Sí • No Pregunta 9 ¿Qué objetivos perseguiría al introducir microservicios en una aplicación existente? ( Opciones de respuesta para cada pero menor • No Pregunta 14 La persistencia distribuida de microservicios comúnmente requiere evitar la transaccionalidad ACID entre servicios. ¿Cómo califica este rechazo? ítem: principalmente, en segundo lugar, en absoluto) • Crítico • Importante 1. Mejorar la escalabilidad • Apenas relevante 2. Mejorar el “tiempo de comercialización” • Irrelevante 3. Mejorar la mantenibilidad 4. Mejorar la calidad 5. Acceder a nuevas tecnologías 6. Preparar el camino para la entrega continua/DevOps 7. Mejorar la motivación de los empleados Pregunta 15 La introducción de invocaciones de servicios en contextos de transacciones existentes puede prolongar su tiempo de ejecución, lo que reduce el rendimiento. ¿Crees que esto es un problema ? Machine Translated by Google Revista internacional de modelado conceptual vol. 14, núm. 1 (2019). DOI:10.18417/emisa.14.1 26 • Sí, un problema grave • Sí, pero solo en casos puntuales • No Pregunta 16 ¿Qué tan importante cree que es incorporar límites transaccionales en el diseño del servicio? • Muy importante • Importante • No demasiado importante • Sin importancia Pregunta 17 ¿En qué rubro se encuentra usted/está su empresa (por ejemplo, Banca, Consultoría)? (Pregunta abierta) Pregunta 18 ¿Qué puesto(s) ocupa? • Gestión • Arquitecto de Software • Desarrollador de software • Consultor • Otro: (Espacio para respuesta) Pregunta 19 ¿En qué departamento(s) / área(s) trabaja? • Desarrollo • Operaciones • Departamento Especializado • Otro: (Espacio para respuesta) Machine Translated by Google Modelado empresarial y arquitecturas de sistemas de información vol. 14, núm. 1 (2019). DOI:10.18417/emisa.14.1 27 B Detalles sobre las pruebas estadísticas Los detalles sobre las pruebas de significación estadística individuales en el documento se proporcionan a continuación. Para cada prueba, se proporciona el tipo de prueba , la hipótesis alternativa, los datos relevantes y el valor p de la prueba. Para especificar la hipótesis alternativa, utilizamos la siguiente notación: • ls(p1, p2) se refiere al cambio de ubicación entre las distribuciones de las submuestras definidas por la selección predicados p1 y p2 • mediana(p) se refiere a la mediana de la puntuación de la submuestra definida por el predicado de selección p Los predicados de selección para las respuestas se especifican de la siguiente manera: • Los grupos (p. ej., "finanzas" para "Servicios financieros") se escriben sin letras mayúsculas. Si solo hay un grupo dado (solo válido para preguntas de sí/no), se refiere a las respuestas positivas • Los complementos de grupos se escriben con una raya (p. ej., “finanzas” para todas las respuestas que no son del dominio de servicios financieros) • Los aspectos (p. ej., "Tiempo de comercialización") se escriben con las primeras letras en mayúscula. Si no se da ningún grupo, se refiere a todas las respuestas para este aspecto • Los aspectos de un grupo se escriben como "Aspecto@Grupo", por ejemplo, "Tiempo de comercialización@finanzas" Para abreviar, usamos las siguientes abreviaturas para grupos y aspectos: Abreviatura Nombre completo devcons Desarrollo / Consultoría finanzas Energía / Manufactura energéticas Servicios financieros minorista de usuarios "usuarios pesados" pesados Venta minorista / comercio electrónico Abreviatura Attr. Nombre completo Emplear. Atractivos como empleador Copias de Copias de seguridad consistentes seguridad Habilitador para CD y DevOps Cumplimiento de Cumplimiento y Regulaciones CD/DevOps Idoneidad para Cloud y Docker Capacidad de Alta mantenibilidad mantenimiento de Introducir nueva tecnología Docker/nube Nueva Habilidades de operaciones insuficientes tecnología Ops Skills Poly. Persistir. Persistencia políglota Escuela politécnica. Programa. Programación políglota Aprovisionamiento Aprovisionamiento de recursos Calidad Mejorar calidad Escalabilidad Alta escalabilidad y elasticidad Tiempo de comercialización Corto tiempo de comercialización Machine Translated by Google Revista internacional de modelado conceptual vol. 14, núm. 1 (2019). DOI:10.18417/emisa.14.1 28 B.1 Pruebas sobre la Pregunta 2 Prueba T1 Prueba de dos muestras Tipo de prueba Prueba de suma de rangos de Wilcoxon ls alternativo (minorista, minorista) > 0 Datos n1 = 6; n2 = 65 m1 = 1 ; m2 = 0 W = 328,5000 0,001656 valor p Prueba T2 Prueba de dos muestras Tipo de Prueba de suma de rangos de Wilcoxon prueba Alternativa ls(finanzas, finanzas) < 0 Datos n1 = 20 ; n2 = 51 m1 = ÿ1 ; m2 = 0 W = 339 0,009998 valor p B.2 Pruebas sobre la Pregunta 3 Prueba T3 Prueba de dos muestras Tipo de prueba Prueba de suma de rangos de Wilcoxon ls alternativo (tiempo de comercialización, CD/DevOps) > 0 Datos n1 = 71; n2 = 71 m1 = 2 ; m2 = 2 W = 3261 valor p 0.000597 Tipo de Prueba de suma de rangos de Wilcoxon Prueba T4 Prueba de dos muestras prueba Alternativa ls(Attr. Emplo., Poly. Program.) < 0 Datos n1 = 71; n2 = 71 m1 = 1 ; m2 = 1 W = 1898 valor p 0.003724 Tipo de prueba Prueba de suma de rangos de Wilcoxon Prueba T5 Prueba de dos muestras ls alternativo (Docker/Cloud@devcons, Docker/Cloud@devcons) > 0 Datos n1 = 16; n2 = 55 m1 = 2 ; m2 = 1 W = 592 0,013572 valor p Machine Translated by Google Modelado empresarial y arquitecturas de sistemas de información vol. 14, núm. 1 (2019). DOI:10.18417/emisa.14.1 29 Prueba T6 Prueba de dos muestras Tipo de Prueba de suma de rangos de Wilcoxon prueba Alternativa ls(Poly. Program.@enermfg, Poly. Program.@enermfg) > 0 Datos n1 = 11; n2 = 60 m1 = 2 ; m2 = 1 W = 463,5000 valor p 0.012416 Tipo de Prueba de suma de rangos de Wilcoxon Prueba T7 Prueba de dos muestras prueba Alternativa ls(Poly. Program.@retail, Poly. Program.@retail) > 0 Datos n1 = 6; n2 = 65 m1 = 2 ; m2 = 1 W = 283 0,027161 valor p Prueba T8 Prueba de dos muestras Tipo de Prueba de suma de rangos de Wilcoxon prueba Alternativa ls(Attr. Employ.@minorista, Attr. Employ.@minorista) > 0 Datos n1 = 6 ; n2 = 65 m1 = 2 ; m2 = 1 W = 290,5000 0,017768 valor p Prueba T9 Prueba de dos muestras Tipo de Prueba de suma de rangos de Wilcoxon prueba Alternativa ls(Tiempo de comercialización@enermfg, Tiempo de comercialización@enermfg) < 0 Datos n1 = 11 ; n2 = 60 m1 = 2 ; m2 = 2 W = 200 0,012007 valor p Prueba T10 Prueba de dos muestras Tipo de prueba Prueba de suma de rangos de Wilcoxon ls alternativo (Docker/Cloud@enermfg, Docker/Cloud@enermfg) < 0 Datos n1 = 11; n2 = 60 m1 = 1 ; m2 = 2 W = 211 0,022894 valor p Machine Translated by Google Revista internacional de modelado conceptual vol. 14, núm. 1 (2019). DOI:10.18417/emisa.14.1 30 Prueba T11 Prueba de dos muestras Tipo de Prueba de suma de rangos de Wilcoxon prueba Alternativa ls(Poly. Program.@enermfg, Poly. Persist.@enermfg) Datos n1 = 11; n2 = 11 m1 = 2 ; m2 = 1 W = 87,5000 valor p 0.029442 Tipo de prueba Prueba de suma de rangos de Wilcoxon Prueba T12 Prueba de dos muestras Alternativa ls(Mantenibilidad@devcons, Escalabilidad@devcons) > 0 Datos n1 = 16; n2 = 16 m1 = 2 ; m2 = 2 W = 134 0,401466 valor p Prueba T13 Prueba de dos muestras Tipo de Prueba de suma de rangos de Wilcoxon prueba Alternativa ls(Attr. Employ.@heavyuser, Attr. Employ.@heavyuser) > 0 n1 = 19 ; n2 = 52 Datos m1 = 1 ; m2 = 1 W = 515,5000 valor p 0.383101 Tipo de Prueba de suma de rangos de Wilcoxon Prueba T14 Prueba de dos muestras prueba Alternativa ls(Poly. Persist.@finanzas, Poly. Persist.@finanzas) > 0 Datos n1 = 20 ; n2 = 51 m1 = 1 ; m2 = 1 W = 574 valor p 0.191551 B.3 Pruebas sobre la Pregunta 4 Prueba T15 Prueba de una muestra Tipo de prueba prueba de signos Media alternativa (Ops Skills) > 1 Datos np = 43; n = 70 valor p 0.036119 Machine Translated by Google Modelado empresarial y arquitecturas de sistemas de información vol. 14, núm. 1 (2019). DOI:10.18417/emisa.14.1 31 Prueba T16 Prueba de dos muestras Tipo de Prueba de suma de rangos de Wilcoxon prueba Alternativa ls(Copias de seguridad@finanzas, Copias de seguridad@finanzas) > 0 Datos n1 = 20 ; n2 = 51 m1 = 2 ; m2 = 1 W = 716 0,002539 valor p Prueba T17 Prueba de dos muestras Tipo de Prueba de suma de rangos de Wilcoxon prueba Alternativa ls(Cumplimiento@enermfg, Cumplimiento@enermfg) > 0 Datos n1 = 11 ; n2 = 60 m1 = 0 ; m2 = 1 W = 175,5000 0,005322 valor p Prueba T18 Prueba de dos muestras Tipo de Prueba de suma de rangos de Wilcoxon prueba Alternativa ls(Cumplimiento@devcons, Cumplimiento@devcons) > 0 Datos n1 = 16 ; n2 = 55 m1 = 1 ; m2 = 1 W = 483,5000 valor p 0.266709 Prueba T19 Prueba de dos muestras Tipo de prueba Prueba Wilcoxon de sumaAlternativa de rangos de ls(Cumplimiento@finanzas, Cumplimiento@finanzas) > 0 Datos n1 = 20 ; n2 = 51 m1 = 1,5; m2 = 1 W = 627,5000 0,059079 valor p B.4 Pruebas sobre la Pregunta 5 Prueba T20 Prueba de dos muestras Tipo de Prueba de suma de rangos de Wilcoxon prueba Alternativa ls(Aprovisionamiento@finanzas, Aprovisionamiento@finanzas) > 0 Datos n1 = 20 ; n2 = 51 m1 = 2 ; m2 = 1 W = 639 0,037406 valor p Machine Translated by Google Revista internacional de modelado conceptual vol. 14, núm. 1 (2019). DOI:10.18417/emisa.14.1 32 Prueba T21 Prueba de dos muestras Tipo de Prueba de suma de rangos de Wilcoxon prueba Alternativa ls(Aprovisionamiento@finanzas, Aprovisionamiento@devcons) > 0 Datos n1 = 20 ; n2 = 16 m1 = 2 ; m2 = 1 W = 240,5000 0,002504 valor p Prueba T22 Prueba de dos muestras Tipo de Prueba de suma de rangos de Wilcoxon prueba Alternativa ls(Poly. Program.@finance, Poly. Program.@finance) Datos n1 = 20; n2 = 51 m1 = 2 ; m2 = 0 W = 783,5000 valor p 0.000010 B.5 Pruebas sobre la Pregunta 9 Prueba T23 Prueba de dos muestras Tipo de prueba Prueba Wilcoxon de sumaAlternativa de rangos de ls (mantenibilidad, tiempo de comercialización) < 0 Datos n1 = 71 ; n2 = 71 m1 = 2 ; m2 = 2 W = 3057,5000 0,002817 valor p Prueba T24 Prueba de dos muestras Tipo de prueba Prueba de suma de rangos de Wilcoxon ls alternativos (nueva tecnología, CD / DevOps) < 0 Datos n1 = 71; n2 = 71 m1 = 1 ; m2 = 2 W = 1873 valor p 0.002166 Tipo de prueba Prueba de suma de rangos de Wilcoxon Prueba T25 Prueba de dos muestras Alternativa ls(Calidad@clientes potenciales, Calidad@clientes potenciales) > 0 Datos n1 = 11; n2 = 60 m1 = 2 ; m2 = 1 W = 436 0,030351 valor p Machine Translated by Google Modelado empresarial y arquitecturas de sistemas de información vol. 14, núm. 1 (2019). DOI:10.18417/emisa.14.1 33 Prueba T26 Prueba de dos muestras Tipo de prueba suma dePrueba rangosde de Wilcoxon Alternativa ls(CD / DevOps@leads, CD / DevOps@leads) > 0 Datos n1 = 11 ; n2 = 60 m1 = 2 ; m2 = 1 W = 428 0,042106 valor p C Tablas de correlación cruzada Las tablas de correlación cruzada de las Preguntas 3 a 5 y 9 se muestran a continuación. Persistencia políglota Habilitador para CD yDevOps 0,07 Programación políglota Alta mantenibilidad Corto tiempo de comercialización Alta escalabilidad yelasticidad Tabla 10: Tabla de correlación cruzada para la Pregunta 3 Idoneidad para Cloud yDocker 0,03 Mejora Organizacional Alta Mantenibilidad 0,04 0,01 — 0,07 0,11 0,18 0,04 0,33 0,10 Programación Políglota 0,21 -0,17 0,07 — 0,47 -0,06 -0,05 0,05 0,02 Persistencia Políglota 0,13 0,05 0,11 0,47 — -0,08 -0,04 0,05 0,11 Enabler para CD y DevOps -0,06 0,20 0,18 -0,06 -0,08 — 0,38 0,03 0,07 Idoneidad para Cloud y Docker 0,11 -0,13 0,04 -0,05 -0,04 0,38 — 0,08 0,15 0,05 Mejora Organizacional 0,08 — 0,28 -0,09 0,07 0,33 0,05 0,02 0,01 0,11 Atractivo como empleador 0,15 0,28 —0,10 0,02 Atractivo como empleador Alta Escalabilidad y Elasticidad — -0,13 0,04 0,21 0,13 -0,06 0,11 -0,09 0,02 Corto plazo de comercialización -0,13 — 0,01 -0,17 0,05 0,20 -0,13 0,07 0,01 Machine Translated by Google Revista internacional de modelado conceptual vol. 14, núm. 1 (2019). DOI:10.18417/emisa.14.1 34 Problemas de compatibilidad Copias de seguridad consistentes Madurez de la tecnología Cumplimiento yRegulaciones Soporte Contratos Licencias / Complejidad de implementación Resistencia por Ops Habilidades de operaciones insuficientes Habilidades de desarrollo insuficientes Resistencia por desarrolladores — 0,42 0,42 Resistencia por Devs 0,16 -0,04 -0,01 -0,20 0,11 0,02 -0,04 0,03 Habilidades de desarrollo insuficientes—0,23 0,11-0,08 0,16-0,03 0,11 — 0,20 0,13 0,07 -0,09 0,40-0,17 -0,04-0,01 0,23 Resistencia por Ops 0,13 -0,08 0,24 0,29 Habilidades de operaciones insuficientes 0,40 — 0,05 0,31 0,32 0,21 -0,07 -0,07 Soporte Contratos / Licencias -0,01 -0,08 0,13 0,05 — 0,30 0,16 0,13 0,28 0,07 Complejidad de implementación -0,20 -0,03 -0,08 0,31 0,30 — 0,31 0,12 0,18 0,09 Cumplimiento y Regulaciones 0,11 0,20 0,24 0,32 0,16 0,31 — 0,21 0,14 0,08 Madurez de la Tecnología 0,02 0,13 0,29 0,21 0,13 0,12 0,21 — 0,15 0,15 Copias de seguridad consistentes -0,04 0,07 -0,17 -0,07 0,28 0,18 0,14 0,15 — 0,05 Problemas de compatibilidad 0,03 -0,09 -0,01 -0,07 0,07 0,09 0,08 0,15 0,05 — Tabla 11: Tabla de correlación cruzada para la Pregunta 4 Infraestructura como código Automatización de pruebas Ejecución de aplicaciones distribuidas Cambio de tareas operaciones Tareas de operaciones por equipos de desarrollo Persistencia descentralizada Aprovisionamiento de recursos Construcción de tuberías — 0,39 0,12 -0,01 -0,29 -0,02 0,49 0,36 0,39 — 0,08 0,01 -0,07 -0,04 0,26 0,27 0 ,12 0,08 — 0,24 -0,09 0,09 0,17 0,06 Programación políglota Aprovisionamiento de recursos Estableciendo Monitoreo Construcción de tuberías 0,13 0,15 0,07 0,17 0,03 0,21 Persistencia descentralizada 0,09 0,14 -0,29 -0,07 Tareas de operaciones por equipos de desarrollo -0,01 0,01 0,24 — 0,32 0,00 -0,02 0,18 -0,09 0,32 — 0,08 -0,10 0,08 -0,04 0,07 0,08 — 0,04 -0,07 -0,10 0,19 0,17 -0,02 -0,10 0,04 — Cambio de tareas de operaciones 0,00 0,09 -0,01 0,22 0,06 0,08 -0,07 0,09 — 0,11 0,15 0,03 Ejecución de aplicaciones distribuidas -0,02 -0,04 0,09 Automatización de Pruebas 0,26 0,27 0,07 0,49 0,17 0,11 — 0,00 0,21 0,15 0,00 — Infraestructura como código 0,36 0,18 Programación políglota 0,13 0,09 -0,04 -0,10 -0,01 0,14 0,22 Estableciendo Monitoreo 0,15 0,07 0,19 Tabla 12: Tabla de correlación cruzada para la Pregunta 5 Machine Translated by Google Modelado empresarial y arquitecturas de sistemas de información vol. 14, núm. 1 (2019). DOI:10.18417/emisa.14.1 35 Copias de seguridad consistentes Cumplimiento yRegulaciones Madurez de la tecnología Soporte Contratos Licencias / Complejidad de implementación Resistencia por Ops Habilidades de operaciones insuficientes Habilidades de desarrollo insuficientes Resistencia por desarrolladores -0,02 0,07 0,11 -0,16 -0,08 -0,03 -0,07 -0,08 0,02 -0,04 -0,01 0,10 -0,11 -0 ,14 0,13 0,07 Aprovisionamiento de recursos -0,06 -0,09 0,01 0,01 -0,18 -0,09 -0,13 -0,22 -0,09 -0,09 -0,21 0,18 0,21 0,01 Problemas de compatibilidad Construcción de tuberías Persistencia descentralizada Tareas de operaciones por equipos de desarrollo -0,22 -0,05 0,10 0,27 0,29 0,26 0,05 0,20 0,31 0,31 Cambio de Tareas Ops -0,01 0,14 0,23 0,45 0,12 0,00 0,21 0,20 0,04 0,24 Ejecución de aplicaciones distribuidas -0,04 -0,06 0,29 0,17 0,02 0,12 0,18 -0,07 -0,02 -0,09 Automatización de Pruebas 0,05 0,13 0,16 0,01 -0,25 0,11 0,21 0,07 -0,07 0,05 -0,03 0,12 -0,07 -0,02 0 ,23 0,28 0,03 0,08 Infraestructura como código 0,08 0,02 0,12 0,02 -0,09 -0,14 0,26 -0,01 -0,02 0,02 0,05 0,49 0, 14 -0,05 0,14 -0,04 0,02 0,31 Programación políglota 0,10 Estableciendo Monitoreo 0,21 -0,05 0,19 Tabla 13: Tabla de correlación cruzada para las Preguntas 4 y 5 Introducir nueva tecnología Mejorar calidad Mejorar la mantenibilidad Mejore el tiempo de comercialización Mejorar la escalabilidad Mejorar Mantenibilidad 0,07 -0,18 — 0,42 -0,02 0,28 0,03 Mejorar Calidad -0,22 -0,10 0,42 — 0,21 0,28 0,05 Introducir nueva tecnología -0,01 0,20 -0,02 0,21 — 0,14 0,34 0,14 0,28 Preparar CD y DevOps 0,14 — 0,16 0,03 0,33 0,34 0,16 — 0,12 0,03 Mejorar la motivación del equipo 0,28 0,05 Tabla 14: Tabla de correlación cruzada para la Pregunta 9 Preparar CD yDevOps Mejorar el tiempo de comercialización -0,05 — -0,18 -0,10 0,20 0,03 0,33 Mejorar la motivación del equipo Mejorar escalabilidad — -0,05 0,07 -0,22 -0,01 0,14 0,12