Expondo a sua aplicação no Kubernetes

Não vou explicar conceitos do Kubernetes, pois não é o meu foco aqui, a idéia é comparar com o modelo tradicional afim de entender melhor o Kubernetes.

Se você precisa expor qualquer serviço executando dentro de um cluster Kubernetes, você deve utilizar o Ingress.

Para explicar de forma rápida o Ingress, montei o seguinte diagrama:

Você deve pensar no Ingress, como um típico Proxy Reverso que colocamos na DMZ, para permitir acesso à sua aplicações que ficam na Intranet. No modelo tradicional usariamos um Apache HTTP server ou um Nginx, pra controlar o tráfego e proteger contra ataques da Internet.

Em um ambiente Java tradicional, teríamos um Load Balancer ou um HTTP Server na frente dos Servidores de Aplicação, mas no Kubernetes temos as figuras do Service e dos PODs, respectivamente.

Adicionei a personagem do Operado de Proxy, que seria do Admin que faz alteração no arquivo .conf. Já no K8s, essa tarefa é executada através do comando kubectl. Podendo usar o linha de comando ou através de um arquivo yaml.

Acredito que tenho deixado mais claro o funcionamento do Ingress. Bye.

Leia também:

  • Sem textos relacionados

Prós e Contras de ter um ou vários Clusters de Kubernetes

Montei uma lista de prós e contras que podem ajudar você e a sua empresa a decidir, sobre a necessidade de ter apenas um ou vários clusters de Kubernetes.

Razões para ter um único cluster:

  1. Reduzir a sobrecarga de configuração, manutenção e administração
  2. Melhor utilização de recursos
  3. Reduzir a latência entre aplicativos em vários clusters
  4. Redução de custos

Neste caso você utiliza Namespaces para poder separar os ambientes, como por exemplo Desenvolvimento, Homologação e Produção.

Razões para ter vários clusters:

  1. Limites de escalabilidade, por exemplo, um cluster Kubernetes tem um limite de nodes, pods, services.
  2. Separação de Desenvolvimento, Homologação e Produção.
  3. Separação para testar uma nova versão do Kubernetes.
  4. Segurança e Conformidade: de acordo com alguns regulamentos, alguns aplicativos devem ser executados em clusters/VPNs separados e diferentes políticas de segurança.
  5. Multi-fornecedor: para se proteger de práticas de Lock-in. Usando de clusters de vários fornecedores.
  6. Nuvem Pública/On Premise: para dividir a carga e o custo.
  7. Regionalidade para latência: executar clusters em diferentes regiões geográficas para reduzir a latência nessas regiões.
  8. Regionalidade para disponibilidade: executar em clusters em diferentes regiões/zonas de disponibilidade para reduzir os danos de um datacenter/região com falha.
  9. Facilitar a cobrança: Isolamento de cluster para facilitar a cobrança.

Leia também:

Novo local para o IBM Collaboration Solutions Catalog

O catálogo de produtos da IBM Collaboration Solutions que antes ficava no Greenhouse, migrou para uma nova url –> https://xspy.mybluemix.net/

Nele estão disponíveis:

  • IBM Connections Desktop Plug-ins for Microsoft Windows
  • IBM Connections Plug-ins for IBM Notes
  • Web Application Integrator for IBM WebSphere Portal
  • ….

Leia também:

Performance com Strings e StringBuilder em Java

Semana passada, estava trabalhando em uma ferramenta em java, que coletava algumas informações e gerava uma saída para um arquivo txt.

Ao testar a ferramenta com um grande volume de dados, me surpreendi que ela gastava mais tempo de execução na concatenação de String do que na escrita do arquivo.

Não podia deixar a ferramenta assim e como um bom programador resolvi melhorar o meu código. E olha como ficou o resultado.

Na primeira versão concatenava usando apenas Uma String (output), código abaixo:

long prev_time = System.currentTimeMillis();
long time;
String output = "";

for (Device device : this.devices) {
 output += "\"deviceid\": \"" + device.deviceid + "\", ";
....
}
time = System.currentTimeMillis() - prev_time;
System.out.println("Time after for loop " + time);

O resultado foi “Time after for loop 233117 ms“, a ferramenta gastava aproximadamente 4 minutos para executar.

Na segunda versão, usei Duas Strings (output e output2) para fazer a concatenação, código abaixo:

long prev_time = System.currentTimeMillis();
long time;
String output = "";

for (Device device : this.devices) {
 String output2 = "";
 output2 += "\"deviceid\": \"" + device.deviceid + "\", ";
....
 output += output2;
}
time = System.currentTimeMillis() - prev_time;
System.out.println("Time after for loop " + time);

O resultado foi “Time after for loop 22929 ms“, a ferramenta agora gastava apenas 22 segundos para processar. Muito bom!!!

Achei que não deveria parar nesse valor e procurei qual outro tipo de classe Java, que poderia utilizar, e num pesquisa rápida encontrei o StringBuilder.

Na terceira versão usei o StringBuilder, veja código abaixo:

long prev_time = System.currentTimeMillis();
long time;
StringBuilder sb = new StringBuilder();

for (Device device : this.devices) {
 String output2 = "";
 output2 += "\"deviceid\": \"" + device.deviceid + "\", ";
....
 sb.append(output2);
}
time = System.currentTimeMillis() - prev_time;
System.out.println("Time after for loop " + time);
String output3 = sb.toString();

O resultado foi  “Time after for loop 137 ms“, impressionantes 137 milissegundos.

Performance é sempre um desafio, mas melhor ainda é compartilhar. #FicaADica

Leia também:

Engenharia de Software: Métodos Ágeis – SCRUM

Artigo da Série Engenharia de Software.

O tema de hoje: SCRUM.

Scrum é uma metodologia ágil para Gerenciamento de Projetos. Ela é baseada em ciclos de 2 a 4 semanas chamados Sprints.

Nos Sprints, se trabalha para alcançar objetivos bem definidos. Estes objetivos (requisitos do sistema) estão no Product Backlog, e são constantemente atualizados e re-priorizados.

No Scrum, as pessoas tem seus papéis:

  • Product Owner

É o ponto focal do projeto, pois tem a visão do negócio. É quem prioriza o Product Backlog.

  • Scrum Master

É um lider/facilitador. Ajuda a equipe a resolver problemas e assegura a prática do Scrum. Não tem autoridade sobre a equipe.

  • Time Scrum

É a equipe de Desenvolvimento. No Scrum, a equipe se auto-organiza e tem poder para definir, inclusive com possibilidade de remove membros da equipe.

Como funciona?

Pega-se os itens do topo da lista no Product Backlog, e define-se um Sprint. Na Execução do Sprint, estes itens são chamados de Sprint Backlog, e são distribuídos no time Scrum.

O Scrum Master faz reuniões diárias de 15 minutos (Daily Scrum) para saber o andamento. Nesta reuniões cada membro deve responder as seguintes questões:

  • O que foi feito?
  • O que tem pra hoje?
  • Tá com algum problema?

No final do Sprint, temos como entrega o produto de Sprint e o Document-of-Done (DoD). Deve ser feita uma revisão pela equipe do produto entregue (Sprint Review) e do  processo (Sprint Retrospective), afim de melhorar ambos.

Leia também:

Engenharia de Software: Modelo de Ciclo de Vida

Artigo da Série Engenharia de Software.

O tema de hoje: Modelo de Ciclo de Vida.

Em Engenharia de Software, o Modelo de Ciclo de Vida é o processo de planejar, criar, testar e colocar em produção um Sistema da Informação.

Categorias:

  • Sequenciais
    • Modelo em Cascata (Clássico) : Segue uma sequência linear.
  • Incrementais
    • Modelo Incremental: Combinação do modelo Linear e Prototipação.
  • Evolutivos
    • Prototipação (Prototipagem): Facilita o entendimento pelo usuário
    • Espiral: Ciclos de desenvolvimento que melhoram a cada iteração. Focado em Risco.
  • Agéis
    • Incremental + Evolutivo

Leia também:

Engenharia de Software: Engenharia de Requisitos

Artigo da Série Engenharia de Software.

O tema de hoje: Engenharia de Requisitos.

Engenharia de Requisitos é o processo de definir, documentar e manter os requisitos em Engenharia de Software.

Quais as principais atividades?

Antes de mostrar quais as atividades estão envolvidas na Engenharia de Requisitos, é importante fazer um Estudo de Viabilidade com as partes interessadas, para saber se a solução a ser implementada agrega valor ao negócio, se tem orçamento, se tem integração e se já não existe uma solução pronta de mercado.

Após o estudo teremos:

  • Levantamento (Elicitação)

Analistas e Stakeholders se reunem para levantar necessidades. Aqui podemos fazer uso de técnicas como: Entrevistas, Questionários, Workshops de Requisitos, Cenários, Prototipagem e Etnografias (vivenciar na prática a situação, semelhante aos Laboratórios que atores realizam pra montar uma personagem).

  • Análise/Negociação de Requisitos

Aqui classificamos, resolvemos conflitos ( inclusive políticos), priorizamos e confirmamos os requisitos.

  • Especificação

Esta é a atividade de documentação e modelagem. Definimos requisitos para os usuários, requisitos de sistema, o design da aplicação. Estes requisitos classificamos como requisitos funcionas (RF) e requisitos não funcionais (RNF). Criamos Casos de Usos, e outros diagramas presentes na UML.

  • Validação

Com a documentação em mãos, o analista de requisitos verifica e valida se o sistema atende ao clientes. Algumas técnicas usadas são Revisão, Prototipação, Criação de Casos de Testes.

  • Gestão de Requisitos

A gestão de requisitos faz o controle de mudanças para atender à dinâmica dos negócios, visão do usuário, ….

Leia também: