Drivers and Barriers for Microservice Adoption

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