Experiência: Configr e Prêmio Oxford de Design
Post publicado em 01/10/2018 09:10 Última atualização em 24/11/2018 10:09
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 Shop, Configr 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:- Inscrições
- Votação popular
- Voto dos vencedores anteriores
- Finalistas - Seleção do júri técnico
- Divulgação do resultado
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
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.