O papa-filas e o round-robin de DNS...

Dando seqüência ao tema "balanceamento de carga", vou agora mostrar os tipos mais comuns e suas vantagens e desvantagens, de forma a suprir o leitor com subsídios para uma escolha adequada ao seu caso.

1) Balanceamento por Round-Robin de DNS

O algoritmo de "round-robin" não é nenhuma novidade para profissionais de informática. Em qualquer curso de faculdade ele é assunto freqüente.  É simplesmente uma lista, enfileirada, em que os elementos vão, um a um, assumindo certa posição. Ao chegar no último elemento, o processo reinicia com o primeiro elemento. O DNS (Domain Name System) é uma forma de traduzir endereços de sites em seus respectivos IPs, por exemplo: www.google.com.br vira 74.125.234.159. O balanceamento de carga via round-robin de DNS funciona redirecionando alternadamente o usuário para uma lista de servidores, cada vez que ele acessa a mesma URL pelo navegador. Ou seja, há mais de um IP respondendo a uma mesma URL, só que de forma alternada.

Funciona de maneira muito similar ao "papa-filas" do supermercado, onde cada cliente entra numa única fila e ao final é direcionado para uma das gôndolas de pagamento disponíveis.

Se forem três servidores de aplicação, cada vez que o usuário recarregar a página no navegador, será direcionado para um dos servidores. Se chegar no último servidor e recarregar a página, será redirecionado novamente ao primeiro servidor.

Essa é uma forma bastante simples de balanceamento, que não leva em consideração a carga de cada servidor de aplicação, ou seja, não é um balanceamento ótimo, porque uma máquina lotada vai continuar recebendo usuários. Além disso, caso uma das máquinas falhe e fique fora do ar, ela mesmo assim ainda estará participando da fila. E usuários serão redirecionados para ela assim mesmo, recebendo a mensagem de que o servidor está fora do ar. Em outras palavras, um certo grupo de usuários cairá na máquina que está ruim.

Apesar das desvantagens, é uma forma extremamente fácil de implementar e é recomendável que ela exista em conjunto com outras formas de balanceamento.

No próximo post falarei sobre balanceamento de carga por cluster.

Quantidade pode ser melhor que qualidade? Entenda como funciona o balanceamento de carga.

Há alguns anos atrás, participei de um projeto de um sistema que tinha uma previsão de alto número de usuários simultaneos pela rede. Sugeri ao líder do projeto que fizesse um grupo de servidores de aplicação, fazendo balanceamento de carga entre eles, ou seja, montar um conjunto de dois ou mais computadores rodando a mesma aplicação, que dividissem o trabalho de atender àqueles usuários do serviço.

 

O líder do projeto não adotou a sugestão, argumentando que "tínhamos um servidor parrudo", com muita memória e vários processadores, capaz de suportar tamanha demanda. Contra-argumentei que, apesar de toda a indubitável capacidade do servidor, ele era um só. E se falhasse, o sistema ficaria fora do ar.

 

Mas, infelizmente, o líder do projeto não tinha visão orientada à otimização. E disse que o que deveríamos fazer era preparar um servidor de contingência. A visão dele era assim: "Temos um servidor que aguenta o tranco. Mas, no caso de não aguentar, colocamos outro, igual, para assumir a questão".

 

O resultado da história foi que o sistema foi posto no ar dessa forma. E o tal servidor "parrudo", à medida que o número de usuários aumentava, foi ficando lento, lento.... Até que chegou uma hora que o sistema caiu. E foi aquela correria! Inicialmente reinicializou-se o servidor várias vezes, mas os usuários retornavam (obviamente) e o sistema caía de novo.

 

Ligou-se a contingência. Ficou assim: O primeiro servidor entrava no ar. Os usuários acessavam o sistema, até que ele caía. Aí os próximos usuários eram direcionados ao segundo servidor, que também entupia e caía.

 

O tal líder do projeto culpou a tudo e a todos. Disse que o sistema operacional não prestava, reclamou do software do servidor de aplicação, da linguagem em que foi desenvolvido o sistema, maldisse o fabricante dos processadores do servidor, enfim, criou uma porção de desculpas para a coisa não ter funcionado. Mas em nenhum momento cogitou a hipótese de estar errado.

 

Sua vontade era reescrever o sistema em outra linguagem, funcionando sob outro sistema operacional, mas permanecendo o ambiente de um único servidor com outro de contingência.

 

Ele tinha o apoio da empresa, que confiava na sua competência técnica. E realmente ele tinha muita competência técnica, inegavelmente. Mas lhe faltava algo de igual importância: Maturidade.

 

Bem, o sistema ia pro ar uma vez por ano. Durante dois anos permaneceu assim. Funcionava mal, os usuários tinham uma péssima experiência e havia um alto nível de estresse.

 

Finalmente, o líder do projeto decidiu começar a buscar otimizar o sistema e isso promoveu uma certa melhora. Mas ele ainda não havia sido convencido da necessidade de dois ou mais servidores.

 

Em um belo dia de sol, mudaram o líder do projeto. Eu permaneci no grupo de desenvolvedores do sistema. Após uma longa conversa com a nova líder do projeto, consegui convencê-la da importância de ter um modelo com dois ou mais servidores de aplicação, ao invés do modelo de servidor+contingência.

 

Infelizmente a empresa foi contra. Então, junto com um colega de equipe, montamos um cluster de servidores de aplicação, utilizando máquinas velhas do nosso setor, abandonadas, cacarecos mesmo, mas fazendo balanceamento de carga. Fizemos testes então, com softwares que simulam acessos simultâneos de usuários, sobre nosso cluster de cacarecos. E... adivinhe? A estabilidade era maior do que em uma situação de um único "servidor parrudo".

 

Os dados eram incontestáveis e foi o argumento que convenceu a empresa a adotar tal procedimento. Hoje em dia todo sistema da empresa que precise de alto desempenho e disponibilidade utiliza mais de um servidor, em cluster (usamos várias máquinas virtuais, fazendo balanceamento).
 

Eis um caso em que quantidade é melhor do que qualidade.

 

No próximo post aprofundarei este tema, mostrando os tipos de balanceamento de carga possíveis de implementar. Não perca!

O que o xadrez de rua tem a ver com sistemas rápidos?

A técnica que vou ensinar neste post - e é uma das mais recentes utilizadas em nossos sistemas, embora não seja nenhuma novidade - chama-se "query simulada".

Mas antes vou falar sobre um filme que assisti há alguns anos atrás, chamado "Lances Inocentes" (Searching for Bobby Fischer).

 

O filme conta a história de um garoto que tem um talento especial para o xadrez e é incentivado pelo pai a participar de competições. A família do menino contrata um instrutor que passa a treiná-lo sob uma abordagem clássica do xadrez. Só que simultaneamente, o garoto conhece um enxadrista de rua, que também o influencia, mas sob a ótica do "speed chess", com técnicas bastante heterodoxas, consideradas pelo instrutor do menino como de segunda categoria. E instala-se o conflito.

 

Mas o que, afinal, tem a ver o xadrez de rua com sistemas rápidos?

 

Bem, no contexto de sistemas, sempre existiu uma discussão sobre boas práticas de programação. Há um conflito entre o meio acadêmico e quem "põe a mão na massa".

 

Nesse contexto, todos sabemos que colocar informações hard-coded no sistema (junto com o código-fonte) é uma prática péssima de programação, certo?

 

Bem, o enxadrista de rua do filme tinha seu ponto de vista. E sua técnica funcionava em determinadas ocasiões. E ajudou o menino a encontrar um meio termo.

 

Portanto, estou dizendo que tudo na vida depende do contexto. Em uma situação em que a velocidade de resposta é condição sine qua non, aceito sim ser um pouco heterodoxo.

 

Isto posto, vamos ao que interessa: O que afinal é uma "query simulada"?

 

De forma simples, é programar o resultado de uma query hard-coded no sistema. Posso dizer que é uma espécie "query cacheada" que não expira e que ocupa a memória pontualmente, por pouco tempo. A vantagem não podia ser outra: Velocidade, disponibilidade, menor probabilidade de falhas.

 

Fazemos isso pegando um método que retorna uma query real, indo efetivamente ao banco de dados, substituindo-a por uma query simulada. Para o resto do sistema, é como se estivéssemos indo realmente ao banco de dados. O retorno continua sendo um recordset, mas nós o preenchemos manualmente e o sistema é induzido a acreditar que os dados vieram mesmo do banco. E não tem mesmo diferença nenhuma.

 

Essa foi uma forma de otimizarmos ainda mais o que já havia sido otimizado em nossos sistemas.

 

Estudamos as queries elegíveis para "query simulada" e as convertemos, é claro, com muito critério.

 

Como exemplo, imagine uma query que vai ao banco de dados obter os estados federativos brasileiros e que é muito utilizada. É possível criar uma query fake no sistema que contenha a lista dos estados. O acesso é infinitamente mais rápido do que indo ao banco. Evita tráfego de rede, vai continuar mostrando os estados mesmo que o banco esteja fora do ar, enfim, no contexto de um sistema que não pode ter gargalos, é uma técnica a mais no rol das possibilidades., e que não deve ser ignorada.

Fique ligado que ainda tem muito mais pela frente! Até o próximo post.

Outro pulo do gato: O query timeout!

Caros leitores, hoje falarei sobre algo não menos importante do que o assunto tratado no post anterior. Considero que é também outro "pulo-do-gato" em se tratando de otimização de sistemas web: O "timeout de query"!

 

Tomando-se a velha premissa como base, ou seja, que o banco de dados é um recurso finito, disputado, e portanto sujeito a falhas, e considerando que uma query pode levar mais tempo do que o desejado para executar, então faz-se necessário o uso do "timeout de query".

 

A questão é que, se uma query demorar muito para retornar um resultado, o servidor de aplicação enfileirará requisições, o que é nosso maior temor - e deve ser evitado a qualquer custo.

 

O "timeout de query" funciona de forma muito similar ao "cache de queries". Mas, o intuito aqui é especificar um tempo que nossa aplicação considerará aceitável para a execução de uma query.

 

Em cada query do sistema, especifica-se em segundos, o tempo que aceitaremos para sua execução. Caso esse tempo seja atingido, o servidor de aplicação considerará que houve uma exceção. Um erro, provocado por estouro de tempo limite na execução da query.

 

Esse erro deve ser esperado e tratado pela nossa aplicação, que, em geral, informará ao usuário que a sua requisição não foi atendida dentro do tempo esperado.

 

A grande vantagem é que o usuário não tem a percepção de um sistema lento, agarrado, pelo contrário, para ele a aplicação continua no ar e respondendo adequadamente. Só que agora informando o que ocorreu e permitindo que ele tente novamente.

 

Sendo um dos grandes segredos de um sistema web estável e com alto uptime, o "query timeout" é  uma prática indispensável. Todas as queries do sistema devem utilizá-lo, sem exceção!

 

Até a próxima!

Eis o grande segredo...

Hoje vou falar sobre uma das formas mais eficazes de otimização de qualquer sistema web: Apresento-lhes o "Cache de Queries".

No post anterior, discerni sobre a importância da otimização do banco de dados e sobre a preocupação que se deve ter com o tempo de execução de cada uma das queries que fazem parte de um sistema.

Portanto, o banco de dados é o ponto de maior geração indireta de gargalos em um sistema web. Se ele estiver lento, todo o resto ficará lento, através de um efeito cascata. O acesso ao banco é o maior problema.

Vamos então "eliminar o problema".

"Mas como assim? Afinal o banco de dados é o cerne do sistema. Sem ele não faria sentido o sistema!" - já ouço o leitor retrucar.

Na verdade, não estamos falando, obviamente, em eliminar o banco de dados. Estamos falando em evitá-lo o máximo que pudermos!

Quanto menor for o número de vezes que a aplicação precisar "encostar" no banco de dados, melhor para a performance geral do sistema web.

E é isso exatamente o que faz o Cache de Queries! Evita "idas" desnecessárias ao banco de dados!

O Cache de Queries é algo realmente modificador de vidas. Eu diria que um sistema pode ser dividido entre antes e depois da implementação de Cache de Queries.

O Cache de Queries funciona da seguinte maneira: Você especifica deliberadamente que uma determinada query SQL será "cacheada", isto é, posta em memória real. Então, na primeira vez que a query é executada, o servidor de aplicação efetivamente requisita a consulta ao banco de dados. Entretanto, o resultado de retorno dessa consulta, ou seja o recordset obtido em resposta, é armazenado em memória no servidor de aplicação. Isso significa dizer que, a partir deste momento, se algum usuário requisitar novamente essa mesma query, o banco de dados não será mais incomodado.

O que posso dizer é que o aumento de performance com a técnica é gritante.

As medições de antes e depois da implementação de Cache de Queries mostram situações em que o tempo de carga total de uma página com a query cai de 1 ou 2 segundos para ZERO. É óbvio que algum tempo é gasto no processo para recuperar os dados, ainda que estejam em memória. Mas como a unidade de medida é o milissegundo, o que o servidor de aplicação nos diz é que o tempo gasto foi de zero milissegundos, ou seja, a consulta levou menos de 1 milissegundo para ser executada!

"Uau! Vamos então cachear todas as queries do sistema e resolver todos os nossos problemas!"

Não é bem assim... Há situações que não permitem que uma query seja cacheada. Há de se analisar query por query do sistema, e definir quais delas são elegíveis para o cache. Vamos supor, por exemplo, que o resultado de uma pesquisa dependa de dados que estejam sendo alimentados pelo usuário do sistema. Para ilustrar: Suponha que se esteja pesquisando um aluno pelo seu nome, em uma lista de alunos inscritos. Se é um sistema de inscrição de alunos, e se pusérmos o retorno da pesquisa em cache, alunos inscritos posteriormente ao cacheamento não aparecerão no resultado da pesquisa.

 

Além disso, lembrando de nosso amigo Lavoisier, se ganhamos de um lado, perdemos de outro. Nesse contexto que estamos trabalhando, o ganho é de extraordinária performance. Em detrimento de um uso maior de memória real no servidor de aplicação.

Como sempre, é um ajuste fino. Há que ser estudado com cautela. Mas, como sempre, a relação custo x benefício é positiva.

As linguagens em geral, permitem também, que seja especificado quanto tempo a query ficará em cache, em segundos, minutos, horas ou dias. O resultado de certas queries podem ficar "eternamente" (365 dias) em cache. Por exemplo, no contexto da educação, a query que retorna as séries em determinado ano letivo é uma delas. Como a única chance de ser criada uma série nova é na virada do ano, então a lista das séries pode ficar o ano inteiro em cache.

A conclusão é que, um sistema que não usa cache de queries está aquém do desejado e vai sofrer com certeza, de lentidão, quiçá terá comprometido seu uptime.

Minha opinião pessoal é que todo sistema deve ser desenvolvido com esta técnica desde o princípio, em função dos resultados excepcionais alcançados para o usuário final.

 

No próximo post o assunto será algo igualmente importante: O time-out de queries! Até lá.

Prioridade zero: O banco de dados!

Vou agora começar a mostrar onde geralmente estão os principais gargalos nos sistemas desenvolvidos para web, e algumas técnicas para evitá-los.

A "prioridade número zero" em qualquer sistema que esteja apresentando lentidão e precise ser otimizado é atacar os gargalos no banco de dados.

Pode-se otimizar de tudo em um sistema: a rede, o número de servidores, o poder de processamento dos mesmos, aumentar a quantidade de memória, mas nada disso surtirá o efeito desejado sem uma prévia otimização do banco de dados.

Isso porque no final das contas, toda a cadeia de processos envolvidos dependem dele. Os pedidos dos usuários, em geral, culminam num acesso ao banco de dados.

Portanto, não compensa ficar enxugando a aplicação (por exemplo) para ganhar 10 ou 20 milissegundos na carga de uma página, se não tiver sido feito antes, um ajuste fino no banco de dados.

E, através de modificações triviais no banco de dados, pode-se diminuir segundos do tempo de resposta (em contrapartida aos milissegundos ganhos sob outra abordagem), o que representa um ganho muito mais expressivo na performance geral do sistema, impedindo o enfileiramento de requisições no servidor de aplicação.

 

Note que é assim que se melhora a performance de um sistema. Medindo-se o tempo gasto em cada pequena parte e a otimizando-a, pois cada pequeno processo desses será chamada o número de vezes que requisições forem feitas pela aplicação ao banco de dados. Então é algo que é exponencial.

Os pontos-chave a se observar no contexto do banco de dados são, portanto:

* Otimizar as queries

Tenha o hábito de medir o tempo que leva cada query do seu sistema, do início ao fim do processamento. No Oracle, por exemplo,  isso é feito com o comando "SET TIMING ON". Toda query executada após este comando terá seu tempo de processamento mostrado na tela, em milissegundos. Quanto menor o tempo gasto pela query, melhor. Diria que qualquer valor acima de 1 segundo é indesejável:

    set timing on;
 
    select dsc_serie from serie
    where ind_status = 'A';

    25 linhas selecionadas.
    real: 141 (milissegundos)


* Evitar usar a cláusula IN ou EXISTS nas queries

A cláusula IN em queries SQL são muito lentas. Dê prioridade aos joins.


* Utilizar materialized views para consultas que gerarão relatórios.

Muitos sistemas geram relatórios a partir das próprias tabelas que estão sofrendo inserções e atualizações de dados  pelos usuários do site. Isso cria uma situação de lentidão tanto para quem está requisitando o relatório quanto para quem está entrando ou atualizando dados. A solução é criar uma materialized view com um job associado, que a atualizará de tempos em tempos. Sugiro a pesquisa no Google pelo termo "ETL".

* Utilizar índices nas tabelas.

Os índices criam uma espécie de "mapa" para o banco de dados acessar as informações de forma muito, muito mais rápida. Mas, relembrando a citação de Lavoisier, em contrapartida, tornam a inserção de dados ligeiramente mais lenta, pois algum tempo é necessário para que a indexação seja realizada. No entanto, a relação custo x benefício é vantajosa.

* Restringir o número de linhas no retorno de uma query.

Quando o usuário estiver fazendo uma pesquisa digitando um nome em uma caixa de texto, por exemplo, que gera uma atualização instantânea do conteúdo da caixa (o famoso autocomplete), pode-se especificar na query o número máximo de linhas retornadas. Isso agiliza bastante a resposta. O usuário não perderá informações, pois quanto mais letras digita, mais precisa é a resposta.

* Trazer tabelas específicas inteiras para a memória real

Com a diminuição do preço da memória RAM, é muito comum termos servidores com grande oferta de memória disponível. Algumas empresas já estão utilizando esta técnica para agilizar as consultas a banco de dados - trazer TODO o conteúdo de certas tabelas para a memória real.

Há outras dezenas de técnicas de otimização possíveis no âmbito do banco de dados. Área em que  não sou especialista. Mas certamente, uma equipe de banco de dados saberá responder prontamente a qualquer pedido nesse sentido, fornecendo as melhores estratégias para diminuir o tempo de processamento das queries, que é a necessidade objetiva que tentei passar com este post.

Entretanto... Há uma técnica em especial que é uma daquelas coisas que costumamos dizer que "funciona como mágica", como diz a famosa música do Queen - "It´s a kind of magic!":

 

 

 O Cache de queries.

 

 

Será o tema do nosso próximo post. Imperdível!!!

O gargalo faz da garrafa o que ela é. Mas do congestionamento também!

Um dos mais importantes estratagemas do livro "A arte da guerra", escrito pelo general, filósofo e estrategista chinês Sun Tzu há dois mil e quinhentos anos atrás, enfatiza a importância de conhecer o inimigo:

"Se você conhece o inimigo e conhece a si mesmo, não precisa temer o resultado de cem batalhas. Se você conhece a si mesmo, mas não o inimigo, para cada vitória conquistada, você também sofrerá uma derrota."

Em outras palavras, para ser ótimo, é necessário conhecer o inimigo profundamente. Caso contrário, só é possível ser mediano. No contexto da otimização de sistemas, o inimigo em questão é o gargalo.

Mas o que é um gargalo? De que se trata? Por que ele nos aborrece? Ele é sempre ruim? Como evitá-lo? Onde ele aparece?

Bem, um gargalo é um funil. Nada além do que uma resistência à passagem de alguma coisa por um canal. Um filtro. Quantitativo, não qualitativo.

O gargalo de uma garrafa tem a função de restringir a quantidade de líquido que sai dela. E nesse contexto isso é bom. É a função dele, para que o líquido não derrame todo de uma vez. O gargalo é o que faz da garrafa o que ela é! Sem ele, não seria uma garrafa, mas um copo.

Por outro lado, um gargalo também faz de um engarrafamento de veículos em uma avenida ou estrada, o que ele é. E nesse contexto isso não é bom. Deve e pode ser evitado: Pode-se construir  mais vias paralelas de escoamento, definir saídas priorizando ambulâncias, carros de bombeiro, transportes de massa como ônibus, pode-se coibir motoristas que trafegam no acostamento,  induzir motoristas a seguir por uma rota alternativa, pode-se aumentar a velocidade com que os veículos passam pelos pontos de gargalo, pode-se fazer um rodízio de placas naquela via, combinando quem pode trafegar de acordo como dia da semana,  pode-se até mesmo retirar a necessidade de vários motoristas passarem ali diariamente, se forem convencidos a trabalharem de casa. Pode-se aumentar o número de guardas e câmeras na via para monitorar o comportamento do fluxo e obter informações que gerarão ações de correção.

Veja que, utilizando a analogia do engarrafamento no parágrafo acima, citei várias técnicas de otimização de sistemas web, que, quando corretamente aplicadas, podem melhorar sobremaneira o desempenho e a estabilidade de um serviço online.

Antes de optar por uma técnica ou outra (ou por todas), entretanto, é preciso identificar os pontos de gargalo do sistema, que podem estar: na rede (baixo número de rotas para chegar ao servidor de aplicação, lentidão da rede, baixo throughput do canal), no banco de dados (queries mal-escritas, ausência de índices nas tabelas, relatórios que recalculam totais todas as vezes que são chamados), na própria aplicação (páginas muito grandes, imagens muito pesadas, navegação pouco eficiente), e também no layout da estrutura física (poucos servidores de aplicação).

É muito importante, também, saber reconhecer que o sistema não é a aplicação! Já vi diversos projetos que funcionaram na fase de testes não apresentarem o mesmo desempenho ao serem postos em produção. O motivo é que testaram se a aplicação aguentava um certo número de usuários simultâneos, quando deveriam ter testado se o sistema aguentava - o que é completamente diferente.

Um sistema é um conjunto de partes que forma o todo. Portanto, a aplicação, aqui, é apenas parte dele. Há que se considerar desde o computador que o cliente usa, passando pelo canal de acesso,  considerar os servidores, o banco de dados, etc. Esse conjunto de peças é o "sistema", cuja performance deve ser testada antes de ir para produção.

Sem eliminar o gargalo o sistema está fadado a um baixo uptime.

O gargalo gera o enfileiramento no servidor de aplicação. Conforme os usuários requisitam páginas ao sistema web, utilizando seus navegadores, os servidores de aplicação tentam atendê-los da melhor maneira possível (pois é a função deles). Se uma determinada página provoca a execução de uma consulta em um banco de dados e este último demora muito para retornar o resultado, o servidor de aplicação vai colocar o usuário em uma fila e vai tentar atender outras requisições. A medida que os pedidos não estejam conseguindo ser atendidos, a fila cresce exponencialmente. O usuário, percebendo a demora, começa a ficar irritado e tende a pressionar F5 ou o reload em seu navegador, o que piora ainda mais a situação. O resultado é que o inimigo vence a batalha: o sistema sai do ar.

Nos próximos posts conheceremos como podemos enfrentar o gargalo - este inimigo indesejável - e derrotá-lo sempre. Até lá!

Tudo se resume a evitar gargalos...

Após uma década de experiência trabalhando com ajuste fino de sistemas web, posso afirmar, sem sombra de dúvidas, que a frase que intitula este primeiro post no blog sintetiza perfeitamente a idéia do que é a otimização de sistemas que necessitam de alta disponibilidade e desempenho.

Ocorre que, tal qual qualquer serviço disponibilizado a um grande público com canais finitos, há uma tendência a formação de gargalos, que são o maior inimigo do fluxo ininterrupto do processo.

Durante as olimpíadas de Londres em 2012, os organizadores se valeram de uma filosofia conhecida como "go with the flow", na qual eventualmente abriam mão da arrecadação em uma estação de trem, por exemplo, caso o processo de aquisição dos bilhetes pudesse causar um congestionamento de pessoas nas saídas (vale esclarecer que em Londres põe-se o bilhete na saída da estação). Priorizou-se (pontualmente) o fluxo ininterrupto de passageiros em detrimento do faturamento, mas a idéia era evitar situações de risco, que surgiriam se um gargalo fosse instaldo.

Os mesmos princípios podem (e devem) ser aplicados em sistemas web que precisam de um uptime elevado.

É importante salientar que, tal qual a eventual diminuição do faturamento nas estações de trem de Londres durante os jogos de grande público, haverá situações em que será preciso escolher do que abriremos mão no processo, em detrimento de algo de importância semelhante, considerando como principal objetivo o sucesso do processo como um todo.

Como disse o pai da química moderna, Antoine Lavoisier, "na natureza, nada se cria, nada se perde, tudo se transforma". Na informática não seria diferente. Portanto, a questão é mesmo, em última análise, uma arte de ajuste de custo/benefício.

Nos próximos posts mostrarei diversos conceitos e técnicas que podem ser aplicados a qualquer sistema de informática que precise de alta disponibilidade, independente da linguagem de programação utilizada (e essa é a beleza da coisa).

São informações que valem ouro.

Fique ligado!