O que são os Azure Media Services?

Anunciado para GA em 2013, após alguns ensaios bem-sucedidos, o Azure Media Services era tudo o que precisava para disponibilizar conteúdos ao vivo e a pedido na nuvem. Desde a receção de VOD e feeds lineares, passando pela transcodificação e codificação, encapsulamento (empacotamento) e entrega através da CDN do Azure. O AMS apresentava um conjunto relativamente simples de APIs de gestão para realizar o trabalho, antes de finalmente estabilizar nas APIs V3 que instrumentaram alterações ao processamento de vídeo e áudio, tratamento de DRM FairPlay e alterações à elevada disponibilidade em VOD.

Porquê o fim de vida?

A Microsoft afirma que se deve ao foco noutras áreas de negócio. Além disso, estão a acelerar soluções do Ecossistema de Parceiros da Microsoft. Faz todo o sentido financeiro permitir que os parceiros implementem o seu próprio equipamento na nuvem e o disponibilizem através de marketplaces ou serviços, em vez de tentarem acompanhar o complexo desenvolvimento necessário para apoiar o panorama de media e transmissão.

Curiosamente, isto não é muito diferente da descontinuação dos Akamai Media Services em 2019 – mas com a Akamai a servir (e talvez "antes" do surto de crescimento da Fastly) uma boa fatia marginal do tráfego OTT global, pensei realmente que a sua oferta tinha mais pernas para andar, dados os poupanças de custos a obter com a saída das nuvens públicas para as origens da Akamai.

Finalmente - lembre-se de quando a AWS fez o investimento na Elemental: a sua própria pilha de media era um pouco desprovida de capacidades com o Elastic Transcoder. Outra história onde fazia mais sentido comprar ou fazer parcerias do que tentar acompanhar e competir. Mesmo com os orçamentos da Amazon – isso quer dizer algo.

Então, de quanto tempo disponho?

Junho de 2024. Parece muito tempo, mas essa data vai aproximar-se rapidamente. Ao planear projetos em torno disto – posso atestar que os prazos são levados ao limite quando o ciclo de ponta a ponta é considerado.

Quais são as minhas opções?

A boa notícia é que tem muitas opções – a má notícia é que tem muitas opções

Soluções da Rede de Parceiros Azure

Para quem já tem conteúdo armazenado em Azure Blobs (e faço esta ressalva em relação a outros custos de alteração), esta pode ser uma das abordagens mais económicas em comparação com a extração de conteúdo para a AWS. Se estiver a armazenar ativos intermédios (mezzanine), os custos de saída de TBs ou PBs de conteúdo para algo como a AWS podem tornar-se difíceis de suportar. Fornecedores como a Bitmovin, Telestream e Dolby operam boas soluções no Azure, mas terá de fazer algum trabalho para as integrar, como discutiremos em breve.

Amazon AWS

Possivelmente o melhor conjunto de soluções "cloud-native" em oferta hoje. A AWS fez um trabalho fantástico ao integrar o conjunto de soluções Elemental na empresa. Qualquer pessoa que mude do Azure tem uma subida pela frente, no entanto – e isto pode implicar um aumento de custos não só para integrar, mas para facilitar a simples migração de conteúdos. Se se sentir super corajoso – há sempre a opção de usar o seu Azure blob sob a pilha da AWS! A AWS executa o seu conjunto de soluções como pilhas separadas com alguma sobreposição de funcionalidades – mas para obter a melhor solução escalável e flexível, haverá trabalho a fazer. Bem construído – este será um fluxo de trabalho incrivelmente poderoso com bom rendimento e excelentes capacidades. Mal construído, corre o risco de perder a noção de onde está o seu conteúdo, o que lhe está a acontecer e por que razão não está a escalar.

Google GCP

A Google tem vindo a progredir no setor dos media e do entretenimento, e tem um conjunto de soluções relativamente bom para a preparação e entrega básica de media. A Google é proprietária do YouTube – indiscutivelmente uma das maiores plataformas de transformação de media do mundo, para não falar de uma enorme quantidade de infraestrutura de entrega – pensaria que esta seria a aposta mais inteligente no papel. Para um serviço freemium que gera HLS/DASH básico com algum corte, não terá problemas – mas para algo mais avançado, existem algumas lacunas de solução consideráveis que exigem que elementos / ferramentas / serviços de terceiros sejam integrados no seu fluxo de trabalho.

Mais alguma?

Sim – muitas. Fora dos grandes fornecedores de nuvem pública, existe uma série de fornecedores que disponibilizam ferramentas de transformação e entrega de media baseadas em SaaS e PaaS. Algumas estão bem integradas nas nuvens públicas através de ofertas de marketplace, outras funcionariam muito bem na nuvem, mas teria de implementar / configurar / gerir os elementos circundantes. Começaria uma lista, mas precisaria de fazer a barba antes de terminar. O que é importante, no entanto, é COMO aborda qualquer migração.

O que preciso de avaliar antes de uma mudança?

Análise de lacunas de funcionalidades

A boa notícia aqui é que existem muitas opções por aí – e com uma mudança, provavelmente ganhará mais do que perderá em termos de puras funcionalidades e capacidades – mas isto precisa de ser comparado e avaliado cuidadosamente. O diabo está nos detalhes. Se estiver a fazer coisas mais complicadas, como emendas a meio do segmento, manipulação de manifesto, remapeamento de faixas de áudio ou processamento de fluxos de trabalho HDR – aconselharia a olhar potencialmente para algumas POCs (provas de conceito) para confirmar a funcionalidade e a abordagem antes de prosseguir. Nunca é demais salientar o elemento de teste do lado do cliente e COMO qualquer conteúdo se comporta nos leitores. As variações de versões de especificações entre fornecedores apanham a maioria das pessoas desprevenidas.

Custos de integração e migração

É ingénuo acreditar que a mudança de fluxos de trabalho e cargas de trabalho do Azure não terá um impacto considerável nas integrações e sistemas circundantes. Seja na subida a partir de soluções MAM, monitorização de fluxos de trabalho, armazenamento, entrega a terceiros ou controlo de qualidade (QC). Se estiver a utilizar soluções prontas a usar, parte disto pode necessitar de pedidos de alteração a terceiros. Os custos e o esforço de tempo também terão de ser considerados no seu cronograma geral. Tenha o cuidado de adicionar contingência para permitir desvios.

Análise de custos

Para uma imagem real e realista, qualquer análise de custos deve considerar:

• preço unitário de computação,

• preço de armazenamento,

• custo de transferência,

• custo das integrações com os sistemas circundantes na cadeia,

• custo de monitorização, operações e suporte,

• atualizações de documentação e processos

e vários outros.

Se implementar a partir de ambientes de marketplace, como os fornecidos pela AWS, tome nota de comparar os custos de computação E quaisquer custos de licença adicionais que possam ser necessários. Algumas ofertas de marketplace incluem licenças de software no custo por hora da instância de computação, outras são BYOL (traga a sua própria licença). Se for inteligente com a sua arquitetura e implementação, pode reduzir o seu custo operacional base para valores realmente baixos se não estiver a processar nenhum conteúdo. A taxa de execução normal (BAU) será tipicamente de armazenamento e algumas despesas gerais de serviço, como elementos de rede, etc.

Sei que este é um artigo de alto nível, mas espero que seja uma introdução útil sobre onde focar a sua atenção se estiver numa posição de necessidade de mudança. Finalmente, se desejar uma ajuda ou algumas orientações para começar a mover-se na direção certa – gostaria muito de o ouvir.