[GTER] freeRouter

Wed Dec 30 08:07:42 -02 2015

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)

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.

> 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.

Ficou pequeno?
Espeta a placa do lado(a quente se o hardware permitir) e PAU!

>
> 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.
- 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...

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