Série Node.js: Escolhendo o web container ou, na verdade, nem mesmo tendo um

Olá de novo e bem vindo!

[English Version]

Este é o segundo post da minha “Série Node.js”, então, se você não leu o primeiro post, aqui está, aproveite!

Então, como mencionado no post anterior, muitos problemas foram encontrados quando decidimos nos aprofundar no mundo do #NodeJS. Vindo de um mundo Java / SOA, o pouso no paradigma microservices e #NodeJS não é exatamente tão suave como se deve imaginar e isso não é culpa de #NodeJS ou de microservices! Ah não! A questão é que nos acostumamos tanto à verbosidade e impraticabilidade de linguagens enterprise, que a simplicidade pode, na verdade, parecer juvenil ou até errada.

Minha primeira visão disso aconteceu quando comecei a procurar pelo que conhecia como Web Containers, apesar de Java e .Net hoje em dia já ofereçam uma ampla variedade de frameworks onde você não precisa de um contêiner web para ver seus códigos atendendo a solicitações HTTP, é ainda mais comumente visto nas empresas instâncias muito grandes de contêineres Web e servidores de aplicativos em execução, e ninguém deve ser surpreendido com isso. As soluções Cloud serverless estão crescendo mais e mais, no entanto a maioria ainda não conseguiu encontrar o equilíbrio correto para suas próprias empresas implementá-las, resultando em contas incrivelmente altas no final do mês ou simplesmente assistindo suas aventuras na nuvem falharem por falta de conhecimento ou planejamento.

Isso não poderia acontecer agora, então mesmo que o serverless seja nosso objetivo desde o início, foi a decisão da equipe apostar na estratégia de instâncias reservadas, já que isso já era algo de conhecimento comum em todas as equipes de infraestrutura e desenvolvimento. O que isso significava era que uma maneira de executar esses códigos #NodeJS em uma instância reservada tinha que ser encontrada e, depois de algumas pesquisas, uma estrutura de simplicidade surpreendente chamava minha atenção, o framework #ExpressJS. O código abaixo foi exatamente o primeiro código que eu executei para os meus testes. O objetivo do código era simples: obter um serviço HTTP / REST para responder a uma chamada. O que obtive foi isso:


var express = require('express');
var app = express();

app.get('/hello', function (req, res) {
  res.send('Hello! Servidor em operação!!');
});

app.listen(3000, function () {
  console.log('Online on port 3000!');
});

É isso, sério.

Isso não é apenas o código que usei na minha primeira tentativa, na verdade é a solicitação que ainda uso para verificar se meus servidores estão ativos.

Minha segunda bem recebida surpresa foi o quanto de memória virtual custou para o código ser executado. Eu acabo de rodar o código aqui para que eu pudesse obter número exato: 12MB

Na verdade, você pode executar basicamente o mesmo código sem usar #ExpressJS, mas o que faz você querer usar #ExpressJS é a quantidade de serviços que eles fornecem em sua API muito ampla. Vale a pena. E é grátis e de código aberto! Vá conferir!

Estava bem claro agora que com a simplicidade deste código, muito poderia ser entregue com um prazo razoável.

Esse certamente não foi o único problema que enfrentamos em nossa missão. Muito mais tinha que ser descoberto.

Por favor, siga-me na minha conta do Twitter recentemente reaberta @vrsbrazil para que você possa ficar sabendo do resto de nossos esforços com #Microservices e #NodeJS.

Obrigado!

Advertisements

2 thoughts on “Série Node.js: Escolhendo o web container ou, na verdade, nem mesmo tendo um”

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s