A arquitetura serverless (arquitetura sem servidor) desafia o status quo do design de software e os fundamentos de implementação por alcançar um ótimo nível de desenvolvimento, operação e gerenciamento. Embora herde conceitos elementares da Microservices Architecture (MSA), é dotada de padrões arquitetônicos de ponta para atingir o nível mínimo possível de hardware ocioso.
Apesar dos notáveis avanços que ela representa, a adaptação carece de um processo minucioso para mapear com precisão os requisitos da solução corporativa aplicados à computação sem servidor.
As implementações iniciais de sistemas de software, executadas em servidores físicos, não poderiam utilizar otimamente a potência de computação do hardware subjacente, uma vez que só poderia haver uma instância do sistema operacional em execução em um determinado momento. Posteriormente, após identificar as capacidades de compartilhamento de tempo em recursos de computação, vários computadores virtuais foram capazes de executar o mesmo hardware ao mesmo tempo, ao trocar operações de CPU e I/O entre eles.
Esta evolução tecnológica levou a muitas inovações na indústria e, ainda mais importante, ao surgimento da computação em nuvem. Nesse momento, as máquinas virtuais eram as unidades mais gerenciáveis, escaláveis e programáveis de ambientes de computação isolados para a implementação de software. A tecnologia de container Linux surgiu por volta do ano de 2006, quando o Google implementou grupos de controle de acordo com os recursos do kernel Linux.
Os containers Linux estão lá desde então. No entanto, apenas grandes empresas como o Google foram capazes de usá-los em escala. Por volta do ano de 2012, o conceito de arquitetura de microserviços foi introduzido por um grupo de arquitetos de software na Europa. Mais tarde, no ano de 2013, o Docker preenchia incisivamente as lacunas de acessibilidade, usabilidade e serviços de apoio no ecossistema de containers e, consequentemente, os containers começaram a se popularizar.
Os containers Linux abriram um novo horizonte para a decomposição de grandes sistemas monolíticos em serviços individuais e auto-gerenciáveis, e sua execução com utilização de recursos finos. Para acelerar esses avanços, os sistemas de gerenciamento de clusters de containers como Kubernetes e Mesosphere começaram a aumentar no mesmo período para fornecer recursos de “Container as a Service” (CaaS) de ponta a ponta.
Mais tarde, em 2015, a AWS deu outro salto à frente com a introdução do AWS Lambda, que poderia economizar ainda mais os custos de implementação de software, executando microservices sob demanda e os interrompendo quando necessário. Esse conceito é análogo ao recurso stop-start em veículos eficientes em termos energéticos que automaticamente desligam o motor de combustão para reduzir o consumo de combustível.
Apesar do termo “serverless computing” (computação sem servidor) soar absurdo à primeira vista, seu significado real é baseado na capacidade de implementar software sem ter qualquer envolvimento com a infraestrutura. As plataformas sem servidor automatizam todo o processo de criação, implementação e início de serviços sob demanda. Os usuários só precisariam registrar as funções empresariais requeridas e suas necessidades de recursos.
Como é evidente, essas funções podem ser classificadas em dois tipos principais: funções que são acionadas por solicitações de clientes e funções que precisam ser executadas em segundo plano por triggers de tempo ou eventos. Geralmente, esses “sistemas sem servidores” podem ser implementados usando um container cluster manager (CCM) com um roteador dinâmico que poderia acionar containers sob demanda. No entanto, ele também precisará considerar a latência do roteador, o tempo de criação do container, suporte de linguagem, suporte de protocolo, interfaces de função, tempo de inicialização de função, passagem de parâmetros de configuração, fornecimento de arquivos de certificado etc.
Mesmo que esse estilo de implementação solicite que os containers sejam interrompidos quando não há carga, na realidade o encerramento de containers pouco tempo depois de atender a requisições seria caro, pois poderia haver mais solicitações dentro de curtos intervalos de tempo. Portanto, com mais frequência, containers de computação sem servidor são preservados por um período de tempo pré-configurado para serem reutilizados e então atender a mais solicitações. Isso é análogo ao comportamento de escalabilidade automática em plataformas PaaS. Uma vez que um serviço é ampliado, as instâncias serão preservadas por um determinado período de tempo para processar mais solicitações sem encerrá-las imediatamente.
Fonte: DZone.com
Gostou do conteúdo? Tem alguma dúvida? Entre em contato com nossos Especialistas Mandic Cloud, ficamos felizes em ajudá-lo.