Experiência: Configr e Prêmio Oxford de Design

Este é o primeiro post do gênero que escrevo, um post para falar sobre experiências de desenvolvimento. Antes de tudo quero lhe falar que este não é um post patrocinado. Nenhuma das empresas mencionadas me pagou nada para o escrever. É uma experiência real que quero compartilhar com você. Mas antes de qualquer coisa, deixa eu lhe ambientar sobre os envolvidos, Oxford Porcelanas, Candy ShopConfigr e eu.

O que é o Prêmio Oxford de Design?

Um concurso de design com premiação em dinheiro, uma linha exclusiva, limitada e numerada de porcelanas Oxford ao vencedor. Neste ano rolou a sua 4ª edição. Mais detalhes deste projeto você encontra aqui.

O que é a Candy Shop?

Uma agência digital de Curitiba que atende a Oxford Porcelanas e me chamou para ser o responsável técnico do concurso.

O que é a Configr?

Um serviço muito bacana que tira a preocupação de infraestrutura de meros devs como eu, cloud gerenciado.

E eu

Sou apenas uma das inúmeras pessoas envolvidas no concurso, mais especificamente no desenvolvimento.

Um pouco de história

O Prêmio Oxford de Design já está na quarta edição e é a primeira vez que trabalho no mesmo. Quando fui chamado para cuidar da tecnologia, fui informado que nos anos anteriores houveram muitos erros e não gostariam de ter a mesma experiência. Deixa eu dar um spoiler: este ano houveram alguns pequenos erros, mas como estávamos preparados, foi rápida a ação e correção.

Do lado técnico, o sistema utilizado nas 3 edições anteriores foi feito com PHP e o framework CodeIgniter. Nada contra o framework, já vi coisas muito boas feitas com ele. O que me assustou, no entanto, foi o “versionamento” do sistema. Como exemplo, no controller dos participantes existiam diversos métodos como votos, votos_2, votos_back, votos_old, votos_new… e assim por diante. Obviamente que era compreensível qual era o método atual, no entanto, todos aqueles outros que lá estavam foram relevantes em algum momento nos 3 anos anteriores. Apesar de tudo, eram bem semelhantes, poucas variações eram vistas entre ambos. Aí vieram algumas perguntas: o que motivou aquelas versões não mais utilizadas? Se eu remover, pode ser prejudicial para um estágio futuro do concurso?

Como existiam diversos pontos dúbios, estudei o código do começo ao fim e compreendi exatamente o que o sistema se propunha a fazer, e foi aí que…

Um novo sistema

Era claro que com o tempo disponível e conhecimento de todas as etapas do concurso eu conseguiria deixar de lado o legado de 3 outras edições com suas N variações da mesma coisa e dezenas de problemas já conhecidos para criar algo totalmente novo e pensado. O concurso iniciaria em 30 de Agosto de 2018 e eu já estava como responsável técnico em Abril do mesmo ano.

Por comodidade preferi criar o sistema com PHP usando o Zend Framework 3, afinal de contas, eu precisaria de segurança caso algo delicado acontecesse, então, nada melhor que usar algo que tenho pleno domínio. Aliás, essa é uma lição que aprendi há um tempo com o Flávio Silveira: caso o que você esteja desenvolvendo seja crítico, sempre opte pelo que mais domina. Imagina se eu tivesse feito algo em Python ou Ruby, por exemplo, e ocorresse uma situação que requeria ação imediata, o resultado poderia ser bem caótico.

Tomei algumas decisões muito loucas no desenvolvimento deste sistema. Além da demanda da cliente, fiz algumas coisas por acreditar ser necessário e outras com base nas inúmeras requisições de pequenas ações manuais que tive ao longo do concurso, mas a mais incrível de todas foi essa: tornar o sistema Rolling Release. O concurso possui as seguintes etapas:

  1. Inscrições
  2. Votação popular
  3. Voto dos vencedores anteriores
  4. Finalistas – Seleção do júri técnico
  5. Divulgação do resultado

E para cada uma destas etapas, de algumas poucas à dezenas de ações foram necessárias. A cada etapa as funcionalidades necessárias para seu funcionamento eram desenvolvidas poucos dias antes, algumas inclusive, ficando prontas somente alguns minutos antes de ir ao ar.

O primeiro problema

O site do prêmio estava hospedado na Locaweb e por orientação com base em sei lá que parâmetros, o fornecedor orientou a cliente a contratar um cloud dedicado para dar conta do recado. Quando fui criar o ambiente de homologação para a cliente, minha primeira necessidade foi criar um subdomínio apontando para uma pasta do server. Não foi possível.

Já tinha feito isso dezenas de vezes em hospedagens compartilhadas da Locaweb e não compreendia por que no cloud da cliente não era possível. Abri um ticket. 3 dias depois veio a resposta dizendo que como era um cloud dedicado, era diferente das hospedagens compartilhadas, não sendo possível criar subdomínios da forma que eu precisava.

Em continuidade ao ticket, solicitei tal subdomínio, informando o nome e pasta de destino. 2 dias depois a resposta dizendo que estava pronto. Testei e não estava. Após mais 4 dias “resolveram” o problema do subdomínio, agora ele estava correto. No entanto, fizeram uma caca sem tamanho: o site de produção agora era o mesmo que deveria estar somente em homologação. Pense no desespero pra corrigir a merda deles. Em resumo, foram 9 dias para criar um ambiente de homologação para no fim em 15 minutos eu ter que jogar fora para fazer o de produção estar no ar novamente.

E podia ser pior!

Obviamente que não abrirei valores, mas a cliente estava com um cloud dedicado de 32GB de RAM, 8 cores de processamento, HD de 200GB e mais um pacote adicional de 20GB de armazenamento, dá pra imaginar que não é barato, certo? Mas minha maior preocupação foi a seguinte: Em meio às solicitações via ticket, reclamei de o chat não estar habilitado. A pessoa me informou que devido à contratação do cloud dedicado, tudo deveria ser resolvido por meio de ticket, o chat não era uma opção naquele plano e se quiséssemos chat teria de retornar ao plano compartilhado. Achei um absurdo, um serviço dedicado e caro com SLA de 24h enquanto que no compartilhado o atendimento é instantâneo.

Imagina só, centenas de pessoas acessando, ocorre um erro que está fora do meu controle, abro um ticket e eles levam 2, 3 dias para responder… não dá, né!

A solução

Sugeri a migração para um cloud gerenciado. Sou cliente da Configr há quase um ano e venho tendo uma ótima experiência com eles, então sugeri para a Oxford também. Entrei em contato com a Configr explicando a necessidade e problemas que tive na Locaweb e ao final além de tudo, me ajudaram a montar um plano de ação. Isso foi o que mais me agradou, além de um serviço de qualidade, o qual eu já tenho pleno conhecimento e confio, ainda fizemos a cliente gastar 1/12 do que estava torrando na Locaweb. Isso mesmo, com apenas 1 mensalidade na Locaweb a cliente pagará 1 ano todo na Configr com um cloud corretamente dimensionado para o período de maior quantidade acessos.

Mas o preço é apenas um dos atrativos.

Lembra que falei que na Locaweb o ambiente de homologação levou “apenas” 9 dias para ir ao ar e quando isso aconteceu o ambiente de produção foi “pro espaço”? Pois é, na Configr em 1h o ambiente de produção e homologação estavam no ar sem a necessidade de acionar o suporte e muito menos de abrir ticket.

Depois que migrei tudo para a Configr só me preocupei com 2 coisas: 1) propagar os domínios, pois a cliente tem 6 que mandam para a mesma aplicação e 2) a aplicação em si. Resolvida a questão dos domínios, preocupei-me exclusivamente em desenvolver.

Esquecemos de um detalhe

Como mencionei, com a ajuda da Configr foi montado um plano de ação que aumentaria recursos do cloud durante as fases mais intensas do concurso: encerramento das inscrições e encerramento das votações populares. No entanto, esquecemos de um pequeno detalhe: a cliente optou por pagamento em boleto. Por nunca ter feito esse dimensionamento na Configr não tinha conhecimento dos detalhes, era necessário pagar o proporcional do novo tamanho do cloud até o fechamento da fatura. Em resumo, após pagar o proporcional era possível solicitar o dimensionamento ou mesmo agendar. Ficamos de mãos atadas, tivemos de permanecer o cloud de 2GB que tínhamos contratado de início, pois era um final de semana e o financeiro da cliente não autorizaria tal pagamento, mesmo sendo uma situação emergencial.

A experiência foi incrível!

Como dito, inicialmente contratamos o cloud Ilimitado 2G da Configr:

  • 2GB RAM,
  • 1 core de processamento
  • SSD de 50GB

Bem modesto comparado aos 32GB com 8 cores da Locaweb. Porém o cloud aguentou muito bem o tranco. No ápice do concurso, a finalização das inscrições, foram cerca de 42 mil acessos no dia, com uma média de 400 simultâneos. Ao mesmo tempo, diversos serviços em plano de fundo eram executados: alterar intervalo do concurso, barrar novas inscrições após o horário, disparar e-mails transacionais aos inscritos e notificar todos sobre a o encerramento, pouco mais de 70 mil e-mails.

Acredite ou não, o processamento chegou a 341%.

Neste momento acreditei que sairíamos do ar, mas não! Conseguimos serguir firme e receber a maioria das inscrições de última hora, até o horário limite, é claro.

Como ficamos preocupados com a votação, que também causaria um grande volume de acessos, conseguimos migrar para o Ilimitado 4G a tempo. Com isso passamos para 2 core, 80 GB de SSD e 4GB de RAM. Com a votação se encerrando, foram realizados mais de 10 serviços em plano de fundo, o mais pesado deles, disparar novamente os 70k e-mails. E como já presenciado na finalização das inscrições, passamos tranquilos por esta etapa.

Os erros

Como mencionei, tivemos alguns pequenos erros, mas que graças ao trabalho de uma equipe preparada, conseguimos contornar num primeiro momento e sanar imediatamente em seguida.

Quais a lições que ficam?

Com relação ao desenvolvimento, foi uma experência incrível. Por ser um projeto rolling release, perdi a conta de quantas vezes fiquei até 4, 5 da manhã pra deixar tudo preparado para o estágio que entraria às 9h. Outras vezes, que fui ao trabalho e faltando 10 minutos para um estágio do concurso eu ir para o intervalo pra finalizar a funcionalidade necessária.

Coisas não planejadas

Aprendi que sim, é possível escolher o sabor do pastel enquanto a massa está sendo frita. É extremamente arriscado, mas depois que tudo está funcionando a sensação é indescritível. Um exemplo foi para a premiação final, o vencedor seria anunciado ao meio dia de 28/09/2018 e exatamente às 11h49min do mesmo dia eu e mais um envolvido no projeto iniciamos os testes da funcionalidade de indicação dos vencedores no ambiente de homologação (indicar os vencedores, exibir menu do resultado no site, colocar no ar a página do resultado…). No fim, ao meio dia tudo começou a acontecer e, depois de alguns crons rodados e validados, rodei na mão o último envio de e-mails em massa e comemoramos!

Não tivemos um escopo bem definido, uma documentação validada e assinada pela cliente, não tivemos tampouco um alinhamento depois que comecei a reescrever a aplicação. Tudo que eu tinha era um sistema anterior funcionando em partes na minha máquina. Quem já trabalhou com CodeIgniter sabe que com este framework aquela máxima “mas na minha máquina funciona” é levada ao pé da letra. A cada mudança de máquina/server começa a bateria de correções só pra fazer o framework rodar.

Mesmo assim o sistema foi reescrito, ganhou muitas outras funcionalidades que antes não existiam e simplificou muito a vida da cliente.

Firmar parcerias de sucesso

Anos atrás, quando trabalhava na Redsuns e passávamos por um momento caótico, recebemos consultoria de um cara que admiro demais o trabalho, Arthur Furlan. Com ele aprendemos que documentação é importante, TDD, adotamos framework, adotamos padrões, git e começamos a finalmente entender de orientação a objetos. Pois bem, o Arthur é CEO da Configr e quando tive o problema com a Locaweb, falei imediatamente com ele, já com a intenção de sugerir a migração à cliente.

Após ter dados de acessos da edição anterior, conversamos e ele me orientou no dimensionamento do cloud. Também me orientou no plano de upgrade para os momentos de maior acesso.

Esse cuidado que ele teve em me orientar fez muita diferença. Na locaweb simplesmente prezaram em vender um produto caro para a cliente, enquanto que na Configr a preocupação foi com um serviço que atendesse a demanda e, ao mesmo tempo, não tivesse recursos em excesso. E o resultado foi um sucesso.

Por fim, como falei lá no começo, a nenhuma das empresas envolvidas me pagou nada por este post. Até melhor assim, pois o torna natural. Tive a intenção apenas de compartilhar a experiência.

Bônus

Como eu quero ganhar algo – afinal de contas, manter um blog com conteúdos densos sobre programação me toma bastante tempo – vou sugerir a Configr para você também. Abaixo tem um link para você iniciar na Configr. Contratando o serviço da Configr você tem um bônus e eu também 😉

https://cloud.configr.com/signup?rf=e3f5bd6d-59f3-4042-9dd6-2732b8887ba8

 

Menu