DevOps Anti-Patterns

DevOps is word to use for many ways, this is happen because it ’s a fashion buzzword. Then, as such is common to use DevOps incorrectly, I made a presentation show some mistakes in to use. It isn’t a hunt witches but it’s why happen and what to do correctly.

The presentation has two parts, first I show examples as DevOps is applied wrongly and some thoughts what would be great. The second part is a Fishbowl meeting and I confession was a awesome experience to share knowledge each other.

DevOps Anti-Patterns from Fernando Ike

Thanks organization of Agile Infrastructure track and TDC for allow a excellent opportunity to talk about that.

Zapzaps e os grupos de usuários

“Pessoas adoram conviver em grupo”, é uma afirmação comum deste século 21, outra é “As pessoas cada vez mais sente-se mais sozinhas”. Talvez uma frase que junte as duas anteriores seja “As pessoas adoram viver em comunidades virtuais”. Usando um exemplo mais específico, relacionado à tecnologia.

A maioria de nós (humanos) que trabalham com Tecnologia da Informação gostam de estar se relacionando com outros que tem os mesmo interesses. Pessoas que gostam de uma marca (Apple, Oracle, etc.), software (Java, Docker, Python, OSX, etc), “Ideologia” (Software Livre, Opensource, etc.). Restringindo para somente para o mundo virtual, desde o início dos tempos (início da internet) muitos de nós entravam em salas de bate-papo dos BBS, depois em canais de IRC para conversar sobre as coisas que gostávamos ou achávamos divertidos. Passando pelas listas de discussão por email, fóruns web (Facebook) e hoje estamos nos grupos de IM de celulares: Whatsapp, Telegram, Actor, etc.

Não listei todas mas provavelmente você deve participar de um grupo em uma outra rede social não listada aqui e que você deve interagir bastante com os outros membros. Em 5 anos ou menos surgirão grupos organizados em novas rede sociais e alguns dirão que o Whatsapp e demais são coisa de idoso, a onda é a rede/software Foobar.

Lendo um artigo sobre como seria as redes sociais do futuro, a previsão é que a maioria delas serão apenas vídeo. Mais ou menos como o Snapchat é atualmente, mas como será a governança desses grupos?

Esse assunto surgiu porque o dono do grupo de usuários Debian BR apagou o grupo do Telegram.

telegram_debianbr

Dono grupo Debian BR?

Sim!

Isso não deveria ser gerenciado por mais pessoas?

Sim!

Grupos de usuários podem ou não relacionar-se diretamente com os “donos” das tecnologias. Também podem ser grupos de usuários oficiais ou não, isso depende de como é política do projeto. Debian, PostgreSQL e Docker são bons exemplos de forte relacionamento com as comunidades, sendo que eles se organizam de maneiras bem diferentes.

Como mais pessoas poderiam gerenciar os grupos de usuários nos Zapzaps?

Olhei rapidamente para Whatsapp, Telegram e Actor, nenhum deles pode compartilhar ou delegar o perfil de gerenciamento do grupo. Outros como Slack ou Hipchat pode-se ter mais administradores nos grupos. Apesar deles parecem bastante com os Zapzaps, eles são baseados fortemente no canais IRC. Os canais IRC podem ter mais de um “administrador” e outros perfis.

O conteúdo da maioria das listas de discussão são indexadas pelos buscadores ou podem ser armazenados na grande máquina do tempo internética chamada Internet Archive. Ou seja, elas podem ser facilmente encontradas para consulta. Infelizmente no momento nenhuma das Zapzaps tem uma forma de pesquisar o conteúdo para uma consulta futura.

Antes de você achar que estou dizendo que as listas de discussão são a melhor coisa para os grupos de usuários se organizarem e devemos ficar preso neste tipo de comunicação. Mas acho que os Zapzaps podem suportar duas funcionalidades das listas de discussão e também os fóruns:

1 - Pesquisar o histórico do grupo

2 - Mecanimos de controle do grupo como: múltiplos administradores, etc.

As listas de discussão ou rede sociais baseados no IRC talvez ainda serão a melhor forma de se organizar um grupo de usuários porque ainda não temos uma tecnologia massiva que pode pesquisar uma citação de vídeo. Talvez um bom exemplo seja uma discussão sobre a organização de um evento, é impossível acompanhar todas mensagens de textos enviadas, a maioria de nós (não super-humanos) não consegue ler todas.

Imagine ouvir ou assistir todas as mensagens? Provavelmente, muitos de nós gostaria de pesquisar trechos específicos de cada vídeo para usar como citação numa resposta em vídeo. Por enquanto, não existe uma tecnologia usada massivamente que permita pesquisar o que foi falado em vídeo. Quando isso acontecer, provavelmente as listas de discussão deixarão de ser usadas e a Skynet estará entre nós…

Obs. No Actor é possível pesquisar mensagens no histórico do grupo.

Identifying Web Performance bottlenecks

Web Performance

This text came about after a friend sent me a email asking if I know of a good article in Brazilian Portuguese on how to identify Web Performance bottlenecks. Unfortunately, I didn’t remember any, so then I wrote some points to get him started.

Web Performance is a vast and deep subject. If you have references, corrections or even tips, please feel free to comment here or send me a email.

Backend/Front-End

When it comes to the internet world, backend is everything that is processed by the site (web servers, databases, APIs, etc.). Front-end is everything that is processed by web browsers. This is relatively easy to identify; most site monitoring services (Syntethic monitor) use the TTFB (Time to First Byte) as part of their measurement metrics. A high value in TTFB can happen when the backend delays in delivering HTTP responses. E.g.: Dynamic pages with heavy data processing.

When internet world, backend is everything process for site (web servers, databases, APIs, etc.). Front-end is everything that process by web browsers. This is relatively easy to identify, the most site monitoring services (Syntethic monitor) use the TTFB (Time to First Byte) as part of their measurement metrics. A high value in TTFB can happen when the backend is delaying to delivery HTTP responses. E.g.: Dynamic pages with heavy data processing.

The high value of TTFB can occur when your monitoring test is far away from your site. A simple example is my site, when it was tested both in the USA and Sao Paulo.

Webpagetest - TTFB

Country Time
EUA 0,121s
Brasil 0,325s

This’s a real problem for brazilian user sites hosted in USA provides. The network latency at least 100 milliseconds, some companies prefer to clone a part of their servers architecture in Brazil to decrease the latency. So, considering latency, a good value to TTFB for Brazilian sites hosted in USA is 300 milliseconds, if the sites and users are the same region or country, the good value is +- 130 milliseconds.

the high TTFB

TTFB is a really good metric to indicate that some problem in backend, it’s a trigger to start a research to identify bottlenecks such as servers overloads, misconfiguration, slow responses of third-party APIs, bad choose of architecture definition, etc.

SSL/TLS

It’s common sense that’s good idea to provide cryptography for users sites, but few people really important to implement SSL/TLS and less yet to provide good performance when sites are using cryptography. It seems a minor stuff but it didn’t, I saw sites just to complete TLS handshake takes almost 1 second. A good value to SSL handshake is under 100 milliseconds.

TLS/SSL do Github SSL Github

TLS/SSL das listas do PostgreSQL Brasil SSL PostgreSQL Brasil

I did comparative test SSL handshake of Github homepage and mail list homepage of PostgreSQL Brasil. It’s really impressive as a good infrastructure and tweak TLS configuration can provide a good performance. Obliviously, Github was better than PostgreSQL Brasil (my fault), at last they have a lot of money. :)

DNS

Probably, DNS server is the most important network service that pay less attention. Nevertheless, it’s important to think if DNS is being a bottleneck. It’s good performance when browsers resolve DNS less 70 milliseconds. For sites with users around the world, consider use a DNS service with servers locate in more regions or countries.

DNS www.fernandoike.com

Others

TTFB can be anything, then, think about to use a FLOSS Monitoring software or even to pay someone. Really important, you need to plan what you will monitor and what metrics you will use, or you don’t want to dive in the data deep-sea without any way to rescue.

When Monitoring Service has a good implementation, it can show where are bottlenecks and many other views how your system or sites are good health.

Front-End

Even though that root case is the site infrastructure, somethings are just Identifying to analyze a web browser. Because, browsers allow whole context to open a web page and still haven’t a software that simulate exactly the browser behavior (Phamthonjs is almost there).

Compressão (gzip)

Any web server HTTP response is text/plain type, they have to be compression by gzip (RFC 2616). If you want further about this subject, read my post “CDN ranking and gzip compression (only portuguese)”. But, if you don’t time to learn portuguse or wait me write in English, below a brief note.

If Content-Type HTTP header contains any value below, consider enable compression in your web server.1

  • text/html
  • application/x-javascript
  • text/css
  • application/javascript
  • text/javascript
  • text/plain
  • text/xml
  • application/json
  • application/vnd.ms-fontobject
  • application/x-font-opentype
  • application/x-font-truetype
  • application/x-font-ttf
  • application/xml
  • font/eot
  • font/opentype
  • font/otf
  • image/svg+xml
  • image/vnd.microsoft.icon
  • text/x-js

The my site previously had a good result for compression in the Webpagetest.

Gargalos gzip - nota

Gargalos gzip - percentual

Web Browser cache (Cache-Control)

Cache-Control is a of most important HTTP header because it says to web browsers what they can do local cache or not. The most web develop frameworks provides a good management under Cache-Contol, they add the HTTP header automatically for images, javascripts, css and webfonts.

I didn’t my TLS homework this test, because my blog had a lot of third-party content (Linkedin and Slideshare). Unfortunately, they don’t use Cache-Control correctly, and this does the Repeat View isn’t good to. The Repeat View could have 40% less HTTP requests.

Repeat View

Repeat View is the second visit of user to site. E.g.: Every day I read the The Wikipedia home page to read new articles or updates.

Cache-Control HTTP Header

Third-party

Here is the most difficult to gain performance, you don’t have control of Third-party content. My website doesn’t have commercial goals, so readers of my website can be patient but users sites like ecommerces, news portal, etc. want to consume as soon as possible. As you read above, Slideshare as Third-party for my site is worst because they don’t use Cache-Control header.

There are many tricks to improve performance site for Third-party HTTP requests like defer, asynchronous HTTP requests, etc. Often have your mindset, performance and User eXperience are the most important for yours users.

Third Party HTTP Requests

Ian Murdock Legacy

Buzz I really want to know what did happen but at the moment I prefer to remember how Ian Murdock influenced me.

Inspiration Debian is a really cool name. Whenever I do a presentation about Debian, I always explain how the name came about (Debra + Ian).

Abnegation Ian Murdock could be a commercial linux distribution but he didn’t do. It’s impressive because the common sense was to create Linux distribution by a person or a very closely group. Debian was the first Linux distro to use open development; anyone could contribute to Debian. If he had founded a commercial distro, it probably would have been something like Red Hat.

Ambitious In the first The Debian Manifesto, he wrote “It is also an attempt to create a non-commercial distribution that will be able to effectively compete in the commercial market.”. Even now, to create a non-profit project to compete in the commercial market it’s a huge challenge and he did.

Kept moving forward He could have just stayed as the Debian leader, but he worked in the other projects and companies as well. At least for me, it’s really cool to always embrace new challenges and increase our knowledge.

To Beyond and infinity

10 Anos do PGBR - Listas

Logo_PGBR

O Telles lembrou dos 10 (17) anos do PostgreSQL Brasil, meus dois centavos são sobre os números das lista de discussão do PostgreSQL Brasil. Desde 2006, as listas de discussão estão hospedados em servidores dedicado.

Um levantamento rápido dos emails das listas até 2015 deu os seguintes números:

  • De 2006 à 2015 foram enviados 49.002 emails.
  • 2008 foi o ano que mais foi enviado email: 9.322
  • 2014 foi ano que menos email foi enviado: 2.523

Raking_ano

A queda de emails nas listas reflete os problemas de instalabilida que ocorrem nos últimos anos (2013-2015). Ela foi um efeito colateral da migração para contêineres (Docker), o Logrotate parava o serviço do Mailman e não conseguia reiniciá-lo. O problema ocorria porque as imagens (de contêiner) baseadas no Debian e derivados alteram a Policy-rc.d, a alteração é para que a instalação e/ou atualização de pacotes não reiniciem automaticamente os serviços. O (gambiarra) workaround foi alterar o script de rotação dos logs, removendo invoke-rc.d para /etc/init.d/comando.

Desde Agosto de 2015 às listas do PostgreSQL Brasil não tiveram mais problema de disponibilidade, reflexo disso é o aumento de emails nas listas. Também contribuiu para o aumento a conferência PostgreSQL Brasil em Porto Alegre.

Ranking_2015_mes

Para terminar este texto, um ranking dos participantes mais ativos das listas em 2015.

Ranking_top10_2015

Choosing a software name

We’re a meeting discuss how to run a tiny project. The project was a proof a concept about a new possible service and we had been think to buy a new software tool until the dialog below comes.

homerhammer

Joe: We need to prove if this idea is possible to prove is turn a good service.

Zee: Sure! I can develop a script to test it.

Joe: Then, we have to give a name to this software.

Zee: Why? It’s just a script.

Joe: C’mon, the awesome services began as a prove of the idea.

Zee: Ok, let’s we think about it.

Zee: I had a script a long time ago that I called homer.

Joe: Homer? Why?

Zee: It was lazy, unfixable and unstoppable.

Joe: Wow! Homer Hammer! Homer Hammer!

Zee: Homer Hammer?

Joe: For sure! It’s same idea but with more power devastation.

Identificando os gargalos de sites

Web Performance

Este texto nasceu de um email de um amigo perguntando se existe algum material com o básico para identificar problemas de performance (gargalos) de sites. Não lembrei de nenhum, então segue alguns itens mais básicos que podem ajudar a encontrar porque um site está lento.

Web Performance é um tema vasto e muito variado, se tiver referências, correções ou mesmo dicas, comente ou mande email. :)

Backend/Front-End

No mundo internético, Backend é tudo que é processado pelo site (servidores web, banco de dados, APIs, etc). Front-end é tudo que é processado pelo navegador web.

Isso é relativamente fácil identificar, a maioria dos serviços de testes de sites (monitoramento sintetico) usam a métrica TTFB (Time to First Byte). TTFB alto pode acontecer porque a infraestrutura do site está demorando para responder. Exemplo: Sites com páginas dinâmicas que precisam processar muita coisa para gerar a homepage de um site.

O TTFB alto também pode ser que o teste está sendo executando num local muito distante da infraestrutura do site. Exemplo disso é meu site ao ser testando no Brasil e nos EUA.

Webpagetest - TTFB

País Segundos
EUA 0,121s
Brasil 0,325s

Isso acontece porque o servidor do meu site está no EUA, um número aceitável para um site que está nos EUA e os usuários no Brasil é em torno de 300 milissegundos.

Se o site e os usuários estiverem nos EUA, o valor considerado bom é abaixo de 130 milissegundos.

TTFB alto

Pode ser várias coisas, um banco de dados com alto tempo de resposta, uma API conectada ao site terceiro, balanceador de carga com algoritimo errado, etc.

SSL/TLS

Um ponto que poucas pessoas verificam é a parte de criptografia (HTTPS). Já vi sites que o handshake de SSL/TLS para abrir a conexão HTTPS era próximo de 1 segundo, o recomendável deveria estar abaixo de 100 milissegundos.

TLS/SSL do Github SSL Github

TLS/SSL das listas do PostgreSQL Brasil SSL PostgreSQL Brasil

Incrível como no teste com o Github é rápido para fazer o handkshake SSL, contudo o mesmo teste no site das listas de discussão do PostgreSQL Brasil tem um desempenho sofrível (culpa minha!).

DNS

Parece incrível, contudo tem muito site que tem servidores DNS sofríveis em desempenho. Se a resolução DNS não for rápida (abaixo de 50 milissegundos), ele pode ser a causa do TTFB alto.

DNS www.fernandoike.com

Outros

Como comentei um pouco mais acima, qualquer parte da infraestrutura de um site pode impactar no TTFB. Se estiver desconfiado que alguma na infraestrutura do site seja o gargalo, vale à pena considerar usar alguma coisa como New Relic para instrumentar os serviços e ver o que está enfileirando.

Front-End

Ainda que a causa seja a infraestrutura do site, só é possível identificar ao analisar com um navegador web.

Compressão (gzip)

Qualquer resposta do servidor do site que for do tipo text/plain deve ser comprimida por gzip (RFC 2616). Eu escrevi um texto sobre isso no meu blog, recomendo lê-lo.

Mas estiver com pressa (imagino que sim!), basicamente é o seguinte: se na resposta HTTP tiver o cabeçalho Content-Type com algum dos valores abaixo, deve-se considerar habilitar a compressão.

  • text/html
  • application/x-javascript
  • text/css
  • application/javascript
  • text/javascript
  • text/plain
  • text/xml
  • application/json
  • application/vnd.ms-fontobject
  • application/x-font-opentype
  • application/x-font-truetype
  • application/x-font-ttf
  • application/xml
  • font/eot
  • font/opentype
  • font/otf
  • image/svg+xml
  • image/vnd.microsoft.icon
  • text/x-js

O meu site (no momento) está com um bom desempenho para compressão no Webpagetest.

Gargalos gzip - nota

Gargalos gzip - percentual

Cache no navegador web (Cache-Control)

O cabeçalho Cache-Control diz para o navegador web o que ele pode ou não cachear. O bom uso dele faz com que o site tenha um consumo menor de banda de rede. É muito comum usá-lo para fazer cache de imagens, javascripts, css e fontes no navegador web.

O meu site não faz o bom uso dele no teste que fiz no Webpagetest. Ao abrir o link abaixo você verá que a pontuação é baixa porque meu site usa conteúdo de terceiros (Linkedin e Slideshare), eles infelizmente não usam o Cache-Control.

Ainda usando meu site como exemplo, se o Cache-Control fosse bem usado, a quantidade de requisições (request) HTTP no Repeat View seria bem menor. O Repeat View no meu blog tem 23 e ao menos deveria ser em abaixo de 40%.

Repeat View

Simula o acesso de navegador web com parte do conteúdo cacheado pelo computador do usuário, seria como se o usuário acesse o site pela segunda vez.

Cache-Control HTTP Header

Terceiros

Muitos sites usam conteúdo de terceiros nas suas páginas, geralmente conteúdo de redes sociais ou publicidade. Esse conteúdo por impactar no desempenho do site significativamente se for abusado o uso dele.

Meu site tem mais requisições do Slideshare do que dele próprio, portanto, meu site é totalmente dependente do desempenho do Slideshare para ser rápido para usuário. Existem algumas formas de contornar usando coisas como defer.

Como não vivo do site, posso conviver mas sites que são ecommerce ou portais de notícia não podem conviver com esse “gargalo”, precisam fazer que o as requisições HTTP para terceiros (parceiros) sejam feitas depois que Document Complete (ou o evento Onload) esteja concluído.

Third Party HTTP Requests

Building Debian images by jigdo

A friend asked me how to got a Debian Old Image, she wanted to download Debian Squeeze DVD image. Unfortunately, it’s impossible to download by Debian-CD mirror because Squeeze isn’t more maintainer. So, it’s possible to get a Image by Debian-CD primary server but it’s locate in Sweden. Nothing problem, right? Well, She lives in Brazil and the download time is a little bit more than 8 hours.

A good tool to “download” a Debian image is the Jigdo. It’s a program to synchronize repositories and generate Images. It get packages and build a image locally in your computer.

I made a simple test, I used jigdo to “download” the first Squeeze DVD by brazilian repository (Unicamp) and compare with a download image by PR (Primary Server). The difference was huge, PS download took a long time to finish (8 hours) and Unicamp mirror finished in 100 minutes.

Well, let’s go to practice.

Install jigdo

#aptitude install jigdo

Downloading and building image

The jigdo file (.jigdo) is simple list with all packages and hash of a instalation image. You need it to start the downloads. In this case, I used jigdo file to build first Squeeze DVD.

$jigdo-lite http://cdimage.debian.org/cdimage/archive/6.0.10/amd64/jigdo-dvd/debian-6.0.10-amd64-DVD-1.jigdo

Before to begin download, jidgo need some arguments. Fill arguments of your preference but remember that the argument more important is the mirror. If you have doubt what’s mirror is more fast, you can use netselect-apt to discovery. For my test, I’m used Unicamp mirror (http://debian.las.ic.unicamp.br/debian).

My jigdo-lite conf file.


$cat ~/.jigdo-lite
-------
jigdo=''
debianMirror='http://debian.las.ic.unicamp.br/debian/'
nonusMirror=''
tmpDir='.'
jigdoOpts='--cache jigdo-file-cache.db'
wgetOpts='--passive-ftp --dot-style=mega --continue --timeout=30'
scanMenu='

Nice, huh?

Take a coffee and forget to download Debian images using others programs (curl, wget, etc.). :)

FISL 16

fisl16.png

FISL 16 aconteceu algumas semanas atrás… e depois de nem tão rigoroso inverno consegui rascunhar alguma coisas sobre o evento.

Impressões

Como sempre, sempre bom rever os amigos e conhecidos de inúmero projetos que participam. O evento não estava tão lotado como nos últimos anos que participei mas mesmo sim acredito que teve um bom público.

A internet até que funcionou razoavelmente bem, o wifi do evento era usável a maior parte do tempo e também gostei das palestras que assisti. Curti demais participar da Mini-Debconf realizada durante o FISL, fico feliz que em 2015 no Brasil serão (no mínimo) 3 Micro/Mini-Debconf. :)

As minhas apresentações

Este ano fiz duas apresentações no FISL16, uma sobre Web Performance e a outra sobre Management 3.0. A apresentação de de Web Performance foi a última vez que apresentei (acho), fiz algumas pequenas atualizações e acréscimo de exemplos que a deixou com +- 100 lâminas (slides). Já tem material suficiente para escrever um livro (quem sabe…). ;)

A apresentação sobre Management 3.0 é sobre como foi descobrir que usamos (equipe de TI que participei) esse conceito antes de saber que existiu um nome. Eu descobri Management 3.0 depois de participar de um curso de Scrum com Manoel Pimentel, isso foi alguns anos depois que já não era mais gerente. Ele me ajudou bastante para avaliar os erros e acertos como gerente. Recomendo para quem se interessar desempenhar o papel de líder de equipe ou chefia a estudar um pouco mais sobre tema.

Um milhão de usuários simultâneos

Um milhao de usuários simultâneos

O vídeo da apresentação pode ser acessado por aqui e aqui.

Management 3.0

Management 3.0 - a vida pós-agilidade

O vídeo da apresentação pode ser acessado por aqui.

Eventos em maio de 2015

Essa semana estarei participando de dois eventos como palestrante.

Devcamp

O Devcamp é a “A maior conferência de desenvolvimento de software do interior São Paulo” e esterei apresentando sobre a minha experiência em migrar para Docker. Docker é novo buzzword um projeto de automação de deploys de aplicações dentro de contêineres. Se estiver por lá e quiser tomar um café, estarei a disposição.

Meetup Germinadora

Provavelmente é a última vez que apresente essa palestra sobre Web Performance (“Um milhão de usuários simultâneos”). Não que eu não goste de falar sobre o tema, pelo contrário (gosto bastante)! Tem algumas partes específicas dessa apresentação que quero abordar numa próxima vez.

Se estiver de bobeira por aqui em São Paulo, passe por lá.