Spring Framwork
Você utiliza Spring Framework? Têm dúvidas ? Gostaria de Suporte oficial com SLA de atendimento?
Este não é um post de propaganda, e sim informativo, pois sei que o Spring Framework é um dos frameworks mais populares em utilização no Brasil.
Eu mesmo quando trabalhava na minha antiga empresa em vários clientes implantamos projetos utilizando o SpringFramework, claro, com o apelo de oferecer vários facilitadores, principalmente os (*)DAOSupport, as famosas injeções de dependências, e vários facilitadores que o Spring tem. A questão é que a SpringSource, tentou adotar um modelo comercial sobre o Spring. Sim! Uma empresa precisa de dinheiro e vendas para sobreviver, então não os julgo errados, afinal, o negócio de oferecer apenas serviços promove uma escala grande de recursos humanos, e fatores de riscos que toda a área de TI tem. A comercialização do suporte de Spring deve ficar mais fácil, depois da aquisição dela pela VMWare. Então, usuários do Spring que tem problemas, poderiam ter acesso ao suporte através da VMWare.
O ponto interessante, é que você não precisa adquirir este suporte da VMWare (empresa de virtualização), uma vez que a divisão JBoss da Red Hat também suporta Spring dentro do seu pacote conhecido como JBoss Enterprise Application Platform, que além do Spring e o próprio JBoss Application Server 5.0, oferece suporte também para:
- Hibernate
- Seam
- Strtus 2.x
- GWT (Google Web Toolkit)
- RichFaces
O motivo pelo qual isto é suportado é simples, a Red Hat quer que o cliente tenha a seu alcance todo o suporte e garantia de atendimento do que seja necessário para desenvolver uma aplicação Java corporativa de forma eficiente e segura.
Como funciona o suporte?
Você tem alguma dúvida de configuração, instalação ou até performance, você poderá ligar num 0800 em Português e poder falar com um Engenheiro de Suporte, que pode resolver o seu problema, ou escalar sua dúvida para o time de Engenharia de Segundo-Nível ou mesmo um Desenvolvedor do produto, no caso de Spring, a Red Hat contratou alguns core-developers do Canadá e Estados unidos, para trabalharem na divisão JBoss continuando a contribuir de alguma forma com o desenvolvimento do Spring, bem como suportando problemas, fornecendo correções e etc. Isto acontece com todos os produtos que a Red Hat comercializa o suporte.
Particularmente foi uma surpresa ver este movimento na Red Hat, mas parando e refletindo, faz todo o sentido, a questão de tentar atender o máximo possível as necessidades de seus clientes.
Arquitetos Chuck Norris
É claro que você já deve ter encontrado, ouvido, trabalhado com um Arquiteto “Chuck Norris”, daqueles caras que batem no peito e falam “Eu não preciso de suporte, se for o caso eu refaço todo este códigozinho do Hibernate em uma noite….”, não que alguns destes caras não sejam f… suficiente para resolverem, mas em termos de gestão, o tempo, os riscos, precisam ser mitigados de forma profissional, e pensar: “Vale a pena dedicar um recurso que me custa caro para ter que perder 3 dias, 1 semana, 1 mês, para resolver algo de um projeto opensource que eu poderia ter no mínimo o conselho do fabricante desta tecnologia?”. Outra coisa que é difícil de fazer algumas pessoas entenderem é que ninguem vende software opensource, o que as pessoas vendem são benefícios do uso dele. Mas de algum lugar a cultura de opensource deve ser de graça assolou nosso país de uma forma, que em alguns momentos é delicado manter a calma e paciência frente alguns comentários no mínimo infudados do que é nada mais nada menos que um modelo de negócios.
Arquitetos aceitando a Colaboração de um Suporte
Quando chega-se à uma posição de Arquitetura, acredito que a pessoa já tenha passado algumas fases até da vida pessoal, onde a rebeldia e teimosia tenham sido deixadas um pouco de lado, portanto fica mais fácil ouvir, refletir e muitas vezes evitar assumir um risco sozinho. Afinal de contas, eu não vejo nenhum caso de empresa que tenha dado certo, onde não haja pessoas que escutem as outras, colaborem e que tomem decisões mediante vários estudos, avisos, conselhos etc. Se você é um Arquiteto de Software em Java, não seria interessante ter uma opinião de quem cria os frameworks que você usa?
Existe um caso de suporte no Brasil que é bem interessante, um cliente nosso passou a utilizar o JBoss Messaging ao invés do antigo JBossMQ, pois o “Arquiteto” leu a documentação e interpretou algo de uma forma “X”. Abriram um chamado, pois o comportamento era “Y”, o mais interessante é que esse chamado caiu nas mãos do Clebert Suconic, como este nome, não é fácil de imaginar que esse cara seja um paulistano de fala tranquila, um cara calmo e com uma humildade tão grande quanto a sua genialidade… Pois bem, depois do cliente achar que o GoogleTranslator era super avançado, já que as respostas no “Site de Clientes JBoss” tinha um português perfeito, Clebert pediu para fazermos um call com este cliente para sermos mais claros, ele me copiou no e-mail e pediu para organizar este chamado. Foi engraçado ver todos esperando um cara falando inglês, mas ouvir um português de São Paulo, apenas com umas gírias desatualizadas, já que o Clebert mora em Austin no Texas (EUA) há um tempão. Durante a conversa e o debate, uma das coisas mais interessantes foi o momento que nós explicamos um comportamento de um determinado componente do Messaging, depois de muito escutar o Arquiteto do cliente relutante em aceitar a explicação, Clebert com muita humildade e simplicidade disse:
” - Arquiteto XXX, desculpe, mas não quero parecer arrogante, mas esta porção da documentação foi escrita por mim, bem como este componente também, a não ser que nós escalemos isto para o meu chefe, mas o funcionamento é de fato assim….”
Depois de ouvir isto, o Arquiteto se convenceu, afinal de contas, não era nenhum outro Arquiteto, desenvolvedor, ou qualquer um, mas a pessoa que criará aquele cenário que ele não tinha entendido direito como poderia ser usado. No final o cliente entendeu, e conseguimos instruí-lo para uma solução diferente, mas que faria exatamente o que ele queria.
Não garantimos que todo o Core-Developer de JBoss falem português tão bem quanto o Clebert, mesmo tendo vários brasileiros em diferentes projetos, mas tentamos garantir que o cliente seja atendido, e que tenha sua dúvida sanada sempre da melhor forma. O que é isso? É um serviço, é um produto… Baseado no modelo de colaboração! Apenas isso, nada mais que isso. Se isto é um crime… Eu acredito que não.
Assisti o vídeo da palestra do Vinicius Manhães Telles no RailsSummit 2009, e achei fantástica a abordagem que ele deu para a visão empreendedora e como estabelecer e criar um modelo de negócio, me faz ter uma saudade da época que eu tinha minha empresa, meus sonhos, mas que foram interrompidos talvez pela a imaturidade ou falta de paciência, que ele tanto cita. Na Red Hat, meu principal foco de trabalho é tentar levar as pessoas o nosso modelo de negócios, visando trazer comodidade e tranquilidade para o nosso mercado. O Vinicius Telles criou o BeOnTheNet, ele cobra R$99,00 para os clientes poderem ter um site de alta qualidade na internet, sem a necessidade de um “atravessador” (Webmaster) :). A Red Hat cobra em média R$5.000 por ano por CPU para oferecer suporte premium 24X7 de seu ambiente corporativo JBoss, e como já foi dito, oferecendo um suporte de alta qualidade, que é uma assinatura que lhe dá direito a tirar dúvidas sobre os seguintes projetos:
- JBoss Application Server
- Hibernate
- Seam
- Spring Framework
- Struts 2.x
- GWT
- Richfaces
Meu colega João Paulo Viragine faz a brincadeira, que nosso suporte premium por 1 CPU custa na verdade:
- R$13.69 por dia (Menos que a média do Vale Refeição na região Sudeste)
- R$0,57 por hora (Sim, cinquenta centavos por hora … Não isto nem de piada precisa)
Pergunta: Isto é caro? Já vi empresas que perdem milhões se passam 1 única manhã sem seu ambiente de produção funcionando… Estas empresas, ainda vivem o “Opensource romantico”, entretanto até mesmo o Gartner cita Opensource como o modelo de negócios extremamente promissor para os próximos anos, porém, quando a estratégia opensource é mal feita, os resultados são péssimos! Afinal de contas, eu não gostaria de ver a empresa que eu trabalho, que eu gosto “pra caramba”, onde vejo pessoas felizes por que acreditarem na causa da colaboração, tendo que ser vendida para uma empresa qualquer, pode ser que isso aconteça, não podemos nunca dizer nunca, mas vamos lutar sempre para manter a nossa missão:
- “Ser o catalizador das inicitivas de código aberto, fornecendo sempre uma alternativa de solução aberta porém corporativa! “
Este evento pode ter uma leitura polêmica, aliás no passado, algumas pessoas achavam que as pessoas iriam até as vias de fato, defendendo suas plataformas, ou ’seu ganha-pão’, porém, de acordo com a leitura que fizemos, este evento visa muito divulgar o que existem nas platformas, e fomentar o interesse e uso das mesmas.