A metodologia 12 factor

A metodologia 12 factor consiste em um série métodos que você deve seguir para construir uma aplicação como Software-as-a-Service (SaaS).

Quando li sobre a 12-factor, ficou mais claro pra mim, como aplicações rodando em Cloud estão organizadas em provedores como Amazon AWS, Microsoft Azure, IBM Bluemix ou como soluções Cloud Foundry.

Fator 1 – Um código base em um repositório com multiplos deployments.

Utilize de um sistema de controle de versão como Git ou Subversion, e a partir deste código fonte faça o deploy em múltiplos lugares, como ambiente de desenvolvimento, homologação e produção.

Fator 2 – Declare e separa as dependências.

As dependências da aplicação devem estar fora do código fonte. Por exemplo, no arquivo package.json para uma aplicação em Node.js.
Com isso, o deploy de uma aplicação pode ser feito em diversos servidores, e assim não nos preocupamos com as suas dependências.

Fator 3 – Armazene configuraçòes no seu ambiente.

As configurações da aplicação devem estar fora do código fonte. Nos principais provedores de Cloud, essas configurações são declaradas como variáveis de ambiente.

Exemplo:
set PORT “8080”
set JDBC_URL “jdbc://db_server:port/”

Fator 4 – Trate serviços de apoio como recursos anexado.

Um serviço de apoio é qualquer serviço que a aplicação faça através da rede. Exemplos: Banco de dados (MySql/MongoDB), Sistemas de Mensagens/Filas, serviços SMTP para emails externos (tais como Postfix), e serviços do IBM Watson.

Você deve preparar sua aplicação para usar estes serviços independente do local onde estejam (local ou remoto), e usar variáveis de ambiente para alterar essas configurações. Podendo usar Web UI dashboard do provedor Cloud ou comandos como “cf create-service” e “cf bind-service” para ligar os serviços.

Fator 5 – Faça a separação do Build, Release and Run.

Separe as fases de:

  • Build = Pegue uma versão do código do repositório, forneça as dependências, compile binários e empacote.
  • Release = Envie o Build para um servidor, ajuste as configurações necessárias para que ele seja executado.
  • Run = Rode a aplicação no ambiente de execução, através do início de alguns dos processos da aplicação, para que ele esteja disponível para os usuários acessarem.

Fator 6 – Execute a aplicação como um ou mais processos stateless

Execute a aplicação como um ou mais processos que não armazenam estado.

Quando você cria aplicativos, use vários processos ou serviços conforme necessário.
Evite dependências em stick sessions e mantenha os dados da sessão em um armazenamento persistente para garantir que o tráfego possa ser roteado para outros processos sem interrupção do serviço.

Fator 7 – Exporte de serviços pela porta de TCP/IP

A aplicação lê a variável de ambiente e exporta o serviço através do bind a uma porta de TCP/IP, que recebe as requisições que chegam na mesma.
Depois você pode adicionar um servidor Nginx, que faz um proxy para esse serviço ou utilizar o serviço de roteamento de tráfico do seu provedor cloud.

Fator 8 – Escale atráves do uso de um processo modelo.

Escale horizontalmente a sua aplicação através da criação de processos modelos. Por exemplo, solicitações HTTP podem ser manipuladas para um processo web, e tarefas background de longa duração podem ser manipuladas por um processo trabalhador.

Fator 9 – Maximize a robustez com inicialização e desligamento rápido

Processos no 12-factor são descartáveis, significando que podem ser iniciados ou parados a qualquer momento. Um processo dever iniciar rapidamente, fazendo
o mínimo de ações. E quando o processo for encerrado, deve seguir o mesmo padrão.
Isso facilita o escalonamento, rápido deploy de código ou mudanças de configuração, e robustez de deploys de produção.

Fator 10 – Mantenha os ambientes de desenvolvimento, homologação, produção o mais semelhante possível

Manter ambientes semelhantes evita erros durante o processo de envio da aplicação para produção.

Ferramentas como Docker, Puppet auxiliam nisso. Outras soluções com Spaces no IBM Bluemix provem metodos efetivos para separar diferentes níveis da aplicação.

Esta abordagem permite a entrega de software ágil ( Agile Software) e a integração contínua (continuous integration).

Fator 11 – Trate logs como fluxo de eventos

Utilize os logs da aplicação para entender o funcionamento e utilização da sua aplicação.

A aplicação deve enviar as mensagens para a saída padrão e esta deve ser redirecionada para locais específicos de acordo com o ambiente onde a aplicação está executando, em desenvolvimento para um arquivo.

Exemplo: No Bluemix ou Cloud Foundry, o Loggregator coleta os dados de log em vários componentes do aplicativo e você pode visualizar atráves do comando cf logs.

Fator 12: Executar tarefas de administração/gerenciamento como processos pontuais

Crie tarefas que precisam ser executadas uma vez ou ocasionalmente em componentes separados que podem ser executados quando necessário em vez de adicionar o código diretamente em outro componente.
Por exemplo, se um aplicativo precisa migrar dados para um banco de dados, coloque essa tarefa em um componente separado ao invés de adicioná-lo ao código principal do aplicativo na inicialização.

E aí. Vai utilizar a metodologia 12-factor na sua próxima aplicação?

Leia também:

O que são aplicações Servless?

Apesar do termo Servless, significar “sem servidor”, o conceito de aplicação Servless é bem diferente.

Em aplicações Servless, o desenvolvedor cria uma aplicação que atende a eventos, como por exemplo uma request http, enquanto a gestão do Application server, database, container ou VM, fica por conta do provedor de Cloud.

Dessa maneira, o desenvolvedor foca no desenvolvimento da solução, não se preocupando com a infraestrutura. O faturamento também é diferente, pois o provedor de Cloud vai cobrar pelo eventos, do exemplo anterior, pela quantidade de requisições.

Em breve vou postar algumas dicas de como desenvolver, construir, fazer o deploy, manter e ganhos de eficiência de soluções de software construídas com essas modernas tecnologias de cloud.

Por enquanto, listo abaixo alguns dos principais players de cloud e as tecnologias usadas:

Leia também:

Ofertas Gratuitas do Microsoft Azure

Dica bem interessante sobre o Microsoft Azure!

Se você tem uma conta no serviço de Cloud da Microsoft, pode aproveitar algumas opções gratuitas para qualquer tipo de assinatura.

Serviço Oferta
Serviço de Aplicativo Host de 10 aplicações Web ou Mobile
Hub IoT 3000 mensagens por dia, e controle 10 dispositivos IoT
Hub de notificação 1 milhão de push notifications por mês
Azure Active Directory (AD) Até 500.000 objetos no AD e single-sign-on para 10 aplicações por usuário
AD B2C 50.000 usuários para sua aplicação B2C, a aplicação pode ser Web ou Mobile
Rede Virtual 50 redes virtuais
Visual Studio Team Services Até 5 usuários
Application Insights Ilimitado número de Hosts ou Dispositivos
Azure Search 10.000 documentos indexados
Scheduler 3.600 jobs por mês
Log Analytics 500 MB de log para análise por mês

Mais detalhes veja no link https://azure.microsoft.com/en-us/free/pricing-offers/

Leia também:

Download do Orient Me do IBM Connections 6

No post anterior, falei sobre o Connections 6 e a nova homepage, denominada Orient Me, baseada Docker, NodeJs, Redis, MongoDb e Nginx.

A documentação de instalação do Orient Me, no item Installing the IBM Spectrum Conductor for Containers indica que para baixar o arquivo hybridcloud.zip na IBM Fix Central.

Só que a documentação não indica qual item procurar. Conversei com um engenheiro do Connections, e ele me deu a dica.

Você deve procurar por Fixes para o Connections 6.0!!!

Na listagem, você deve baixar o arquivo IC-OrientMe-6.0.0.0.zip (3.05 GB)!!!

Leia também:

Lançamento do Connections 6.0

Em 31 de Março, uma nova versão do IBM Connections foi liberada. Algumas novidades da versão 6.0.

Orient me
Um novo conceito de homepage, onde as pessoas e comunidades mais importantes são apresentadas e priorizando conteúdos mais úteis da rede dos usuários.
Tecnicamente, o Orient Me migra de uma arquitetura baseada em IHS/WAS/DB2, para uma nova arquitetura baseada em Docker Containers (modelo de virtualização), que executam novas tecnologias como NodeJs/Redis/MongoDb/Nginx.
Futuras versões do Connections usarão essas tecnologias e serão atualizadas usando a arquitetura de containers, ao invés de aplicação de Fixpacks, ou migração lado-a-lado.
Enhanced communities
Recursos avançados de personalização de Comunidades fornece aos proprietários da comunidade opções adicionais para personalizar a sua comunidade.
Torna mais fácil organizar as informações e de modo muito mais atraente, dando ao usuário final uma aparência moderna para as comunidades.
Touchpoint
Permite o “onboarding” dos funcionários ao Conecte BB de maneira mais simples. Sugere colegas e comunidades para seguir, a fim de começar a trabalhar de forma mais eficiente.
Sincronização de Arquivos
A versão 6.0 fornece uma interface simples para sincronizar arquivos. Agora, a sincronização de arquivos suporta pastas.

 

Leia também:

Minha Jornada em ser proficiente em JavaScript e Python.

Sempre trabalhei mais com produtos de mercado do que com desenvolvimento, mas sempre procurei conhecer as linguagens utilizadas neste produtos, com o objetivo de solucionar problemas, melhorar integrações e automatizar tarefas.

A algum tempo, tenho investido bastante do meu tempo em JavaScript e Python. Alguns  motivos para isso são:

  • Os principais fornecedores de Cloud (Amazon AWS, Microsoft Azzure, Google Cloud, IBM Bluemix, …) tem serviços baseados nestas linguagens;
  • Produtos como IBM Connections, estão deixando a plataforma Java/IHS/WAS/DB2 e migrando para Javascript/Nginx/Node.JS/MongoDB.
  • Soluções em Analytics e Big Data de mãos dadas com Python.
Três Homens em Conflito ou O Bom, O Mau e o Feio!!!
O Bom O Mau O Feio
JavaScript
  • JavaScript me faz lembrar da aulas de Programação Funcional!!! Idêntico as recursões da linguagem Scheme.
  • JavaScript é uma escolha natural para quem usa APIs baseadas em Json.
  • JavaScript/Node.JS/MongoDB é uma combinação muito poderosa, onde tratamos objetos de apenas uma maneira, isto é, no formato Json.
  • Assincrônia. Saiba o que são funções “blockantes”, para evitar sustos nos resultados do seu código.
  • Fuja dos Callbacks Hells!
Python
  • Python me faz lembrar das aulas de Pascal da faculdade! Uma linguagem simples e sem burocracia. Programar procedural ou orientado à objeto, fica a escolha do programador.
  • Python é um “trator” no que se fala em tratamento de dados.
  • Python 2.7 e Python 3.x gera confusão de qual devo usar.
  • Uso de Json através de bibliotecas.
  • Alguns artigos que li sobre o Python 3, questionam sobre os problemas de performance devido ao novo I/O stack e o suporte a Unicode.

Em ambos as linguagens, tenha noção de:

  • “Para prego use Martelo, para parafuso use Chave de Fenda”, saiba quando utilizar uma linguagem ou outra.
  • Escolha um bom editor, como sugestão Atom, Sublime e Visual Studio Code.
  • Bibliotecas são instaladas com facilidade usando npm/JavaScript ou pip/Python.
  • Aprenda a fazer chamadas via Rest para APIs estamos na era da Economia das APIs.
  • Você precisa utilizar dados JDBC, SAP, Aplicações Legadas, etc. Crie APIs em Java Servlets, e utilize dentro do Javascript e Python usando Rest/HTTP, com isso você reduz a necessidade de instalação de novas bibliotecas.

Nunca deixe de aprender coisas novas e pratique, pratique, pratique.

Leia também:

Migre o seu Domino do AIX/Windows para o Linux

Trabalhei com o IBM Domino em diversas plataformas (AIX/Windows/Linux/zLinux). Em todas o Domino tinham ótima performance e um uptime muito alto.

Mas quais seriam os motivos pra recomendar isso?

Vendo a apresentação “Notes Domino 2016 Roadmap.pptx”, a mesma apresentava como plataformas estratégicas para o Domino o Microsoft Windows Server e RedHat Enterprise Linux (RHEL).

Além dessa questão de estratégia, vejo outros motivos para migrar de AIX/Windows para Linux:

  • Ferramentas DevOps, como shell e puppet, padronizam o ambiente Domino, melhorando a performance, uptime e reduzindo o TCO.
  • SmartCloud usa esta plataforma.
  • Verse On-Premises para Linux, já está disponível para essa plataforma desde Janeiro/2017
  • Traveler na mesma plataforma
  • IBM mail support for Microsoft Outlook (IMSMO) na mesma plataforma
  • Flexibilidade entre a quantidade de Domino Partitions (DPAR) por VM, isto é, melhor uso de recursos ou maior isolamento. Uma DPAR é semelhante a uma instância Oracle,Melhorar o isolamento.

Apesar de atualmente não ser suportado, vejo como futuro o uso de containers Docker para execução do Domino ao invés de Virtual Machines (VM). Sobre Domino em Docker, sugiro dar uma olhada nessa apresentação feita  Matteo Bisi and Daniele Vistalii, e ver o artigo How to Run IBM Domino Server in Docker Container.

Leia também: