Resumo

  • A principal afirmação da Pantheon não é hospedagem comum. É a promessa de que equipes de WordPress e Drupal podem manter o estado de mudança sob controle através de ambientes Dev, Test e Live, Multidev, implantação baseada em Git, backups, cache, monitoramento, controles de governança e suporte.
  • Os custos reais permanecem fora do título: compatibilidade de plugins e módulos, comportamento de cache, desvio de conteúdo, limites de rollback de banco de dados, trabalho de CI personalizado, níveis de suporte, esforço de migração, disciplina de handoff de agência e o preço de uma plataforma opinada.
  • A Pantheon é mais defensável para portfólios multi-site, agências, ensino superior, governo e equipes web empresariais que precisam de aceitação de mudança repetível. É menos atraente para um pequeno site único, uma equipe que deseja controle de infraestrutura de baixo nível ou uma organização que não consegue adaptar seus hábitos de lançamento ao modelo da Pantheon.

A Pantheon é fácil de descrever de forma muito ampla. A empresa vende uma plataforma WebOps para WordPress, Drupal e sites front-end, mas a pergunta de compra útil é mais restrita. Uma equipe não está comprando um slogan sobre operações modernas de sites. Está comprando uma maneira de mover uma mudança com segurança através de um conjunto de sites com muito conteúdo, muitas permissões e muito cache, sem transformar cada lançamento em uma negociação privada entre desenvolvedores, profissionais de marketing, agências e administradores.

Essa diferença é importante porque a maioria das falhas de sites não é espetacular. A falha normal é pequena e repetitiva. Um desenvolvedor altera um tema e descobre que o conteúdo ativo atual se comporta de forma diferente dos dados de amostra em um ambiente de desenvolvimento. Um módulo Drupal assume que pode escrever em algum lugar que a plataforma não trata como gravável. Um plugin WordPress afeta a capacidade de cache. Uma equipe de marketing vê uma imagem antiga após um lançamento porque uma camada de cache não foi limpa no lugar certo. Um clone de banco de dados sobrescreve um trabalho que não se esperava ser sobrescrito.

Um contato de suporte sai da empresa e as permissões permanecem bagunçadas. Uma agência cria um fluxo de trabalho que funciona para seus próprios engenheiros, mas é difícil para o cliente herdar.

O caso da Pantheon começa com uma peça útil de disciplina: código e conteúdo são tratados de forma diferente. O código sobe pelo caminho de lançamento. O conteúdo desce do site ativo para teste e desenvolvimento. Isso parece simples, mas é um dos fatos operacionais centrais de um portfólio CMS. O código pode ser versionado. O conteúdo do banco de dados, mídia carregada e muitas alterações editoriais não podem ser tratados como um histórico Git limpo. O modelo Dev, Test e Live da Pantheon é projetado em torno dessa distinção.

A plataforma tenta fazer com que as equipes testem o código contra o conteúdo que se assemelha ao site ativo atual antes de colocar a mudança diante dos leitores.

Portanto, o produto não é melhor julgado por uma lista de verificação genérica de hospedagem. O melhor teste é a mudança web aceita. Uma mudança é aceita apenas quando a equipe sabe o que mudou, quem aprovou, por qual ambiente passou, se o código e o conteúdo atual foram testados juntos, se as atualizações de banco de dados foram consideradas, se o comportamento de cache foi tratado, se o desempenho permaneceu aceitável, se o rollback é possível e se o proprietário do negócio pode conviver com o resultado. Um lançamento que apenas chega ao ambiente ativo não é suficiente. Deve chegar em um estado que possa ser explicado e suportado.

O Limite do Produto é WebOps Opinado

A Pantheon é uma plataforma gerenciada, não uma conta de infraestrutura em branco. Esse limite é tanto o valor do produto quanto sua restrição. A empresa apresenta a plataforma como uma camada all-in-one de infraestrutura, fluxo de trabalho e governança para equipes web. O material público do produto descreve hospedagem gerenciada, ambientes Dev e staging, fluxo de trabalho de implantação, controle de versão integrado, backups, logs, acesso à linha de comando, CDN Global, cache, monitoramento de desempenho, atualizações do Autopilot, Multidev, gerenciamento de portfólio, segurança e suporte.

A documentação descreve uma plataforma SaaS de WebOps e hospedagem para aplicações front-end baseadas em Drupal, WordPress e React.

A palavra importante é "opinado". A Pantheon não está tentando se tornar a nuvem privada de todas as equipes. Ela padroniza a forma como os sites CMS são construídos, preparados, implantados e operados. Essa padronização pode remover uma grande quantidade de trabalho indiferenciado: manutenção de servidor, configuração manual de ambiente, scripts de implantação ad hoc, sites de staging inconsistentes, edições de painel não rastreadas e propriedade pouco clara em muitos sites.

Também pode frustrar equipes que estão acostumadas a alterar a configuração do servidor diretamente, escrever em qualquer lugar na base de código, executar seu próprio CI nos mesmos servidores ou tratar o CMS como uma aplicação PHP completamente sem restrições.

É por isso que o limite técnico da Pantheon precisa ser mantido claro. Seu caso mais forte está em torno de sites WordPress e Drupal, além de padrões de hospedagem front-end suportados. Não é uma resposta geral para toda carga de trabalho de aplicação. Se uma equipe precisa de trabalhadores em segundo plano arbitrários, serviços não-CMS, topologia de rede personalizada, edição direta de regras Varnish, arquitetura de banco de dados especial ou controle de infraestrutura excepcionalmente granular, as proteções da plataforma podem se tornar um custo.

Se uma equipe precisa executar muitos sites CMS com disciplina de lançamento repetível, essas mesmas proteções podem se tornar a razão para comprar.

O limite também importa comercialmente. A Pantheon compete com hospedagem gerenciada WordPress, plataformas especializadas em Drupal, provedores mais amplos de plataforma como serviço, implantações de nuvem gerenciadas por agências, contas de nuvem autogerenciadas e suítes de experiência digital empresarial. Não deve ser tratada como intercambiável com o VPS mais barato ou com um programa Kubernetes totalmente personalizado. O produto está vendendo um padrão operacional gerenciado. O comprador tem que decidir se o padrão corresponde ao trabalho semanal real.

Para muitas equipes web, esse trabalho semanal é mundano, mas caro. Alguém tem que aplicar atualizações CMS. Alguém tem que testar a compatibilidade de plugins e módulos. Alguém tem que criar um ambiente de pré-visualização para um recurso. Alguém tem que copiar o conteúdo atual para teste sem destruir os dados errados. Alguém tem que decidir se um lançamento pode ir ao vivo durante um pico de tráfego. Alguém tem que inspecionar o desempenho quando usuários logados bypassam o cache. Alguém tem que responder a um proprietário de negócio que diz que a nova página inicial ainda mostra a imagem antiga.

O valor da plataforma depende de quanto desse trabalho se torna mais previsível.

(continuação traduzida similarmente...)