Вы находитесь на странице: 1из 12

SéptimaConferenciadeDirectoresdeTecnologíadeInformación,TICAL2017Gestiónde

lasTICsparalaInvestigaciónylaColaboración,SanJosé,delXXalXXdejuliode2017

ArquitecturadeSoftwarebasadaenMicroserviciospara

DesarrollodeAplicacionesWeb

DanielLópez a ,EdgarMaya b

a AsambleaNacionaldelEcuador,CoordinaciónGeneraldeTecnologíasdelaInformación

yComunicación,Piedrahita5-21yAv.GranColombia,Pichincha,Ecuador

daniel.lopez@asambleanacional.gob.ec

b UniversidadTécnicadelNorte,InstitutodePosgrados,Av.17deJulio5-21Gral.José MaríaCordova,Imbabura,Ecuador eamaya@utn.edu.ec

Resumen. Actualmente, el proceso de desarrollo de software que realiza la Coordinación GeneraldeTecnologíasdelaInformaciónyComunicación(CGTIC)delaAsambleaNacional del Ecuador (ANE) constituye el empleo de una arquitectura de software tradicional o monolíticaquehasidoadoptadadellenguajedeprogramaciónutilizado,laplataformaodela experiencia del personal del área de desarrollo; por el aspecto monolítico, este tipo de aplicacionesempaquetantodalafuncionalidadenunasolaygranunidadejecutable(unsolo archivo o aplicación), lo que ha provocado dificultades en aspectos como mantenimiento, escalabilidad y entregas. El objetivo del presente estudio fue identificar las tecnologías, metodologíayarquitecturaqueutilizalaCGTICparaeldesarrollodeaplicacioneswebyla correspondienteidentificacióndelastecnologíasexistentesparaeldesarrolloeimplementación demicroservicios,utilizandocomobasedelainvestigaciónunenfoquecualitativo,conuntipo deinvestigacióndescriptivaydiseñodocumental.Seempleólatécnicadegrupofocalaplicado alosfuncionariosdeláreadedesarrollodesoftwaredelaCGTIC,revisiónbibliográficade arquitectura de microservicios. Como avance de la investigación, el análisis ha permitido identificar el estado del arte respecto a microservicios y su implementación así como la identificacióndelosrequisitosynecesidadesrelativosaldesarrollodeaplicacioneswebycomo satisfacerlasmedianteeldiseñodeunaarquitecturadesoftware.

PalabrasClave:Microservicios,arquitecturadesoftware,aplicacionesweb.

Ejetemático:Infraestructuraydesarrollodesoftware.

1Introducción

Enlaactualidad,anivelempresarialytantoenelsectorprivadocomopúblicose realiza desarrollo de software para suplir las necesidades de automatización de procesos internos, este desarrollo ha seguido las tendencias impuestas por la plataforma,lenguajedeprogramaciónoporlaexperienciadeláreadedesarrollo,lo cualdevieneenlaimplantacióndesistemasdeconstruccióntradicionalomonolítico.

El proceso de desarrollo de software que realiza la Coordinación General de TecnologíasdelaInformaciónyComunicación(CGTIC)delaAsambleaNacional delEcuador(ANE)constituyeelempleodeunaarquitecturadesoftwaremonolítica,

mismaquehasidoadoptadaporelusodeunlenguajedeprogramaciónespecífico paraconstruccióndeaplicacioneswebempresariales;porelaspectomonolítico,este tipodeaplicacionesempaquetantodalafuncionalidadenunasolaygranunidad ejecutable (un solo archivo o aplicación), lo que ha provocado dificultades en

aspectoscomomantenimiento,escalabilidadyentregas[1]

1.1Problema

Elpresentetrabajodeinvestigación,partedeunanálisisdelaproblemáticaexistente coneldesarrollodeaplicacioneswebdelaCGTIC,dichodesarrollohaceusodeuna arquitectura monolítica la cual incide en diferentes aspectos tanto tecnológicos y administrativos.Lasincidenciasmásevidentessepuedenobservaralaplicarprocesos demantenimientoen sistemas complejos,sea por unapetición decambio, nueva funcionalidadocorreccióndeunfallo,enloscuales,laresolucióndeunproblemao cambiosimpleimplicaelredesplieguedetodalaaplicacióndebidoaquesetiene todaslasfuncionalidadesenunúnicopaqueteincrementandolosriesgosdefallos.De igual forma, por el tiempo que toma la implementación de un cambio o nueva funcionalidad,sepresentaresistenciaalcambioenelusuariofinal,yenconsecuencia lasactualizacionessonmenosfrecuentesporquerequierendeunmayoresfuerzoy coordinacióndelosgruposdedesarrolloylarealizacióndepruebasmásextensas. Enaspectosdecalidad,surgencomplicacionesenlaescalabilidadyaquepuede requerirseescalarunmóduloespecífico,pero,porelaspectomonolíticoesnecesario escalarlaaplicaciónensutotalidad.Deigualmanerasucedeconlaresilencia,al ocurrirunfalloporcaídaosobrecargaenunapartedelaaplicación,sepierdentodas sus funcionalidades; si bien este último aspecto puede ser subsanado mediante replicación o clusters, también incrementa las dificultades de coordinación, configuraciónyelevaloscostosdeequipamientoyesfuerzo. Otra problemática a resaltar, es la incidencia que produce el mantenimiento aplicacionesenelnormaldesenvolvimientodelasactividadesdelosusuarios;eneste sentido,unadelasáreasmáscríticaseselPlenariodelaANE,elcualhaceusode softwarepararegistrarlasvotacionesdeloslegisladoresenlacreaciónoreformade leyesdeafectaciónnacional,porloqueresultadifícilcambiar,agregaroactualizarlo. Adicionalmente,algunosdelossistemasseencuentranimpedidosdeactualización queesdevitalimportanciaporsuniveldecriticidadyafectación,estosedebeuna vezmásporestarconstruidabajoelesquemamonolítico. Porlosaspectosdescritosseconcluyequeexistelanecesidaddedefinirunanueva arquitecturadesoftwareconunenfoquedevanguardiaquefaciliteeldesarrollode nuevasaplicacionesparalasdiferentesunidadesorganizacionalesdelaANE.Bajo esta nueva perspectiva, se pretende obtener arquitectura de software flexible que permitaelmantenimientodelasaplicacionesevitandolainterrupcióndeactividades delpersonalquelasusa.

2Antecedentes

En la Universidad de Aarhus de Dinamarca [2], evalúa diferentes tácticas de disponibilidadymantenibilidadenlaconstruccióndeunprototipoconarquitecturade microservicios,enelproceso,concluyeconunarevisióndelascaracterísticasdelos

microserviciosenunciadasporFowleryLewis[3]encuatrocriteriosprincipalesque

definenaunmicroservicio:

Enfoqueenlascapacidadesdenegocio.Elprocesodedesarrollodesoftwarese vuelve más flexible bajo el enfoque de microservicios, cada microservicio está compuestopor supropialógicadenegocios,interfazdeusuario,basededatosy funcionalidaddecomunicacióncon otros servicios, por lo tanto,en elequipo de desarrolloquecadamiembronecesitaexperienciaendesarrollodebackend,frontend, y bases de datos, permitiéndoles agregar nuevas características rápidamente sin arriesgarlaestabilidadyelfuncionamientodetodoelsistema.

Independenciadelosserviciosautónomos.Cadaserviciocontienesupropialógica de negocio y se despliega por separado. Esto hace posible cambiar y extender gradualmenteconnuevascaracterísticassinafectarelrestodelsistema.Lapropiedad autónomapermitelaflexibilidadenlaseleccióndelatecnologíamásadecuadapara unservicioespecífico.

Gestióndescentralizadadedatos.Todoslosserviciostienensupropiabasededatos en esquemas pequeños y simples, que se ven por separado. Los datos están desacoplados,loquerequieremuchagestiónypruebasparagarantizarqueunsistema nuncaactualiceoeliminelosdatosenunserviciosinactualizaroeliminarlosdatos correspondientesenotrosserviciosquecontienenlosmismosdatosoconjuntode referencias.

Toleranciaafallos.Lossistemasdemicroservicioconsistenenmúltiplesunidades

pequeñasquepuedenfallar;Estasunidadesestánligeramenteacopladasypuedenser

restauradasautomáticamente.loqueresultaenunsistemamásestableyrobusto.

PorsuparteBorčin[4]ensutrabajodeinvestigación,realizaunanálisisdelos

atributosdecalidaddelaarquitecturademicroserviciosprofundizandoenlosretosde

suimplementación:

Interfacesycomunicación.Cadamicroserviciodebeexponeralgunainterfase,para algunas tecnologías no equipadas con una especificación, esto puede representar seriosproblemasinclusoRESTqueesutilizadoenlaarquitecturademicroservicio paralacomunicaciónnotieneunainterfazbiendefinida.

Transacciones y bloqueos. Se necesita un conjunto completamente nuevo de operacionesparaunatransacciónquecompruebalacomunicacióndemicroservicios. se debe asegurar de que ningún microservicio utilice flujos cerrados o recursos bloqueadosyquenomodifiquelosdatosqueotrosserviciosestánutilizando.Estos bloqueospodríanprovocarlasuspensióndetodoelsistema.

Programación coreográfica. El paradigma de programación coreográfica puede ayudarenlacreacióndesistemaslibresdebloqueos,sinerroresdecomunicación.La programación coreográfica puede llegar a ser más importante con el desarrollo ulteriordelaarquitecturadelmicroservicio,yaqueproporcionanunterrenosólido paraunaformalizacióndelacomunicación.

Puntosdeentrada.Laseguridadesunproblemaimportantecuandosetratadela

arquitecturademicroserviciosylossistemasdistribuidosengeneral.Enaplicaciones

monolíticassepuedeasegurarfácilmentelaseguridaddetodalaaplicación,yaque

todalacomunicaciónpasaatravésdelospuntosdeentradaqueposeecadamódulo

quelocompone.Encontraste,enmicroservicios,garantizarlaseguridadsevuelve

muchomásdifícil.Todalaaplicaciónsecomponedeunmicroservicioindependiente

(lenguajeymáquina)queexponesusinterfacesyelnúcleodelaaplicaciónparala

comunicaciónexterior,proporcionandonuevospuntosdeentradaparalosintrusos.

Redcompleja.Unaextensareddecomunicaciónpuedeserfácilmenteexpuestaa ataques, ya que es difícil administrar cuando la aplicación consta de muchos microservicios y esos servicios envían miles de mensajes. El monitoreo de esta complejaredestambiénmuydifícil.

Concluyeque,laarquitecturademicroserviciostraeránuevosproblemasydesafíos

relacionadosnosóloconlacomunicaciónysuestructuradistribuida.Actualmente

sólosepuededecirquelosmicroserviciostodavíaestánenunaetapainicialyaúnes

desconocidoparamuchosdesarrolladores,peroestánganandomuchaatenciónyun

sitioenelmercado,especialmenteentreunamedianasypequeñasempresas.

2.1Microservicios

Es un enfoque para el desarrollo de una aplicación única como un conjunto de pequeñosservicios,cadaunoejecutándoseensupropioprocesoymecanismosligeros de comunicación, a menudo un recurso de una interfaz de programación de

aplicaciones (API) sobre protocolo de transferencia de hipertexto (HTTP). Estos servicios están construidos alrededor de las capacidades del negocio y con independenciadedespliegueeimplementacióntotalmenteautomatizada.Existeun mínimodegestióncentralizadadeestosservicios,losquepuedenestarescritosen lenguajes de programación diferentes y utilizar diferentes tecnologías de

almacenamientodedatos[3].

Eltérminomicroserviciosnoesrelativamentenuevo,esteestiloarquitecturalfue acuñado por Martin Fowler en un taller de arquitectos de software como una descripcióndelnuevocampoquelosparticipantesestabanexplorando.Noexisteuna definición en concretoparamicroservicio,sin embargo, unaaproximaciónque la

realiza[5]lodefinecomo:“Pequeñosserviciosautónomosquetrabajanjuntos”.

Una arquitectura de microservicios promueve el desarrollo y despliegue de

aplicacionescompuestasporunidadesindependientes,autónomas,modularesyauto-

contenidas,locualdifieredelaformatradicionalomonolítico[6].

Fig.1. PatrónbásicodearquitecturadeMicroservicios[7] Unadelas ventajas de utilizar microservicios es lacapacidadde

Fig.1.PatrónbásicodearquitecturadeMicroservicios[7]

Unadelas ventajas de utilizar microservicios es lacapacidadde publicaruna aplicacióngrandecomounconjuntodepequeñasaplicaciones(microservicios)quese puedendesarrollar,desplegar,escalar,manejaryvisualizardeformaindependiente. Losmicroserviciospermitenalasempresasgestionarlasaplicacionesdecódigobase grandeusandounametodologíamásprácticadondelasmejorasincrementalesson ejecutadasporpequeñosequiposenbasesdecódigoydesplieguesindependientes.La agilidad,reduccióndecostesylaescalabilidadgranular,traenalgunosretosdelos sistemasdistribuidosylasprácticasdegestióndelosequiposdedesarrolloquedeben

serconsiderados.[8]

serconsiderados.[8] Fig.1. Beneficiosdelosmicroservicios Topologías.

Fig.1.Beneficiosdelosmicroservicios

Topologías.SegúnRichards[7],existenmuchasmanerasdeimplementarunpatrón

dearquitecturademicroservicios,perosedestacantrestopologíasprincipalesqueson las más comunes y populares: basada en API REST (Transferencia de Estado RepresentacionaldelinglésRepresentationalStateTransfer),basadaenaplicaciones RESTylacentralizadademensajería.

o

TopologíabasadaenAPIRESTesútilparasitioswebqueexponenservicios individualespequeñosyautónomosatravésdealgúntipodeAPI.Constade componentesdeserviciodegranofino(deahíelnombremicroservicios)que contienen uno o dos módulos que realizan funciones empresariales específicasindependientesdelrestodelosservicios.Enestatopología,estos componentesdeserviciodegranofinoseaccedennormalmentemediante unainterfazbasadaenRESTimplementadaatravésdeunacapadeAPI basada en la Web desplegada separadamente. Algunos ejemplos de esta topologíaincluyenalgunosdelosservicioswebRESTbasadosenlanube comolosusadosporYahoo,GoogleyAmazon.

o

TopologíabasadaenaplicacionesRESTdifieredelenfoquebasadoenAPI RESTenquelassolicitudesdeclienteserecibenatravésdepantallasde aplicaciones empresariales tradicionales basadas en web o en clientes pesados(fat-client)enlugardeunasimplecapadeAPI.Lacapadeinterfaz deusuariodelaaplicaciónsedespliegacomounaaplicaciónwebseparada queaccede deforma remotaa componentes deservicio desplegados por separado(funcionalidadempresarial)atravésdesimplesinterfacesbasadas enREST.Otradiferenciaseencuentraenqueloscomponentesdeservicio tiendenasermásgrandes,degranomásgruesoyrepresentanunapequeña porción de la aplicación empresarial general en lugar de granos finos, serviciosdeacciónsimple.Estatopologíaescomúnparalasaplicaciones empresarialespequeñasymedianasquetienenungradorelativamentebajo decomplejidad.

o

Latopologíademensajeríacentralizada,essimilaralabasadaenREST, excepto que en lugar de usar REST para acceso remoto, esta utilizaun intermediario de mensajes centralizado ligero (por ejemplo, ActiveMQ, HornetQ,etc.).Esimportanteconsiderarquenosedebeconfundirconel patrónSOAoconsiderarlo"SOA-Lite".Elagentedemensajesligerosquese encuentraenestatopologíanorealizaningunaorquestación,transformación oenrutamientocomplejo,es sólountransporteligeroparaacceder alos componentes de servicio remotos. Esta topología se encuentra frecuentementeenaplicacionesdenegociosmásgrandesoaplicacionesque requieren uncontrol mássofisticado sobrelacapa detransporteentrela interfazdeusuarioyloscomponentesdeservicio.Entrelosbeneficiosque aportafrentealasanterioresesquesonmecanismosavanzadosdecolas, mensajeríaasíncrona,monitoreo, manejo de errores y mejor balanceo de cargayescalabilidad.Elúnicopuntodefalloylosproblemasdecuellode botella arquitectónico generalmente asociados con un intermediario centralizadoseabordanatravésdelaagrupacióndeintermediariosydela federacióndeintermediarios(dividirunaúnicainstanciadeintermediarioen múltiplesinstanciasdeintermediarioparadividirlacargadeprocesamiento demensajesenfuncióndelasáreasfuncionalesdelsistema).

Aplicaciónmonolítica.Enunaaplicaciónmonolíticatodalalógicaseejecutaenun únicoservidordeaplicaciones.Lasaplicacionesmonolíticastípicassongrandesy construidas por múltiples equipos, requiriendo una orquestación cuidadosa del despliegueparacadacambio.Tambiénseconsideranaplicacionesmonolíticascuando

existenmúltiplesserviciosdeAPIqueproporcionanlalógicadenegocio,todalacapa

depresentaciónesunasolaaplicaciónwebgrande.Enamboscasos,laarquitecturade

microserviciospuedeproporcionarunaalternativa.

Tabla1.Arquitecturasmonolíticasvs.microservicios[9]

Categoría

ArquitecturaMonolítica

Arquitecturade

microservicios

Código

Unabasedecódigoúnica

Múltiplesbasesdecódigo.Cada

paratodalaaplicación.

microserviciotienesupropia

basedecódigo.

Comprensibilidad

Amenudoconfusoydifícil

Mayorfacilidaddelecturay

demantener.

muchomásfácildemantener.

Despliegue

Implementaciones

Desplieguesencilloyaquecada

complejasconventanasde

microserviciosepuede

mantenimientoyparadas

implementardeforma

programadas.

individual,conuntiempode

inactividadmínimo,sinoes

cero.

Lenguaje

Típicamentetotalmente

Cadamicroserviciopuede

desarrolladoenunlenguaje

desarrollarseenunlenguajede

deprogramación.

programacióndiferente.

Escalamiento

Requiereescalarla

Cadamicroserviciopuede

aplicaciónentera,aunque

desarrollarseenunlenguajede

loscuellosdebotellaestén

programacióndiferente.

localizados.

2.2Serviciosweb.

LosserviciosWebsoncomponentesdesoftwareligeramenteacopladosentregadosa través de tecnologías estándar de Internet. Es decir, los servicios Web son aplicaciones de negocio autodescriptivas y modulares que exponen la lógica empresarialcomoserviciosatravésdeInternetatravésdelainterfazprogramabley dondeelprotocolodeInternet(IP)puedeserutilizadoparaencontrareinvocaresos servicios. Un servicio web es el elemento clave en la integración de diferentes sistemas de información, ya que los sistemas de información pueden basarse en

diferentesplataformas,lenguajesdeprogramaciónytecnologías[10].

SOAP.Laimplementacióndeservicioswebporprotocolosimpledeaccesoaobjetos (SOAP)sedesarrollócomounaalternativaalestándarCORBA (CommonObject RequestBroker Architecture).Paragarantizareltransportededatos enSOAP,se utilizan protocolos como HTTP, SMTP, entre otros, en formato XML. En este enfoque,unproveedordeserviciospublicaunadescripcióndelservicioounainterfaz

paraelregistrodeservicios,porloqueelsolicitantedelserviciopuedeencontraruna instancia de servicio correcta y utilizarla. Algunos problemas de rendimiento en SOAP se producen al formar el mensaje SOAP ya que agrega un encabezado adicionalypartesalcuerpoalmensaje.LosserviciosWebbasadosenSOAPincluyen una variedad de estándares, tales como WSDL, WSBPEL, WS-Security, WS- AddressingEstasnormasfuerondesarrolladaspororganizacionesdenormalización,

comoW3CyOASIS[11]

REST.UnservicioRESTsedefinecomounaagregacióndediferentesrecursosque puedenseralcanzadosdesdeunidentificadoruniversalderecurso(URI)base.Un recursorepresentaaunaentidaddelmundorealcuyoestadoestáexpuestoypuede cambiarse accediendo a un URI. Una Representación es la descripción de los mensajesenviadosorecibidosdeunRecursoentérminosdeunlenguajetecnológico. Actualmente XML y JSON son los idiomas más populares para describir estos

mensajes[12]

2.3Integracióncontinua

Laintegracióncontinua(CI)esunaprácticaeneldesarrollodesoftwareenlaquelos desarrolladores hacenintegraciones automáticas deunproyectolomás amenudo posible(generalmenteadiario)conelpropósitodedetectarfallosloantesposible. Estaprácticadeintegracióncomprendelacompilaciónyejecucióndepruebasdetodo unproyecto. Prácticasdeintegracióncontinua.ParalaaplicacióndeprácticasdeCIserequiere quecadavezqueseagregueunanuevapartealsistema,tambiénsecreencasosde pruebaautomáticosparacubrirtodoelsistemaincluyendolaspartesreciénagregadas. De igual forma, se requiere que el software sea probado y construido automáticamente y una retroalimentación inmediata sobre los nuevos códigos

integradoshacialosdesarrolladores.DeacuerdoconHamdanyAlramouni[13],estas

prácticasson:

o

Integrarelcódigoconfrecuencia.Estenúcleodelaintegracióncontinua.No sedebeesperarmásdeundíaparaenviarcódigoalrepositoriodecódigo compartido.

o

Nointegrarcódigo“roto”.Códigorotoesuncódigoquecontienecualquier tipodeerrorcuandoseincluyeenunaconstruccióndeCI.

o

Corregirlascompilacionesnofuncionalesdeinmediato.Unacompilaciónno funcionalpuedeserunerrorenlacompilación,enlabasededatosoenla implementación. Es cualquier cosa que impide que la compilación de informesdeéxito.

o

Escribirpruebasautomatizadas.Laspruebasdebenserautomatizadaspara quefuncionenen unsistemadeCI.Tambiéndebecubrirtodoelcódigo fuente.

o

Todaslaspruebaseinspeccionesdebenaprobarse.Paraqueunacompilación

seapruebe,el100%delaspruebasautomatizadasdebenpasarconéxito.

EsteeselcriteriomásimportantedeCIencuantoalacalidaddelsoftware.

o Ejecutar compilaciones privadas. Las herramientas de CI permiten a los desarrolladores tener una copia del software del repositorio de código compartidolocalmenteensusestacionesdetrabajo.Estolesproporcionala capacidaddetenerunacompilacióndeintegraciónrecientelocalmenteantes deintegrarlaalservidordegeneracióndeintegraciónprincipalparaasegurar quenofalle.

2.4Contenedordeaplicaciones

Uncontenedordeaplicacionessebasaenlavirtualizacióndesistemasoperativos usandolos contenedores Linux [14],precisamentees unmotor decontenedor de código abierto, que automatiza el empacado, entrega y despliegue de cualquier aplicación de software, se presenta como contenedores livianos, portátiles y autosuficientes,queseejecutaránprácticamenteencualquierlugar.Uncontenedores uncubodesoftwarequecomprendetodolonecesarioparaejecutarelsoftwarede formaindependiente.Puedehabervarios contenedoresen unasolamáquinaylos contenedores están completamente aislados entre sí y también de la máquina

anfitriona[15]

Lapalabracontenedorsedefinecomo"unobjetoparacontener/resguardaroel transportedealgo".Laideadetrásdeloscontenedoresde"software"essimilar.Son imágenes aisladas e inmutables que proporcionan funcionalidad diseñada en la mayoríadeloscasosparaseraccesiblessóloatravésdesusAPIs.Esunasolución parahacerqueelsoftwarefuncionedeformafiableyen(casi)cualquierentorno.No importadóndeseesténejecutando(computadorportátil,servidordepruebas ode

producción,centrodedatos,etc.),elresultadosiempredebeserelmismo[16].

3Metodología

Comobasedelainvestigaciónseusóunenfoquecualitativoquepermitiódescubriro afinar las preguntas de investigación sobre las necesidades del diseño de una

arquitecturadesoftware.Seaplicauntipodeinvestigacióndescriptiva[17]parala

contextualizaciónydescripcióndelentornodeaplicacióndeunaarquitecturaenel

desarrollodeaplicacionesweb.Eldiseñodocumental[18]utilizadoparalarevisión

bibliográfica sobrearquitecturade microservicios. Se empleó la técnica degrupo

focal[19]aplicadoalosfuncionariosdeláreadedesarrollodesoftwaredelaCGTIC

paradeterminarelestadodesituaciónactualsobreprocesodesoftwareaplicado.

3.1AnálisisCualitativo

Recolección de datos. El instrumento de reunión de expertos fue desarrollado tomando en cuenta los antecedentes del entorno, tales como: Tecnología en uso, documentacióndisponible,experienciadelpersonal.

Lareunióndeexpertostuvodosenfoquesprincipales:

o

Desarrollodeaplicaciones

o

Arquitecturadesoftware

Por cada pregunta se definió posibles respuestas esperadas como guía del conductordeacuerdosuámbitorelacionado.

Resultados.Conrespectoaldesarrollodesoftwareyconbaseenlainformación

recolectadadelaaplicacióndelinstrumentodeinvestigaciónseconcluyeque:

Elprocesodedesarrollodesoftwareutilizaunametodologíaágildebidoalcarácter cambiantedelossistemasenejecución,estasasuvez,constituyenensumayoríalos orientadosalaweb,conunaclaratendenciaaldesarrolloenentornosmóviles.Existe unusomayoritariodeaplicacionesanivelinternoconaltacriticidadmismasqueno cuentan con servicios alternativos en presencia de fallos o eventos fortuitos que permitanlacontinuidaddelservicio. Elproductodesoftwarequesegeneracarecedeprincipiosdemodularidaddebido alusodelaarquitecturaimplícitadelaplataformadedesarrolloutilizada.Como resultadolasaplicacionesadquierenuncaráctermonolíticoembebiendoenunasola unidadejecutabletodassusfuncionalidadesloqueincidetantoensudesarrollocomo mantenimiento. Enconsecuenciaybajoelcriteriounificadoobtenido,seconcluyequeesdealta importanciaemplearunaarquitecturadesoftwareparaeldesarrollodesoftwareque permitaunaestandarización delas aplicaciones ybrinde unamejor calidad alos productosdesoftware.

3.2Procesodearquitecturadesoftware

Elprocesodediseñodelaarquitecturaesunaextensióndelprocesogeneraldediseño deingeniería.Eldiseño de laarquitecturase centraen ladescomposición deun sistemaencomponentesylasinteraccionesentreloscomponentesparasatisfacerlos requisitosfuncionalesynofuncionales.Unsistemadesoftwarepuedeservistocomo unajerarquíadelasdecisionesdediseño(reglastambiénllamadodiseñoocontratos). Cadaniveldelajerarquíatieneunconjuntodereglasdediseñoquedealgunamanera seuneoconectaloscomponentesenesenivel.Lasalidaprincipaldelprocesode diseñodelaarquitecturaesunadescripciónarquitectónica.Elprocesodescribelos

siguientespasosgenerales[20]:

o

Elestablecimientoderequisitos,medianteelanálisisdeloscontroladoresdel negocio, el contexto del sistema, y los factores que los interesados del sistemaestimencríticoparaeléxito.

o

La definición de una arquitectura, mediante el desarrollo de estructuras arquitectónicasyestrategiasdecoordinaciónquesatisfaganlosrequisitos.

o

Laevaluacióndelaarquitectura,medianteladeterminacióndecuándoyqué métodosdeevaluacióndelaarquitecturasonapropiados,larealizaciónde lasevaluaciones,ylaaplicacióndelosresultadosparamejorareldesarrollo delaarquitectura.

o

Ladocumentacióndelaarquitectura,conelsuficientedetalleyenunaforma fácilmenteaccesibleparalosdesarrolladoresyotraspartesinteresadas.

o

Elanálisisdelaarquitectura,paraelrendimientodelsistema,laseguridad.

o

Implementación,delaarquitecturadefinidaatravés deldesarrollodeun prototipo.

4Resultados

Lainvestigaciónseencuentraenetapadedesarrollodelapropuestayposteriormente su aplicación mediante la implementación de un prototipo bajo la arquitectura propuestaquedemuestresuuso,porloqueaúnnosehaobtenidoresultados.

5Conclusiones

o

Elactualdesarrollodesoftwarebajolametodologíaaplicadasecontraponea laarquitecturautilizada,locualdificultasucorrectaaplicación.

o

El mantenimiento o cambio en las funcionalidades de las aplicaciones representaunproblemadebidoasunaturalezamonolítica.

o

Existeunaclaraintencióndeestablecerunanuevaarquitecturadedesarrollo deaplicacionesacordealautilizacióndenuevastecnologías.

Agradecimientos

Este trabajo forma parte de la Tesis Arquitectura de Software Basada en MicroserviciosparaDesarrollodeAplicacionesWebdelaAsambleaNacional.

Referencias

1.Carneiro,C.;Schmelmer,T.:MicroservicesFromDayOne.Apress.Berkeley,CA.(2016).

2.Nielsen,D.Investigateavailabilityandmaintainabilitywithinamicroservicearchitecture

(TesisDoctoral).Master’sthesis,AarhusUniversity.(2015).

3.Fowler,M.;Lewis,J.Microservices.Viittattu,(2014)

4.BorčinT.ServiceactivitymonitoringforSilverWare.MasarykUniversity.(2017)

5.Newman,S.BuildingMicroservices.O’ReillyMedia,Inc.(2015).

6.Wolff,E.Microservices:FlexibleSoftwareArchitectures.CreateSpaceIndependent

PublishingPlatform.(2016).

7.Richards,M.SoftwareArchitecturePatterns.O’ReillyMedia,Inc.(2015).

8.Villamizar,M.,Garces,O.,Castro,H.,Verano,M.,Salamanca,L.,Casallas,R.,yGil,S.

Evaluating the monolithic and the microservice architecture pattern to deploy web

applicationsinthecloud.ComputingColombianConference(10CCC),201510th(pp.583–

590).(2015).

9. Daya, S., Van Duy, N., Eati, K., Ferreira, C., Glozic D., Gucer, V., Vennam R.

MicroservicesfronTheorytoPracticeIBMCorporation.(2015).

10. Wagh, K., Thool, R. A comparative study of soap vs rest web services provisioning

techniquesformobilehost.JournalofInformationEngineeringandApplications,2(5),12–

16.(2012).

11.Tihomirovs, J.,Grabis, J.Comparison ofSOAP andREST Based WebServices Using Software Evaluation Metrics. Information Technology and Management Science, 19(1).

(2016)

12.Valverde,F., Pastor, O.Dealing with REST services in model-driven web engineering methods. VJornadas Científico -Técnicas en Servicios Web y SOA, JSWEB, 243–250.

(2009).

13.Hamdan,S.,Alramouni, S. AQuality Framework forSoftware Continuous Integration.

ProcediaManufacturing,3.(2015).

14.Kratzke,N.Aboutmicroservices,containersandtheirunderestimatedimpactonnetwork

performance.ProceedingsofCloudComputing,2015,165–169.(2015).

15.Raj,P.,Chelladhurai,J.S.,Singh,V.LearningDocker:OptimizethepowerofDockerto

runyourapplicationsquicklyandeasily.BirminghamMumbai:PacktPublishing.(2015).

16.Farcic,V.,TheDevOps2.0Toolkit.packtpub.(2016).

17.HernándezSampieri,R.,FernándezCollado,C.,&BaptistaLucio,P Metodologíadela

investigación.5taEdiciónLaHabana:EditorialFélixVarela,2.(2010)

18.Galeano, M. E. Diseño de proyectos en la investigación cualitativa. Universidad Eafit.

(2004).

19.Álvarez-Gayou,J.L.Cómohacerinvestigacióncualitativa.Fundamentosymetodología.

ColecciónPaidósEducador.México:PaidósMexicana.(2003).

20.Babar,M.,Brown,A.,Mistrík,I.,AgileSoftwareArchitecture:AligningAgileProcesses

andSoftwareArchitectures.Newnes,(2013).