Índice analítico[Ocultar][Mostrar]
Os deseños arquitectónicos no pasado eran moitas veces monolíticos e carecían de xestión, escalabilidade e axilidade. Nesta situación, as empresas deberían implementar o programa completo nun servidor de aplicacións solitario que opera nun ordenador solitario.
Ás veces, toda a base de datos pode incluso estar instalada no mesmo sistema. Mesmo despois de realizar todo isto, un problema simplemente provocaría o peche do programa, interrompendo todas as actividades.
O resultado foi un ciclo interminable de codificación, implantación e solución de problemas que diminuíu a produtividade das empresas.
Pero cando as ideas arquitectónicas cambiaron, a industria experimentou un dramático trastorno que deu lugar ás dúas arquitecturas principais coñecidas como sen servidor e microservizos. Ambos teñen un caso forte para ser usados en sistemas escalables e áxiles.
Ambos priorizan a seguridade, pero adoptan enfoques diferentes. Os propietarios de empresas adoitan preguntarse se son ou non iguais.
Cal se debe escoller se son diferentes para obter beneficios aínda máis sorprendentes? Este artigo axudaranos a descubrilo.
Que son os microservizos?
O patrón de deseño arquitectónico coñecido como microservizos divide unha aplicación máis grande nunha serie de outras máis pequenas, polo que o nome. O deseño monolítico, no que toda a funcionalidade está contida nunha única unidade, é completamente oposto a isto.
Usemos un exemplo de aplicación para facer compras en liña para axudarnos a comprender. Despois de atopar o(s) artigo(s) que quere, o consumidor engádeos ao seu carro da compra e fai o seu pedido.
As interfaces de programación de aplicacións (API) conectan varios servizos que funcionan de forma independente uns dos outros (API). Os microservizos ofrecen funcións como cesta da compra, proceso de pago e produto.
A implementación de microservizos pódese facer de varios métodos. Cada microservizo ten os compoñentes fundamentais que necesita para funcionar de forma independente, incluíndo a súa propia base de datos, bibliotecas e modelos.
Esencialmente, adhírese aos principios SOA (Service Oriented Architecture), que proporcionan ao usuario o poder de construír novas aplicacións e executar diferentes aplicacións de forma independente.
DevOps separa todas as funcións da aplicación en aplicacións ou servizos máis pequenos que poden funcionar por si só mentres seguen funcionando como a aplicación no seu conxunto. Antes de implantarse, cada unha destas aplicacións de microservizos créase e probárase funcionalmente.
Que é un modelo sen servidor?
Nun paradigma sen servidor, o provedor externo de servizos na nube é o encargado de xestionar o servidor. Os desenvolvedores só teñen que preocuparse polo código; o provedor de servizos encargarase das actualizacións de seguranza, balance de carga, xestión da capacidade, escalabilidade, rexistro e seguimento.
Toda a aplicación pódese executar usando arquitectura sen servidor ou só un subconxunto dela. Tan pronto como se executa o código da aplicación, o servidor atribúelle recursos e liberaos unha vez que a aplicación xa non está en uso, polo que só se require cando a aplicación se está a utilizar activamente.
O propietario da aplicación só cobra durante o tempo que a aplicación estea en uso. As empresas de servizos na nube ofrecen Backend como servizo (BaaS) e Función como servizo (FaaS).
BaaS ofrece funcións predefinidas polo que o programador só ten que concentrarse no front-end. Raramente se usa debido á limitada personalización e control que ofrece.
FaaS, con todo, é máis flexible xa que os desenvolvedores poden crear tanto a fronte como a traseira mentres seguen executando a aplicación nun servidor distante. Con FaaS, pódese crear unha aplicación como unha colección de funcións.
Cada función ten un propósito e un factor iniciador. A función non pode funcionar continuamente; normalmente é temporal e finaliza en canto xa non é necesario.
Sen servidor vs microservizos
Un programa descentralizado que se dividiu en varios compoñentes máis pequenos, tamén coñecidos como servizos, denomínase arquitectura de microservizos. Todos eles son responsables de garantir que unha tarefa específica se realiza á perfección.
Os microservizos son moi especializados e só poden facer unha cousa sen problemas. Cada arquitectura ten unha estratexia diferente para resolver problemas. As correccións a longo prazo están dispoñibles cos microservizos.
Cada servizo pode funcionar de forma continua e 24/7. É unha excelente resposta a longo prazo para os equipos que están a escalar.
Por outra banda, as funcións das aplicacións sen servidor están enfocadas a mellorar a eficiencia do código. As funcións non duran tanto como os microservizos. Só comezan a funcionar en resposta a unha determinada entrada ou situación.
Dado que a arquitectura sen servidor está dirixida por eventos, unha función non se executará se non hai un disparador. O programa non usa máis CPU da necesaria e os equipos poden aforrar cartos en computación e espazo de almacenamento grazas a esta metodoloxía de desenvolvemento eficaz.
Ademais destas variacións básicas, os dous deseños tamén difiren doutros aspectos.
Centrémonos nalgunhas consideracións fundamentais ao decidir se usar microservizos ou computación sen servidor.
Funcións
As funcións son transitorias e só se executan cando unha determinada situación o require. Son máis compactos e delgados.
Un microservizo pode xestionar varias operacións vinculadas á vez, mentres que unha función é a única responsable dunha actividade.
Un único microservizo pode realizar varias funcións.
Tempo de execución
As funcións sen servidor teñen un tempo de execución curto. A cantidade que pode executar unha determinada función varía segundo o provedor.
Por exemplo, unha función pode executarse en AWS Lambda durante 15 minutos. Isto débese ao feito de que as funcións son, por natureza, procedementos breves que non deberían consumir moita memoria RAM.
As especificacións do provedor para o tempo de execución, o almacenamento e a RAM non son unha restrición para os microservizos. Debido a isto, son máis axeitados para actividades complicadas e a longo prazo que requiren almacenar e procesar grandes volumes de datos.
Operacións informáticas
A creación de recursos do equipo é necesaria para os microservizos. As tarefas de vixilancia, despregamento, soporte e mantemento son realizadas por un equipo interno ou externo. O equipo encárgase totalmente de apoiar a arquitectura, manexar a súa computación e garantir a súa seguridade.
Pola contra, a arquitectura sen servidor depende dun provedor de terceiros. A empresa non está obrigada a crear, protexer e xestionar o seu propio espazo de servidor. Todas as funcións internas son xestionadas polo provedor da nube.
Esta estratexia pode diminuír os custos do proxecto ao mesmo tempo que evita as taxas de contratación e incorporación, os gastos de almacenamento e as compras de hardware.
Custa
O custo inicial de crear microservizos é maior. Para completar o proxecto son necesarios varios equipos, e é necesario tempo e unha preparación coidadosa establecer as relacións entre os distintos compoñentes.
A creación e o mantemento dos microservizos son máis caros debido á súa dependencia dos recursos internos e da asistencia.
Non obstante, esta estratexia ten beneficios. A empresa non depende de plans externos e non corre o perigo do bloqueo do provedor.
A capacidade de reducir gastos é a principal vantaxe competitiva da arquitectura sen servidor. As empresas que empregan arquitectura sen servidor gañan ao agrupar recursos.
Como comparten os seus servidores entre varios clientes, os provedores de terceiros poden ofrecer prezos de subscrición máis baixos.
Ademais, está a aforrar custos de recursos humanos porque non precisa contratar coñecementos de hardware e servidor.
Cando se debe usar microservizos fronte á arquitectura sen servidor
Os microservizos son a mellor opción se a confidencialidade é a túa principal prioridade
Os servizos de arquitectura sen servidor poden non ser a opción ideal se estás intercambiando información. A aplicación pode ter algúns problemas graves.
Unha forma de hospedaxe xestionada ou compartida é a hospedaxe na nube.
Polo tanto, poderás observar que non es a única persoa que utiliza os recursos dun provedor de terceiros. Debido a que esta circunstancia implica "inquilinos múltiples" en lugar de "inquilinos únicos", os teus datos non están completamente protexidos neste caso.
A información e os datos doutro inquilino son visibles e accesibles para un inquilino. Ademais, é pouco probable que consumas continuamente recursos dun único provedor. Pode haber un gran número.
Así, a capacidade de supervisar e configurar todo o proceso será máis difícil a medida que cambie o provedor.
Utiliza microservizos se queres que o teu legado perdure.
Os servizos de arquitectura sen servidor non funcionarán se a infraestrutura do sistema antigo precisa estar instalada polo momento.
A velocidade e o custo son dous aspectos da arquitectura sen servidor que funcionan ben, pero non son os únicos.
Aínda que sen servidor é bastante granular, é incompatible cunha base de código importante e existente debido a esta granularidade.
Noutras palabras, é un salto demasiado grande para dar unha vez que tes un sistema heredado. Polo tanto, é preferible escoller unha estratexia de Microservizos.
Se es unha startup, elixir sen servidor é o camiño a seguir.
A mellor opción para a arquitectura sen servidor é se es o fundador da startup. A arquitectura sen servidor ofreceralle as velocidades máis rápidas e rápidas de lanzamento ao mercado, independentemente do seu obxectivo: responder a un mercado de tempo limitado ou conseguir inmediatamente unha cota de mercado ao comezo de calquera tendencia.
Ademais, será unha opción asequible para os emprendedores. Un servidor que non estea en uso non che custará nada. A falta de estatísticas de uso fiables, moitas veces necesitas aplicacións extremadamente adaptables.
Os microservizos e sen servidor deberían usarse se comezas desde cero
Facer un novo comezo permítelle obter os beneficios dos provedores de arquitectura sen servidor máis rapidamente, pero non de inmediato. Use microservizos ao deseñar unha arquitectura nova pero prepárese para cambiar a sen servidor máis tarde.
Arquitectura sen servidor vs microservizos: pros e contras
Por desgraza, ningunha tecnoloxía é perfecta; se o fose, o mundo xa sería un lugar contento e moi desenvolvido.
Cada tecnoloxía inclúe beneficios que podes usar para o teu proxecto, así como inconvenientes cos que debes estar preparado para vivir. Examinemos os dous agora.
Pros dos microservizos
- Escalado máis sinxelo: xa que os servizos están separados, é posible engadir ou eliminar funcións e escalar cousas coa menor cantidade de traballo. A diferenza dos programas monolíticos, non tes que considerar a base de código completa.
- Mellor resiliencia do software: debido a que os microservizos dependen menos uns dos outros, a falla dun non derrumba toda a aplicación. É especialmente útil cando o tráfico é intenso.
- Diferentes plataformas: pódense vincular microservizos situados en varias plataformas, ademais de facelo con idiomas. Unha parte dunha aplicación tamén se pode aloxar normalmente e sen servidor.
- Autonomía do equipo: varios equipos pequenos poden interactuar e traballar no proxecto simultaneamente
- Multilingüe: unha API permítelle vincular microservizos escritos en varios idiomas. É unha vantaxe útil porque varias tecnoloxías responden de forma máis eficaz ás diversas demandas dunha función. Non obstante, usar demasiados idiomas pode provocar dificultades para vincular todo, polo que é preferible manter as cousas sinxelas.
- Espazo para experimentos: a pesar da nosa riqueza de datos, as nosas suposicións ás veces son incorrectas e os microservizos permítenche probar todo. Dado que as aplicacións con microservizos son incriblemente adaptables, como comentamos anteriormente, non hai que gastar miles de dólares só para engadir unha nova función que quizais queiras eliminar máis tarde.
Contras dos microservizos
- Problemas de seguranza: debes supervisar atentamente as túas API porque a miúdo están configuradas incorrectamente e, polo tanto, susceptibles.
- Retos de conexión: debes deseñar coidadosamente como ligar todos os microservizos e mover os datos dunha localización a outra.
- A depuración é un reto xa que tes que examinar os rexistros de cada microservizo.
- Probas difíciles: debes probar cada microservizo por separado antes de avaliar a conexión a escala global.
Pros de Serverless
- Escalado sen esforzo: o servidor axústase automaticamente cara arriba ou cara abaixo.
- Implementación moi rápida: podes deseñar rapidamente novas funcións e probar as túas ideas.
- A administración do servidor non é a túa preocupación: podes concentrarte na aplicación e non no servidor.
- Pay-as-you-go: só paga pola capacidade do servidor que usa; non hai que pagar por tempo inactivo.
Contras de Serverless
- Probas difíciles: aínda que non pode reproducir completamente o ambiente sen servidor, é difícil entender como funcionará o código despois de que estea implantado.
- Baixa flexibilidade: moitas persoas teñen problemas para comprometerse cun único provedor de ambiente sen servidor durante un período prolongado.
- Arranque en frío: permanece almacenado na caché, pero só brevemente, unha vez que se completa cada función. A función terá que responder de novo á solicitude de invocación, o que leva tempo se a inicia de novo e non se almacena na memoria caché.
Conclusión
Os microservizos e sen servidor son tecnoloxías relacionadas coa arquitectura que usan diversas técnicas. Tanto os sen servidor como os microservizos enfatizan a escalabilidade, a adaptabilidade, a rendibilidade e a sinxeleza de engadir novas funcións en oposición ao deseño monolítico.
Dado que cada servizo funciona como unha aplicación independente, a escalabilidade a longo prazo é o obxectivo principal dos microservizos.
Dependendo do alcance do produto e das prioridades da organización, pódese seleccionar entre as dúas estratexias.
Os microservizos ofreceranche microservizos sen servidor para solucións a longo prazo se pretendes construír unha gran plataforma que necesite un crecemento continuo.
A arquitectura sen servidor é unha opción fantástica se queres implementar de forma rápida e económica.
Deixe unha resposta