[GTER] freeRouter

Wed Dec 30 15:46:42 -02 2015

Veja inline.

On Wednesday, 30 December 2015, Douglas Fischer <fischerdouglas at gmail.com>
wrote:

> Em 30 de dezembro de 2015 03:10, Diogo Montagner <
> diogo.montagner at gmail.com>
> escreveu:
>
> > Ao escolher Java, automaticamente voce tem uma pancada de ferramentas
> para
> > desenvolvimento e testes. Se voce empreender conceitos de DevOps e
> > Continuos Delivery no codigo, o Java eh a escolha mais correta no quesito
> > qualidade.
> >
> Não discordo!
>
> Maaaaaassss
> Agora uma coisa que NÃO COLA nesse caso é o papo de:
>  "Escolhendo Java você vai ter uma gama
>   quase infinita de bibliotecas e plugins
>   já desenvolvios, blábláblá!!"
> Que arquiteto de código vai embarcar um código no seu projeto se fazer uma
> revisão completa?
> Revisar e colocar nos padrões toma tanto ou mais tempo que escrever do
> zero.
> E a segurança? E o padrão? (desde o básico com a indetação, nomeclatura de
> variáveis, até endereçamento de biliotecas)

Dmontagner> eu tb discordo neste ponto. Mas eu ainda assim suporto a
reutilizacao de codigos existente.

>
> Simples:
> "Qual o projeto mais impecável em qualidade de código no mundo hoje?"
> Com TODA a certeza openbsd(e filhos) estará entre os 3 primeiros da lista.
> Quando eles internalizaram um código sem revisar e reestruturar ele
> TODINHO?
>
>
> E apenas a título de complementação de referências, acho o Ruby e seus
> trilho muito mais elegante no que tange ao continuous deployment.
>

 Elegancia eh uma coisa. Assim como outro membro da lista comentou, existem
outras linguagens que possuem essas ferramentas, mas em ainda acredito
quando o ambiente eh Java, estas ferramentas estao um passo a frente das
demais.

Disclaimer: Java nao estah na minha lista de linguagens preferida. Mas nao
vou iniciar a discussao de linguagens pq eh uma discussao sem fim.

> Eu ainda prefiro o Java do que escrever codigo de roteamento e
> > encaminhamento de pacotes em HW generico do que usar a GPU para isto.
> >
> Man, nesse ponto eu tenho que discordar!
> CINCO MIL THREADS!
>
> Os parques telefônicos do mundo inteiro continuam sendo escritos e
> reescritos desde 50 anos atrás na base do Earlang da Ericson por um(dois)
> motivo(s): FUNCIONAM, e ESCALAM.
>
> Paralelismo alí não é "EXTRA" é requisito de campo.

De uma olhada na linguagem Scala. Ela tem tudo pra substituir o java em um
futuro nao muito distante.

>
> Ficou pequeno?
> Espeta a placa do lado(a quente se o hardware permitir) e PAU!
>
>
Eu concordo com este item.

> >
> > Em geral, o control plane de un roteador pode ser facilmente escrito em
> > Java sem grandes implicacoes na performance. Por outro lado, o fowarding
> > plane, ainda que em HW generico, precisa ter um acesso mais direto ao HW
> > para se obter performances melhores.
> >
> > Se a questao eh apenas escala no control-plane, no momento que a
> > arquitetura passa a ser distribuida e/ou baseada em micro-servicos, a
> > questao do Java eh apenas um pequeno e insignificante detalhe, IMO.
> >
> Se você olhar para o Control-Plane enxergando apenas o de uma caixa, você
> está "quase" certo...
> Quase porque ainda tem os pontos de gargalo(aqueles aonde os Middlewares
> entram)

> Mas se você olhar para o Control-Plane em Pensar em um OpenFlow com 200-300
> dispositivos.
> Aí a coisa muda de figura...
>
>
> Vamos fazer uma coisa:
> - É fato que um fullrouting Single Homed, quando sumarizado, teria apenas
> algo em torno de 10-12 rotas...
> - É também fato que o numero de rotas é fator decisivo em QUALQUER
> plataforma de encaminhamento, seja com FastPath/CEF/etc ou não...
>    (Lembra dos 8Gbps numa CCR usando rota default?)
> - Então me ache um hardware, que não seja essa linha GPU ou XeonPhi, que
> consiga fazer a reduzida de Karnout da Internet IPv4 em tempo praticável e
> aí eu entrego as bets.

Broadcom - eh um HW generico mas desenvolvido para aplicacoes no ambiente
de forwarding de pacotes, i.e., redes.

> - Ou então, coloque o Java/Python/Pearl/Ruby/etc para lidar com essa CINCO
> MIL THREADS que eu mesmo derrubo as casinhas e entrego as bets...
>
>
Espere um pouco mais e voce vai ver isto acontecer. Eu tenho a impressao
que Scala sera um game changer cedo ou tarde. E eu acredito tb que a
arquitetura baseada em micro servicos eh o jeito de escalonar no futuro.

Uma nota final: alta escala em um ponto unico eh uma faca de dois
gumes. Quanto mais alto o edificio, maior eh o estrago qdo ele cai e maior
eh o tempo pra reerguer ele. No final, voce precisa analisar aonde que o se
negocio se encaixa, pois eh uma questao de tradeoff.

>
> P.S: No flames please...
> Brincando e falando sério ao mesmo tempo, a conversa fica descontraída e
> produtiva.
>
>
> > []s
> >
> > On Wednesday, 30 December 2015, Douglas Fischer <
> fischerdouglas at gmail.com>
> > wrote:
> >
> > > <piadoca_com-fundo-de-verdade>
> > >    Os únicos modinhas-devs que eu
> > >    respeito são os que usam Elixir.
> > >    #VeinNiMinUatizápi
> > >
> > >    Ainda assim, tal qual o C# e o C++
> > >    em relação ao C, Elixir é uma
> > >    abordagem afeminada do Erlang.
> > > <piadoca_com-fundo-de-verdade>
> > >
> > > Flames > /dev/null
> > >
> > >
> > >
> > > Brincadeiras a parte, e voltando falando do FreeRouter...
> > > Sou obrigado a reconhecer que o código deles parece realmente
> > > organizado(como o Rubens falou).
> > >    Pessoalmente o lance do "tudo em VRF" me pareceu bastante elegante.
> > >
> > > Mas mesmo dentro dessa organização vê-se a perna-curta que é a mentira
> do
> > > JVM fazendo jus...
> > > Os famosos "middlewares" colocados aonde o bicho pega de verdade.
> > >
> > >
> > > Eu ainda gostaria de ver um conjuntão de pacotes de Routing todo feito
> em
> > > alguma linguagem Shared-Nothing.
> > >  - Imagine isso rodando em ambientes MultiCore (61 cores XeonPhi ou
> então
> > > 5mil cores da Tesla)
> > >  - Imagine isso para rodar um Controller de OpenFlow
> > >    em processamento distribuído com 10-12 nós.
> > >  - E para não dizer que não falei dos nanicos... Imagine isso rodando
> num
> > > Raspeberry?
> > >
> > > Em 29 de dezembro de 2015 21:22, Elizandro Pacheco [ Pacheco Tecnologia
> > ] <
> > > elizandro at pachecotecnologia.net <javascript:;>> escreveu:
> > >
> > > > Ou em python! :P
> > > >
> > > >
> > > > Elizandro Pacheco
> > > >
> > > > > Em 29 de dez de 2015, à(s) 15:12, Rubens Kuhl <rubensk at gmail.com
> > > <javascript:;>>
> > > > escreveu:
> > > > >
> > > > > 2015-12-29 14:40 GMT-02:00 Fernando Frediani <fhfrediani at gmail.com
> > > <javascript:;>>:
> > > > >
> > > > >> Meu caro Rubens. Infelizmente eu não posso falar sobre Java com o
> > > mesmo
> > > > >> entusiasmo que você.
> > > > >>
> > > > >
> > > > > Eu também por default torço o nariz para coisas escritas em Java,
> por
> > > > > exemplo os NMS da ManageEngine... mas eu já vi um sistema complexo
> > em C
> > > > que
> > > > > atendia milhões de usuários (não é força de expressão, eram milhões
> > > > mesmo)
> > > > > ser substituído por um escrito em Java e vi que as dificuldades de
> > > > scaling
> > > > > tem como ser endereçadas. O que se fez foi criar um conjunto de
> > classes
> > > > > muito sólido e rápido - usando o melhor expertise da equipe - que
> > > depois
> > > > > eram reutilizadas por gente não tem experiente mas que não tinha
> > muito
> > > > como
> > > > > errar ao seguir um modelo já pornto.
> > > > >
> > > > >
> > > > >> Se há preocupação com a qualidade do código eu me perguntou por
> qual
> > > > razão
> > > > >> foram escolher justo Java então.
> > > > >>
> > > > >
> > > > > Eu não sei o motivo do autor do freeRouter, mas posso te comentar o
> > > > motivo
> > > > > da escolha do caso que vivi acima: longevidade. O que se vê em
> > > linguagens
> > > > > de programação é que a cada ano existe a linguagem do momento, que
> > > depois
> > > > > perde momentum e é substituída por outras... então se você imagina
> o
> > > > > cenário em que daqui a 10 anos alguém precise der manutenção num
> > > código,
> > > > > ele leva a soluções que não sejam nem as melhores nem muito ruins,
> > mas
> > > > que
> > > > > sejam algo médio que ainda existirá.
> > > > >
> > > > >
> > > > >> feitas em Java ou algo similar. Mas olhando o todo e por default
> eu
> > > não
> > > > >> vejo Java com tanto entusiasmo assim aonde quer que ele exista.
> > > > >>
> > > > >>
> > > > > Cuidado que a interface do Gmail é Java, então ela pode se magoar e
> > > fazer
> > > > > seu e-mail passar a dar problemas... ;-)
> > > > >
> > > > >
> > > > >> Sobre o software em questão parece interessante e com um leque de
> > > > >> funcionalidades que até mesmo outras opções free ou pagas não
> > possuem.
> > > > >> Também gostei da simplicidade que provavelmente vem da filosofia
> > > > K.I.S.S e
> > > > >> que é sempre muito bem vinda.
> > > > >>
> > > > >
> > > > > Você pode reescrever o projeto dele em Go se preferir...
> > > > >
> > > > >
> > > > > Rubens
> > > > > --
> > > > > gter list    https://eng.registro.br/mailman/listinfo/gter
> > > >
> > > > --
> > > > gter list    https://eng.registro.br/mailman/listinfo/gter
> > > >
> > >
> > >
> > >
> > > --
> > > Douglas Fernando Fischer
> > > Engº de Controle e Automação
> > > --
> > > gter list    https://eng.registro.br/mailman/listinfo/gter
> >
> >
> >
> > --
> > ./diogo -montagner
> > JNCIE-SP 0x41A
> > --
> > gter list    https://eng.registro.br/mailman/listinfo/gter
> >
>
>
>
> --
> Douglas Fernando Fischer
> Engº de Controle e Automação
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter

-- 
./diogo -montagner
JNCIE-SP 0x41A