Desde o seu lançamento em 2014 pela Google, o Kubernetes tem ganhado muita popularidade junto com o próprio Docker e, desde 2016, passou a ser o de facto Container orchestrator, sendo estabelecido como um padrão de mercado e ganhando versões gerenciadas em todas as major Clouds[1] [2] [3] (inclusive na Digital Ocean e Alibaba).

Toda essa popularidade tem atraído novas implementações e use-cases para o orquestrador, dentre eles a execução de Stateful applications e inclusive a tentativa de rodar bancos de dados em containers. Qual seria a necessidade de orquestrar um banco de dados? Ótima pergunta para um outro post. Por hoje, vamos focar na utilização do Spark Operator para executar Spark workloads em Kubernetes.

A idéia de executar nativamente no Kubernetes surgiu em 2016 e antes disso haviam alguns jeitinhos de fazer acontecer. Por exemplo: com Apache Zeppelin ou então, mais refinado ainda com um cluster que usaria o Spark Standalone mode.

Porém, executar nativamente seria muito mais interessante e a idéia cresceu bastante, tomou forma, ela foi desenvolvida e integrada na versão 2.3.0 do Spark que foi lançada em Feveiro de 2018.

Quais os benefícios de executar Spark no Kubernetes?

Como atualmente as empresas estão buscando se reinventar por meio da tão falada transformação digital para que possam ter competitividade e, principalmente, sobreviver diante de um mercado cada vez mais dinâmico, é comum ver abordagens que incluam Big Data, Inteligência Artificial e Cloud Computing[1] [2] [3].

Dentre os benefícios de utilizar Cloud ao invés de On-premises podemos listar:

• Custo;
• Elasticidade;
• SLA;
• Integridade.

Uma comparação interessante pode ser lida no blog da Databricks que é a empresa fundada pelos criadores do Apache Spark.

Como nós vemos uma adoção de Cloud Computing generalizada (até por empresas que teriam condições de bancar o próprio hardware), que muitas vezes nessas implementações de Cloud não existem clusters de Apache Hadoop já que os times de Dados (BI/Data Science/Analytics) optam cada vez mais por utilizar ferramentas como Google BigQuery ou AWS Redshift, não faz sentido subir um Hadoop apenas para utilizar o YARN para gerenciar os recursos.

Para entender melhor o design do Spark Operator, recomendo a leitura da documentação gerada pela equipe da GCP no GitHub.

Setup

Agora que toda a palavra já foi passada, vamos meter a mão na massa para mostrar a coisa acontecendo. Para isso, vamos usar:

• Docker como motor de container no Kubernetes, e construção da imagem (link para instalação);
• Minikube (link para instalação) para facilitar o provisionamento do Kubernetes (sim, será uma execução local);
• uma versão compilada do Apache Spark que seja maior do que a 2.3.0.

Instalação do Spark

Para o Apache Spark, é possível tanto compilar o código fonte, que levará algumas boas horas, ou baixar uma versão compilada aqui (recomendo). Após ter o Apache descompactado, vamos adicionar o caminho no PATH para facilitar a execução:

export PATH=${PATH}:/path/to/apache-spark-X.Y.Z/bin

Criação do Kubernetes com Minikube

Para interação com o Kubernetes que será executado em uma VM pelo minikube, será necessário ter o kubectl instalado, que pode ser feito seguindo esse link.

Agora, para ter um cluster de Kubernetes vamos iniciar um minikube básico, com o propósito de rodar um dos exemplos que já vem no repositório do Spark chamado SparkPi apenas como demonstração:

minikube start

Construção da imagem base

Vamos utilizar o Docker daemon do Minikube para não depender de um registry externo (e só gerar lixo na VM). Para isso, o minikube tem um wrapper que facilita a nossa vida configurando o host:

eval $(minikube docker-env)

Por último, precisamos de uma imagem base para rodar os jobs. Existe um shell script no repositório do Spark para ajudar com isso. Como o PATH está com os binários, o commando:

docker-image-tool.sh -m -t latest build 

Obs.: O parâmetro -m aqui indica que o build será para o minikube.

FIRE IN THE HOLE!

Para executar o SparkPi vamos no modo fácil, usando o mesmo comando que seria utilizado para um cluster Spark spark-submit. Porém, o Spark Operator dá suporte a definição de jobs no "idioma do Kubernetes" usando CRD, aqui tem alguns exemplos.

A versão que instalei do Apache Spark é 2.4.3, isso precisa ser passado no parâmetro:

spark-submit --master k8s://https://$(minikube ip):8443 \
  --deploy-mode cluster \
  --name spark-pi \
  --class org.apache.spark.examples.SparkPi \
  --conf spark.executor.instances=2 \
  --executor-memory 512m \
  --conf spark.kubernetes.container.image=spark:latest local:///opt/spark/examples/jars/spark-examples_2.11-2.4.3.jar

O que entra de novo aqui é:

• --master: Aceita como parâmetro um schema k8s:// e então nós passamos o endpoint da API do Kubernetes, que está exposta pelo minikube https://$(minikube ip):8443;
• --conf spark.kubernetes.container.image=: Configuração para a imagem base que será executada no Kubernetes

Com o output:

...
19/08/22 11:59:09 INFO LoggingPodStatusWatcherImpl: State changed, new state:
	 pod name: spark-pi-1566485909677-driver
	 namespace: default
	 labels: spark-app-selector -> spark-20477e803e7648a59e9bcd37394f7f60, spark-role -> driver
	 pod uid: c789c4d2-27c4-45ce-ba10-539940cccb8d
	 creation time: 2019-08-22T14:58:30Z
	 service account name: default
	 volumes: spark-local-dir-1, spark-conf-volume, default-token-tj7jn
	 node name: minikube
	 start time: 2019-08-22T14:58:30Z
	 container images: spark:docker
	 phase: Succeeded
	 status: [ContainerStatus(containerID=docker://e044d944d2ebee2855cd2b993c62025d6406258ef247648a5902bf6ac09801cc, image=spark:docker, imageID=docker://sha256:86649110778a10aa5d6997d1e3d556b35454e9657978f3a87de32c21787ff82f, lastState=ContainerState(running=null, terminated=null, waiting=null, additionalProperties={}), name=spark-kubernetes-driver, ready=false, restartCount=0, state=ContainerState(running=null, terminated=ContainerStateTerminated(containerID=docker://e044d944d2ebee2855cd2b993c62025d6406258ef247648a5902bf6ac09801cc, exitCode=0, finishedAt=2019-08-22T14:59:08Z, message=null, reason=Completed, signal=null, startedAt=2019-08-22T14:58:32Z, additionalProperties={}), waiting=null, additionalProperties={}), additionalProperties={})]
19/08/22 11:59:09 INFO LoggingPodStatusWatcherImpl: Container final statuses:


	 Container name: spark-kubernetes-driver
	 Container image: spark:docker
	 Container state: Terminated
	 Exit code: 0

E para ver o resultado do job, e toda a execução podemos mandar um kubectl logs passando o nome do pod do driver como parâmetro:

kubectl logs spark-pi-1566485909677-driver

Que traz o output (algumas entradas foram omitidas), parecido com:

...
19/08/22 14:59:08 INFO TaskSetManager: Finished task 1.0 in stage 0.0 (TID 1) in 52 ms on 172.17.0.7 (executor 1) (2/2)
19/08/22 14:59:08 INFO TaskSchedulerImpl: Removed TaskSet 0.0, whose tasks have all completed, from pool
19/08/22 14:59:08 INFO DAGScheduler: ResultStage 0 (reduce at SparkPi.scala:38) finished in 0.957 s
19/08/22 14:59:08 INFO DAGScheduler: Job 0 finished: reduce at SparkPi.scala:38, took 1.040608 s
Pi is roughly 3.138915694578473
19/08/22 14:59:08 INFO SparkUI: Stopped Spark web UI at http://spark-pi-1566485909677-driver-svc.default.svc:4040
19/08/22 14:59:08 INFO KubernetesClusterSchedulerBackend: Shutting down all executors
19/08/22 14:59:08 INFO KubernetesClusterSchedulerBackend$KubernetesDriverEndpoint: Asking each executor to shut down
19/08/22 14:59:08 WARN ExecutorPodsWatchSnapshotSource: Kubernetes client has been closed (this is expected if the application is shutting down.)
19/08/22 14:59:08 INFO MapOutputTrackerMasterEndpoint: MapOutputTrackerMasterEndpoint stopped!
19/08/22 14:59:08 INFO MemoryStore: MemoryStore cleared
19/08/22 14:59:08 INFO BlockManager: BlockManager stopped
19/08/22 14:59:08 INFO BlockManagerMaster: BlockManagerMaster stopped
19/08/22 14:59:08 INFO OutputCommitCoordinator$OutputCommitCoordinatorEndpoint: OutputCommitCoordinator stopped!
19/08/22 14:59:08 INFO SparkContext: Successfully stopped SparkContext
19/08/22 14:59:08 INFO ShutdownHookManager: Shutdown hook called
19/08/22 14:59:08 INFO ShutdownHookManager: Deleting directory /tmp/spark-aeadc6ba-36aa-4b7e-8c74-53aa48c3c9b2
19/08/22 14:59:08 INFO ShutdownHookManager: Deleting directory /var/data/spark-084e8326-c8ce-4042-a2ed-75c1eb80414a/spark-ef8117bf-90d0-4a0d-9cab-f36a7bb18910

O resultado aparece no stdout:

19/08/22 14:59:08 INFO DAGScheduler: Job 0 finished: reduce at SparkPi.scala:38, took 1.040608 s
Pi is roughly 3.138915694578473

Cleanup

Para finalizar, vamos deletar a VM que o Minikube gera, para limpar o ambiente (a menos que você queira continuar brincando com ele):

minikube delete

Espero ter dispertado bastante curiosidade e te apresentado uma nova possibilidade para seus workloads de Big Data. Caso tenha alguma dúvida ou sugestão, comenta aí que nós conversamos.

Dentro da engenharia de sistemas, é muito complicado fazer o planejamento do desenvolvimento de um produto, pois muitas vezes o desenvolvimento de software é muito mais arte do que ciência, e os projetos falham. Irei descrever como nós da Datenworks projetamos, implementamos e entregamos tecnologia e sistemas.

Antes de mais nada, para não deixar dúvidas, vamos esclarecer o que é o sistema que você verá bastante no texto:

sistema = software + hardware + pessoas.

Desenvolvimento iterativo e incremental

Confiamos, usamos e abusamos dos métodos de desenvolvimento ágil, alinhados com cultura+metodologias DevOps de entrega contínua e aproximamos ao máximo possível o cliente do processo de desenvolvimento do software. Dessa forma, aumentamos a chance de sucesso do projeto, pois trazemos para a mesa a discussão em volta do que realmente agrega valor ao produto.

Prototipação

Muitas vezes nem todos os requisitos para desenvolvimento estão bem descritos, pois nem mesmo o cliente/usuário tem a visão total do que seria necessário fazer para resolver o problema dele. Nesse cenário, muitas vezes é interessante criar protótipos, podendo ser apenas mock-ups ou até mesmo pequenos pedaços de software funcionais para interação.

MVP

Esse conjunto de ideias nos leva muitas vezes a implementação e evolução de Minimum viable products, tendo sempre uma experiência interessante para apresentar ao usuário, colher feedbacks, iterar e melhorar em cima da visão de quem irá utilizar o produto, e não em cima de feeling ou guessing.

Lean manufacturing. Lean Startup. Por que devo me importar?

A metodologia apresentada no livro Lean start-up, descreve bem essas ideias e como elas vêm revolucionando o desenvolvimento de produtos e negócios desde a popularização do Agile Manifesto.

Favorecendo experimentação ao invés de elaborar um plano detalhado, feedbacks dos usuários/clientes ao invés de intuição e um design iterativo ao invés do desenvolvimento prévio de toda a aplicação. Essa metodologia descreve bastante o que o Agile traz para o desenvolvimento de software, porém, com uma visão de negócio/produto e projetos no geral, não se limitando a utilização em softwares.

Um dos pontos interessantes que não podemos ignorar é que: injetar dinheiro no design de um produto não é suficiente para garantir o sucesso desse produto, se ele não estiver usável e for interessante para os usuários.

“Dinheiro não é o problema, pode gastar”

Esse cenário acontece tanto em grandes empresas, quanto em startups que recebem bastante dinheiro em rodadas de investimento e entram numa certa zona de conforto no que diz respeito às tecnologias e o quanto estão dispostas a arriscar.

Muitas vezes o excesso de dinheiro traz confiança para o negócio, e na maioria desses casos, é comum ouvir que “dinheiro não é o problema”. Esse tipo de afirmação traz preocupações como:

• A empresa está abrindo mão de bons desafios técnicos, para se acomodar com algum vendor;
• Está tampando falhas no sistema (tanto software quanto pessoas) com dinheiro, o que não é saudável no médio/longo prazo.

Quando não se consegue contratar a mão-de-obra necessária para operar certo componente (e isso é comum em tecnologia) é aceitável contratar componentes SaaS (software as a service) e terceirizar a operação. Porém, essa falha não pode ser simplesmente esquecida, afinal, cedo ou tarde a conta chega.

Do contrário, será cada vez mais comum o problema de empresas que falharam por ter conforto demais por meio de dinheiro para inovar e deixaram de ganhar potencial competitivo.

Apesar disso ser mais comuns em grandes empresas que têm mais dificuldade para se mover e evoluir, também existe o caso de startups que falharam mesmo recebendo bons investimentos. Apesar de parecer estranho, se apoiar em uma pilha de dinheiro pode ser matador para a criatividade.

Escolha a sua infra como você escolhe comida, não perfume

Há uma frase de um famoso investidor e escritor chamado Benjamin Graham que diz que “Se você estiver comprando ações, escolha-as do jeito que você compra comida, não do jeito que você compra perfume.”

Podemos adaptar essa frase para o nosso contexto dizendo que “se você estiver investindo em sua infra, escolha-as do jeito que você compra comida, não do jeito que você compra perfume”. Afinal de contas, é muito comum ver implementações utilizando ferramentas desnecessárias (over-engineering) para resolver problemas que talvez nunca existam.

Precisamos ser pragmáticos e realistas durante o design de um sistema, o cliente que irá utilizar o software pouco se importa com o que está embaixo dos panos, desde que as requisições estejam sendo respondidas em um bom tempo, e não haja falhas na interação.

Gastar menos combustível, permite que você rode por mais tempo, e chegue mais longe.

A importância das métricas e do monitoramento

Ter um bom monitoramento configurado, e métricas de consumo dos recursos nos ajuda a ter base para fazer cálculos de carga e capacity planning da infraestrutura. Assim como ajustar pontos de lentidão na aplicação para responder mais rápido e melhor, com métricas de APM.

Ser assertivo e ter uma visão clara da realidade sobre a sua aplicação/produto cria maiores possibilidades de sucesso, ao invés de ser intuitivo.

Agora que a palavra das premissas foi passada, vamos falar do desenvolvimento!

Exemplo prático de produto entregue

A melhor maneira de evidenciar todas essas ideias seria colocar elas em prática. Portanto, vamos ao desenho de um projeto real em que pudemos aplicar tudo o que foi apresentado até aqui, pois de gente que fala que faz o mercado já está cheio.

Seguindo a linha do processamento inteligente de textos, tivemos a oportunidade de fazer a reengenharia de processos de uma empresa de clipping, utilizando RPA para facilitar a operação e dar escala ao processo.

Para fazer o produto “parar de pé” por conta própria, nós projetamos ele para ser:

• Extremamente enxuto, usando apenas componentes que fossem realmente necessários, inclusive em termos de infra, fazendo testes de carga e usando os tamanhos ideais (nem maiores, nem menores) de VMs, e mais da metade da infraestrutura passa menos de 10h por dia ligada;
• Gastamos no máximo 2h por mês com a infra, não há manutenção, o monitoramento não alerta, e não há indisponibilidade devido a implementação de escalabilidade e resiliência na aplicação e na infra;
• Qualquer tarefa/requisição executada pode ser interrompida a qualquer momento e a aplicação garante que ela não será perdida. Na pior hipótese, só é refeita e mesmo assim não cria duplicidade;

Dentro da ideia de produto enxuto, levamos em consideração o Lean desde o modelo Toyota, utilizando dos 3M e Kaizen para abordagem do todo.

Arquitetura proposta

Esse foi o primeiro diagrama de implementação, que já está um pouco distante da realidade. Nesse momento ainda não tínhamos escolhido qual seria o cloud-provider, portanto, o diagrama está com desenhos genéricos (e alguns ícones bonitos do pacote da Azure).

Por que ainda não tínhamos escolhido o cloud-provider? Não queríamos oferecer uma experiência ruim para os usuários, portanto a confiabilidade foi colocada acima dos outros requisitos, como eficiência em custos.

Comparamos Google Cloud Platform e Amazon Web Services, com benchmark de implementação, estimativa de custos e quais features seriam usadas em cada nuvem.

Implementação na nuvem

Escolhemos AWS com a seguinte conclusão (na época):

Olhando apenas para os custos, a GCP se apresenta como o melhor provedor de infraestrutura. Porém, o fato do custo ser mais baixo está diretamente ligado com a falta de maturidade do ambiente, sendo o custo utilizado como estratégia de promoção do provedor. Nesse caso, a confiabilidade fica arriscada, e o comportamento das aplicações não seria tão previsível quanto na AWS.

Outro ponto a ser analisado, é a velocidade para desenvolvimento das aplicações, por ser um provedor mais antigo e estável, a AWS oferece uma velocidade maior no release dos softwares. Além de ter uma comunidade ativa maior, e um suporte mais evoluído em relação aos produtos.

Considerando que os gastos com a AWS ficam 14.67% mais altos em comparação com a GCP, vale a pena utilizar a AWS como provedor, pois a velocidade para o desenvolvimento em uma nuvem mais evoluída, assim como questões claras de segurança, suporte e integridade compensam o custo.

Containers rodando no Kubernetes? Não (:

No primeiro momento a ideia era de utilizar Kubernetes para executar os jobs de processamento dos textos, extração e análise. Porém, percebemos que manter o Kubernetes seria mais trabalhoso do que benéfico (comida, não perfume!) e optamos pelo ECS que, apesar de não ser tão cool nem hype, nos atende bem.

Dentro do ECS temos as definições de services que são executados por meio de auto-scaling groups com instâncias mistas.

Como assim auto-scaling group misto?

Dividimos as instâncias em: 70% spot e 30% on-demand, sendo que a maior parte do tempo, nós estamos consumindo instâncias spot que são maiores que as on-demand.

Essas instâncias on-demand estão lá apenas para garantir que não haja indisponibilidade, caso não tenhamos mais spot instances na zona para usar. Isso nos traz uma economia de aproximadamente 46% nos gastos com EC2.

Sem falar que as instâncias não passam 24h ligadas, elas são apenas ativadas durante as horas de processamento, e ao longo do dia há um script rodando no Lambda que ajusta a quantidade desejada e máxima no auto-scaling, para que o scale down seja mais rápido e sutil.

Nem mesmo o DB fica ligado 24h

Exceto o Redis que precisa estar de pé o dia quase todo, para receber eventos da inserção de novos jornais no S3 (nós desligamos ele, e podemos implementar um fallback pro SQS), toda a infra é desligada fora do horário comercial.

Claro que em outros casos não seria tão simples desligar tudo, isso se dá pela natureza de consumo dos usuários. Porém, acreditamos que sempre há melhorias para serem feitas nos sistemas.

SaaS para tudo? Também não

A única coisa que não está sendo executada em EC2 é o PostgreSQL, pois o RDS nos traz ótimos benefícios por um custo aceitável, ainda mais que instâncias no RDS podem ser desligadas desde 2017.

Isso não nos gera indisponibilidade, nem desconfiança. Software as a Service só se torna uma opção atraente quando não há a capacidade de manter a própria infra na empresa.

Se disponibilidade for a única preocupação, então posso dizer que esse produto está no ar desde Novembro de 2018, e a aplicação se mantém de pé sem manutenção. A implementação da infra está bem confiável, vamos falar de SRE? (:

Simplicidade — a arte de maximizar a quantidade de
trabalho não realizado — é essencial.

Concorda? Discorda? Muito pelo contrário?

Se estiver afim de acrescentar seu ponto ao texto, comenta aí que a gente conversa :D

Uma das proposições de valor da tecnologia Big Data é a capacidade de resolver problemas complexos do cotidiano que, em geral, exigiriam esforços tremendos (pessoas, processos, tecnologia) para proporcionar alguma chance de sucesso. Em vários cenários de negócio, seja na criação fabril de produtos ou execução de serviços, o ganho de escala operacional traz desafios importantes para determinar a capacidade de uma empresa em crescer (ou não) de forma sustentável no longo prazo. Se o custo de produção/operação acelera além do crescimento de receita, certamente há problemas de escala.

A partir deste post, contaremos a jornada de transformação digital de um dos clientes Datenworks e como este cliente, através de Big Data e uso adequado de engenharia de software e automação de processos, reinventou a sua forma de operar, gerar valor para o seu mercado e escalar seu próprio negócio.

Qual o problema?

Imagine que você lidera uma empresa, com mais de 20 anos de mercado, que presta serviços na área de clipping 👇 para mais de 1000 clientes (empresas/pessoas físicas) em todo o Brasil.

Clipping é uma expressão idiomática da língua inglesa, uma “gíria”, que define o processo de selecionar notícias em jornais, revistas, sites e outros meios de comunicação, geralmente impressos, para resultar num apanhado de recortes sobre assuntos de total interesse de quem os coleciona.

Sua oferta de clipping envolve capturar, estruturar e apresentar ao seu cliente, no tempo máximo contratado, todo o nível de exposição da imagem do cliente (pessoa/empresa) e temas de interesse do mesmo em todas as mídias contratadas. Por “mídia”, há de tudo. Jornais (digitais e impressos), revistas, web sites, TV, rádio, etc. De todas as mídias capturadas, uma das mais importantes é conhecida como mídia impressa, que reúne jornais e revistas (digitais e impressos) de todo o país, abrangendo grandes centros e até mesmo pontos mais remotos.

Agora considere o seguinte cenário:

• Pauta diária de leitura de impressos compreende, em média, 300 jornais distintos. 😮
• Jornais distribuídos por todo o Brasil.
• Operação integral, 365 dias por ano.
• Leitura totalmente manual, realizada por dezenas de pessoas 😲
• Os principais jornais do país precisam ser “lidos” (com muita atenção) e entregues para clipping (recorte e envio ao cliente) até às 07:00, todos os dias. 😰

Considerando que sua empresa já realiza esta atividade com alto nível de qualidade mas, ao mesmo tempo, com alto custo operacional (funcionários, espaço físico, etc.), como lidar com o crescimento potencial do seu negócio diante dos claros desafios de escala?

A leitura de impressos, dentre vários aspectos, é uma das operações mais complexas da rotina de clipping. Apenas citando alguns:

• Janela de leitura prioritária — 18 jornais de grande circulação (em média, 800 páginas) lidos até 07:00.
• Em alguns jornais, há mais de uma pessoa realizando a leitura.
• Um dos principais jornais leva mais de 1h para ser lido por 2 (duas) pessoas.
• Pessoas falham (e também faltam ao serviço, eventualmente).
• Hora-extra aos fins de semana.
• Não basta “apenas ler”. É preciso identificar e apontar os termos de interesse de centenas de clientes interessados no conteúdo impresso.

Neste processo, a única forma de ganhar escala de produção é, simplesmente, contratar mais leitores, que precisam ser treinados, escalados em times e acompanhados por gestores, estações de trabalho e planejamento de logística para deslocamento até o escritório da empresa, onde todos estão para o turno de produção.

Muita coisa que pode dar errado, não? 👎

O ponto central da questão envolve ganho de escala na leitura de impressos. Para obter ganho de escala, é preciso isolar da interferência (e dependência) humana as tarefas de alta repetição, sensíveis a erro e que causam degradação e perda de qualidade do processo como um todo, quando falhas ocorrem.

Solução proposta

Há muitos anos, a indústria de tecnologia já pesquisa abordagens com uso de computadores para automação de processos do cotidiano de pessoas, como a leitura de texto em linguagem natural (inglês, português, etc.)

Para o desafio em clipping, a solução passaria por automatizar a leitura a partir de técnicas de OCR (Optical Character Recognition). Há diversas soluções OCR no mercado (comerciais e open-source, cloud e on-premises), mas apenas “ler” não seria o bastante. Como identificar o conteúdo relevante para o cliente final? Diante de um volume gigantesco de informação (300 jornais por dia, lembra?), como fazê-lo no menor tempo possível, sem comprometer a qualidade já alcançada na abordagem manual?

A solução desenvolvida sob medida pela Datenworks, após estudo e definição clara dos objetivos de negócio, envolveu a construção de um serviço automatizado de leitura de impressos, utilizando tecnologias open-source e cloud computing com foco na máxima eficiência do processo e menor TCO possível.

Em linhas gerais o processo de leitura, agora automatizado, é composto de etapas simples de operação porém bastante ágil em entrega de resultados 👇

Ao final do processo, os resultados da leitura automatizada são entregues ao leitor de forma que ele apenas faça uma simples revisão, em tempo muito menor do que a leitura manual.

“Mas o que o leitor recebe como resultado?”

A partir de cada página de jornal submetida para processamento, na etapa “Busca de termos”, é realizado o cruzamento de todos o conteúdo de interesse (palavras, frases, filtros, etc) com os termos verificados em cada página, para isolar o conteúdo de interesse de cada cliente e também para destacar o resultado de maneira visual. Dessa forma, uma página “grifada” é entregue assim 👇

A partir do processamento dos metadados de cada página, também é possível destacar termos “hifenizados” no texto, o que aumenta a qualidade da busca e resultado 👇

“Nossa, muito legal! Mas, como isso funciona?”

A arquitetura técnica desta solução utiliza tecnologia open-source e faz uso eficiente de cloud computing, baseado em Amazon Web Services, com foco em high throughput e operação de baixo custo, abordando conceitos como containers, serverless e spot fleet 👇

Nesta arquitetura, o uso de Docker containers, AWS Lambda, AWS S3 e AWS API Gateway é bastante explorado como elementos de processamento serverless para o pipeline de leitura de impressos. Para processamento OCR de todos os impressos recebidos, um ECS cluster em spot fleet, utilizando task queueing desenvolvido em Python + ferramentas open-source. Para armazenamento de documentos processados (texto, termos, metadados, etc.) e suporte à busca contextual, um ElasticSearch cluster em alta disponibilidade com políticas de backup automatizadas. Para gestão de configuração e armazenamento de métricas de processo (páginas/palavras verificadas, backlog, etc.), uma instância RDS for Postgresql em modo HA. Para sincronização e entrega dos dados processados (imagens, metadados), API Gateway + Lambda.

Para monitoramento ostensivo, um dashboard baseado em Grafana para acompanhamento das métricas de processamento em tempo real 👇

“Ok, bem bonito mas, o que a empresa ganhou com tudo isso?”

• Liberação do clipping para os clientes finais, em média, 60% mais rápido.
• Maior quantidade de jornais lidos e revisados.
• Revisão mais ágil e manutenção de alta qualidade de captura de termos.
• Redução de jornada (horas-extras) para produção maior.
• Processo de captura e revisão distribuída (operadores e leitores em home office)

Além dos benefícios ao negócio, alguns números sobre eficiência operacional:

• ~ 4500 páginas processadas por dia
• ~ 300 jornais diários
• Mais de 5GB de dados processados por dia
• Jornal de grande circulação (aquele lido em 1h por duas pessoas) processado e entregue, em média, em 4 minutos
• A operação da plataforma cloud tem custo médio mensal em 40% do rendimento bruto de um único colaborador (leitor)

Como parte de uma série sobre esta jornada, a partir deste, novos posts serão divulgados para detalhar as abordagens técnicas aplicadas nesta solução.

Até mais!

A metodologia DevOps foi criada utilizando os conceitos dos métodos Ágeis, para entregar um grande valor durante o processo de desenvolvimento de software, automatizando o release de features compipelines, para conseguir provar hipóteses mais rápido e assim se adaptar mais rápido às mudanças por meio de uma abordagem “fail-fast”. Essas mudanças são mais culturais do que técnicas, portanto é comum dizer que DevOps é cultura.

A implementação de DevOps acontece por meio da automação de processos, tendo muito forte dentro dessa implementação a reengenharia de processos da empresa. A implementação da parte técnica é simples e fácil se comparada com a mudança de comportamento das pessoas. Portanto, é bastante confuso o papel que um “Engenheiro/Analista DevOps” desempenharia, no meio dessa confusão, existem muitos SysAdmins e Analistas de Infra assumindo o papel de “DevOps”.

First things first, Lean é a base do Agile

A realidade não é tão feliz quanto parece. Depois da segunda guerra mundial, o Japão estava destruído e com poucos recursos, após ter perdido a guerra. Com uma quantia limitada de recursos, o país precisou se reinventar e sobreviver após uma época de forte depressão, durante essa época dois caras ficaram famosos pelo trabalho realizado dentro de uma empresa, que mais tarde teve o nome dedicado ao modelo que foi criado.

Esses caras eram Eiji Toyoda e Taiichi Ohno, que trabalhavam para a Toyota Motor Corporation. Foram os fundadores do modelo de produção Toyota, também conhecido como Toyotismo.

Toyota deu origem ao Lean

Lean é uma metodologia que ensina a otimizar os processos da empresa; end-to-end, para dar mais atenção às tarefas que entregam valor ao consumidor final, incentivando ao máximo a remoção de bottlenecks no processo, assim como a análise de tarefas que são desperdício (definidas pelos 3M) para que sejam identificadas e removidas.

Essas tarefas consideradas desperdício são classificadas como 3M dentro do Lean que representam: Muda, Mura, e Muri. Outro ponto importante a destacar no processo é a utilização do método nomeado Kaizen (continuous improvement), com foco em melhorar continuamente buscando atingir um nível de excelência em qualidade.

A qualidade faz parte da cultura japonesa, pois existe a crença de que um produto de qualidade traz o cliente de volta, mesmo que os produtos demorem mais para estragar, os clientes serão fiéis a eles, pois terão uma boa experiência. Antes mesmo de falarmos sobre user experience, eles já estavam pensando nisso.

Kaizen

Um mindset que ajuda a olhar para cada parte do processo exclusivamente e pensar nas melhorias, envolvendo as pessoas que fazem parte do processo, assim incentiva que haja a inclusão dessas pessoas nas decisões de mudança, já que:

• Fica muito mais fácil de aceitar uma mudança quando ela não é imposta (top-down);
• Há uma absorção maior das mudanças pelas pessoas, quando elas são incluídas no processo;
• As pessoas que são incluídas no processo trazem as suas preocupações e sugestões, que contribuem positivamente com a evolução da mudança, tornando a ideia mais robusta.

O processo de definição das melhorias por meio de Kaizen acontece (normalmente) na seguinte ordem:

1. Definir objetivos com base em dados;
2. Revisar o estado atual e desenvolver um plano de melhoria;
3. Implementar a melhoria;
4. Revisar a implementação e corrigir o que não funciona;
5. Reportar os resultados e determinar os itens a serem monitorados.

Esse processo é bastante chamado de PDCA: Plain-Do-Control-Act, que se resume em:

• Plan (desenvolver a hipótese);
• Do (executar um experimento);
• Check (validar os resultados);
• Act (refinar o experimento e recomeçar).

3M: Muda, Mura, Muri

Muda (desperdício)

Qualquer atividade que consuma tempo sem agregar valor ao consumidor final. Como por exemplo:

• produção em excesso;
• tempo parado (ocioso) no processo;
• defeito nos produtos.

É importante lembrar que existem níveis diferentes de Muda que podem ser ou não removidos com rapidez, e a classificação depende do tempo para remoção.

Um exemplo de Muda mais demorado é a descontinuação de um software legado que acaba tendo ciclos mais longos de release, causando tempo ocioso nos times, muitas vezes uma rotina de testes longa e manual.

Mura (desigualdade)

Atividades que são muito variáveis e imprevisíveis, gerando resultados diferentes em todas as execuções. Por exemplo: a execução de tarefas que não foram bem planejadas e acabam chegando com prazos rígidos. São executadas na correria, gerando um desgaste, desespero, e ainda por cima, ao terminar deixam as pessoas que executaram essas tarefas esperando (seja um feedback, ou então a confirmação de que está finalizado).

Muri (sobrecarga)

Exigir que as pessoas (ou os equipamentos) trabalhem além do limite, para atingir algum tipo de meta ou expectativa, gerando cansaço e consequentemente falhas durante o processo. Essas falhas são geralmente erros humanos causados pelo cansaço durante o trabalho excessivo.

Voltando ao Agile…

No ano 2000 um grupo de 17 pessoas se encontrou em um resort em Oregon para conversar sobre ideias que poderiam melhorar o fluxo de desenvolvimento de software. Depois de um ano de amadurecimento das ideias, essas pessoas se encontraram de novo e publicaram as ideias, que hoje conhecemos como: Agile Manifesto.

Os principais pontos são:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Vou me restringuir a explicação desses pontos com o ponto de vista DevOps, para não fugir (mais) do tema.

Individuals and interactions

over processes and tools

As pessoas devem receber o kit de ferramentas (tooling) apropriado para trabalhar e então serem empoderados para realizar seu trabalho. As interações entre pessoas é extremamente incentivada, para o compartilhamento de conhecimento e também para facilitar o fluxo criativo dentro dos times de desenvolvimento.

Um excelente exemplo de interação incentivada por meio de DevOps é o hábito de code review. Considerando que pequenas partes do software serão iteradas e aprovadas no pipeline passando por diferentes ambientes, de maneira automática, o melhor jeito de prevenir defeitos é por meio de code review.

Esse hábito traz benefício como:

• Compartilhamento de conhecimento no time;
• Observação do problema em diferentes pontos de vista;
• Engajamento no time;
• Redução no número de bugs.

Working software

over comprehensive documentation

Aqui existe um trick na questão do working software, um software que funciona não é “compilou, tá funcionando”. O software que funciona é o que atende aos requisitos do usuário; i.e. o software que resolve o problema e as dores do usuário.

Como o mercado é muito dinâmico, e evolui com grande velocidade, muitas vezes durante o projeto de desenvolvimento de software os requisitos mudam devido a fatores externos. Portanto, sabendo que não é possível prever todos os fatores, muitas gambiarras são feitas no meio do caminho e documentadas, para que o usuário final aprenda a lidar com as falhas, e executar os workarounds, gastando mais esforço do que seria necessário para realizar as tarefas por meio do software.

Entregar frequentemente software funcionando, de poucas semanas a poucos meses, com preferência à menor escala de tempo

Incentivando assim que hajam deployments tanto quanto o possível, para que as falhas aconteçam o mais cedo possível, permitindo assim que o impacto delas seja bem menor.

Fail-fast!

As falhas são compreendidas e incentivadas, pois faz parte do mindset entender que:

• Só erra quem faz;
• Falhas acontecem.

Portanto é melhor que as falhas ocorram cedo, enquanto o custo de correção ainda é baixo. Falhar em um ambiente controlado de testes, permite que a correção seja muito mais rápida (e barata) do que seria caso a correção acontecesse já em produção.

Para que essa abordagem tenha sucesso, existe a premissa de que os ambientes sejam cópias de produção, ou pelo menos que seja o mais próximo possível. Do contrário, haverão mudanças de comportamento no software entre os ambientes, inviabilizando o ambiente de testes.

Caso os ambientes sejam divergentes, a promoção de bugs para produção será muito frequente, causando falhas tarde, que são falhas caras.

Customer collaboration

over contract negotiation

Também é possível que haja um má levantamento de requisitos durante o início do projeto, pois muitas vezes o próprio cliente/usuário não conseguiu prever todas as funcionalidades necessárias.

Podemos descrever essa situação como:

• Do ponto A é possível ver apenas o ponto B;
• Do ponto B é possível ver o ponto C;

Portanto há um grande incentivo para que o software seja entregue em partes, continuamente. Colhendo assim os feedbacks do usuário sobre os próximos passos, seguindo os conceitos de prototipação evolutiva, que foram muito divulgados por meio do livro The Lean Startup.

Esse ponto faz muito contraste com o anterior, em relação à entrega contínua (continuous release), para que seja possível apresentar o protótipo e evoluir ele ao longo do projeto.

Saiba quem é o seu cliente/consumidor/usuário, e para quem você está fazendo o software, pois esse é o único jeito de conseguir entregar valor para esse cliente. Parte importante do processo de desenvolvimento de software é ser empático com os problemas do usuário, e entender de verdade qual é o problema a ser resolvido, e o resultado causado pelo impacto no desenvolvimento do software (geração do valor para o usuário).

Responding to change

over following a plan

Fazer um redesign dos requisitos durante o projeto é parte crucial para o sucesso do projeto. Será o único jeito de conseguir trazer para a mesa todos os problemas do usuário, e criar a melhor solução para todos esses problemas, pois só o usuário sabe dos reais problemas que ele enfrenta no dia-a-dia lidando com o software.

Com a entrega contínua de software junto com o monitoramento dos resultados, o processo de coleta dos feedbacks fica muito mais simples e rápido.

DevOps, DevOps, DevOps

Com a divulgação da palavra DevOps, existe muita gente falando sobre DevOps por aí. Existindo muita divergência no que é falado, e criando uma confusão grande sobre o tema. Acaba sendo muito comum se deparar com diferentes interpretações sobre o que é DevOps. Existe muito eufemismo na área, e gourmetização em cima do LinkedIn, com muitos SysAdmins por aí se dizendo DevOps, pois aprenderam a codar shell script dentro do Python.

Os benefícios da implementação de DevOps

Principais benefícios que uma companhia geralmente espera e encontra na adoção da cultura:

Releases mais rápidos e baratos

Como os releases serão frequentes, as entregas acabam sendo pequenas. Entregas pequenas trazem o benefício de aumentar a velocidade no ciclo de desenvolvimento (entregando sempre)

Suporte operacional melhorado com ajustes rápidos

Caso haja alguma falha durante a entrega, o impacto é menor pois a quantidade de modificações é pequena, assim como o rollback é rápido.

Melhor time to market (TTM)

O software será entregue muito mais cedo, quando ainda for um MVP. Os clientes serão integrados como parte do processo de desenvolvimento, trazendo insights e feedbacks para o time. Permitindo assim que haja uma velocidade maior de lançamento no mercado.

Produtos de qualidade superior

Como foi falado antes, falhar cedo impede que defeitos sejam entregues em produção

Assim como:

• Menor volume de defeitos no produto como um todo;
• Aumento na frequência de novas features e releases;
• Processos de desenvolvimento apropriados nos times, incluindo automação.

Agora que entendemos o POR QUE, vamos ao COMO

Continuous releases (integration, delivery, deployment)

Geralmente segue uma abordagem de versionamento de código (por meio do Git) utilizando branches específicas para cada ambiente.

Continuous integration

Execução automática dos testes unitários, integrados e também de qualidade de código na branch, para garantir que não houve quebra de funcionamento do pedaço modificado do código.

Continuous delivery

Empacotamento do software que está testado e aprovado, para deixar ele em algum lugar que seja possível fazer um deploy posteriormente. Exemplos são libs entregues em repositórios para ser integradas no código durante o próximo update e deploy de código

Continuous deployment

Após conseguir completar todos os passos anteriores, é possível fazer deploy automatizado direto nos ambientes, quando o time estiver com mais confiança em relação às ferramentas que testam, assim como com a questão de assumir riscos e entender que existe a possibilidade de falhar em ambientes de teste, sem preocupações.

Configuration (e/ou Infrastructure) as code

Para que seja possível testar o software com assertividade, e entender que ele irá transitar entre os ambientes sem mudar de comportamento, é de extrema importância que as configurações sejam também código. Isso permite que as configurações sejam também versionadas, acompanhando o código. Garantindo também uma uniformidade entre os ambientes, que possibilita:

• Redução nos custos de manutenção, tendo um ponto único para olhar e entender o funcionamento do sistema;
• Facilidade para recriar a infraestrutura, caso seja necessário mover tudo para outro lugar, isso pode acontecer com poucas interações manuais;
• Permite que haja code review da infraestrutura e das configurações, que por consequência traz uma cultura de colaboração no desenvolvimento, compartilhamento do conhecimento e aumenta a democratização da infra;
• Documentação como código, ajudando novos membros do time a terem um warm up mais rápido.

Esses pontos foram bem estressados pelo time da Heroku, e deram origem ao famoso paper: The Twelve-Factor App. Uma leitura muito boa para a explicação dos benefícios sobre gerência de configuração.

Monitoramento e self-healing

Ao fim de todo o processo de entrega, o software deverá estar sendo monitorado, para que não seja necessário esperar um report externo de falhas, garantindo que as ações sejam pró-ativas e não reativas.

Garantir que o monitoramento esteja maduro, também nos permite automatizar a parte de reação aos alertas, criando um sistema de self-healing em que ações (scripts) são executados para corrigir possíveis falhas conhecidas na infraestrutura. Permitindo assim que todos possam dormir tranquilamente de noite, sem ter que ficar preocupado com o plantão tocar e ter que ler documentação de madrugada. (Se você já teve experiência com isso, sabe com certeza o quanto é ruim).

Escalando assim apenas os casos que forem extremas exceções (erros não conhecidos/esperados) no processo para o plantonista atuar, garantindo uma maior saúde na operação.

Automação de processos

Todo o processo que estiver causando Muda é alvo de automação, para que as pessoas possam trabalhar com mais agilidade. Bons exemplos de processos que costumam ser automatizados são:

• Deployment;
• Self-healing (resiliência do sistema em resposta às anomalias);
• Renovação de Certificados;
• Testes;
• Monitoramento (com auto-discovery);
• Governança de usuários;

DevOps toolchain

Uma combinação de ferramentas para facilitar a manutenção e operação do sistema, seguindo o seguinte fluxo:

Obs.: Qualquer semelhança com o PDCA é mera certeza.

• Plan: Fase de planejamento do projeto, em que são coletados os feedbacks para levantamento de requisitos, e criação do backlog;
• Create: Criação de um entregável (para validar uma hipótese), como um MVP;
• Verify: Passar o entregável para a fase de testes;
• Package: Empacotar o entregável (build) para conseguir colocar ele em algum ambiente de testes;
• Release: Fazer o deployment do entregável empacotado;
• Configure: Realizar a configuração do entregável no ambiente de testes, tentando chegar o mais próximo possível do twelve-factor app.
• Monitor: Após fazer o deployment no ambiente, acompanhar as métricas de negócio e infraestrutura, para garantir que está tudo funcionando conforme o esperado.

Conclusão

Durante a implementação dessas técnicas é possível observar melhoras no processo de desenvolvimento, os ganhos mais notáveis são:

• Melhoria no engajamento do time;
• Compartilhamento de conhecimento;
• Redução de bottlenecks;
• Mais tempo livre para realizar trabalho que realmente importa (agrega valor para a experiência do usuário ou gera impacto);
• Maior confiança ao entregar software.

E 2019 finalmente começou…

O mercado de tecnologia se tornou um grande terreno de oportunidades e grandes desafios para os “mais corajosos”, pessoas ou instituições engajadas na busca pela transformação definitiva dos meios e relações de consumo e, porque não, da própria sociedade.

Tecnologia? Ela está em todos os lugares, permeando (quase) tudo que remete à inovação e transformação do nosso modo de pensar, agir e principalmente consumir. Em ambiente tracionado pela Nova Economia, não há mais lugar para a criação de ofertas desconectadas com o real interesse do consumidor, tão pouco que produtos e serviços sejam forjados em padrões correntes e que serão “eternos”. Tudo muda, e cada vez mais rápido!

Se tudo muda, o que há de comum a tudo isso e que pode ser explorado para o alinhamento à mudança e aderência ao público consumidor cada vez mais ciente e capaz de forjar a própria oferta?

A resposta: DADOS

A tecnologia tem papel fundamental na habilitação de novas oportunidades, sendo primordial como eixo de produção do principal ativo digital das pequenas às grandes empresas, presentes ou não na Internet: O dado. Clicks em um site, deslocamento das pessoas (e doenças), hábitos de compras, posts nas redes sociais, medições climáticas, imagens, o choro de uma criança, tráfego urbano… Todos estes eventos descrevem fenômenos e produzem dados em quantidade, variedade, velocidade e complexidade exponencialmente crescente. Dados que, combinados ou não, são capazes de gerar insights para definição de novos e disruptivos negócios.

Por uma nova proposta de geração de valor, dirigida por dados, nasce a Datenworks!

Quem somos?

A Datenworks é uma startup nascida e guiada pela Transformação Digital e valores fundamentais da Nova Economia, onde “foco no cliente” é o norte das ações de inovação em tecnologia e soluções dirigidas por dados.

Nós, da Datenworks, acreditamos que “dados” são a principal e definitiva commodity do mundo digital. Vence e prospera aquele que melhor lida e explora as vantagens que a engenharia e a ciência de dados podem oferecer.

Dados estão em todos os lugares e preenchem uma lacuna fundamental rumo à inovação. Acreditamos que a tecnologia tornou possível alcançar este novo patamar mas, para muitos, ela permanece distante, complexa, de altíssimo custo, um ativo elitizado. A Datenworks nasceu para democratizar o acesso à tecnologia de dados, de startups à grandes empresas, de forma simples e convidativa ao progresso de modelos de negócio.

O que fazemos?

Big Data

• Volume, variedade e velocidade são aspectos fundamentais de Big Data.
  Somos especialistas em projeto, construção, implantação e manutenção de sistemas/plataformas de big data conhecidos como datalake, a partir de tecnologia open source padrão de mercado e compatível com implantação em nuvem computacional ou sistemas de datacenter on-premises, promovendo visão centralizada dos dados, escalabilidade linear de processamento e agilidade para exploração e análise.

Governança de Dados

• Uma vez de posse dos dados, é preciso conhecê-los mais e melhor. Governança envolve análise e proposição de processos e práticas de governança dos dados disponíveis em seu datalake, permitindo que a empresa possa tirar o máximo de valor dos dados, a partir de técnicas como data lineage, data quality, gestão de metadados, dicionário de variáveis, dentre outros. Além disso, é papel da Governança de Dados o resguardo de informações ditas “sensíveis” ou “privadas”, no tocante aos variados e recentes mecanismos de proteção de dados pessoais, como a LGPD e a GDPR.

Segurança da Informação

• Não basta ter os dados, tão pouco conhecê-los, se os mesmos podem estar expostos ao uso não autorizado. Processos de segurança são fundamentais para garantir o uso escalável e confiável dos dados e envolvem técnicas de criptografia no armazenamento e transporte, controle granular e auditoria de acesso, segurança de perímetro, autenticação e autorização integrada.

Robotic Process Automation — RPA

• Um dos fatores essenciais para o alcance de escala de operação das empresas, em níveis jamais vistos ou sequer imaginados há pouco tempo, é o uso amplo de automação. Milhares de tarefas de ciclo repetitivo, realizadas por humanos, podem ser realizadas de forma automatizada por robôs de software, com retorno percebido em melhor qualidade de serviços, aumento de conformidade, velocidade e eficiência, da mesma similar aos processos e controles automatizados nas frentes de TI da empresa, com uso de Cloud Computing, DevOps e Quality Assurance (automação de testes).

Quer conhecer melhor o que fazemos? Tem uma necessidade/desejo a ser acelerado por dados? Não sabe por onde começar? Entre em contato conosco e será um enorme prazer ajudar seu negócio a prosperar no universo data-driven :)

Um abraço!