Archive for the ‘Development’ Category

Stream Multiplexing for FME Failover in Flash Media Server

As some may wonder, I decided write my posts in English from now, so, anyone can follow the ideas that are discussed here. To start this new era, I decided to talk a bit about how we can do the failover of live streams in Flash Media Server through internal multiplexing of signals, that is, how we can use a single live stream as a backup of several others, without burdening bandwidth available between the Flash Media Encoder and the Flash Media Server.

To get the goal of this idea a little clearer, let’s suppose that we want to perform a live transmission, where we have 3 servers running an instance of Flash Media Encoder each, and we have 3 different signals (eg cameras), linked to a each encoder. If one of these servers crashes, the stream will no longer be published on Flash Media Server, and inevitably users connected to this content will have their experience interrupted. In order to avoid this problem, we can detect that a stream is no longer running, and then send to users the signal of another encoder, in a transparent way, without playback interruption (lost of connection or rebuffering). This approach dispenses the use of a backup server for each active server, which significantly reduces the investment in hardware and bandwidth, in environments with high availability needs.

The main concept behind this approach is the separation between the publishing streams and the viewing streams, which means that the users should not connect directly into the stream published for Flash Media Encoder. In fact, users should connect to a fake stream, and the published content will be dynamically linked to it via a server side Action Script. This idea is very well explained in the article “Building a Live Video Switcher with Flash Communication Server MX“, which was the base of multiplexing for failover concept. To automate this association between publisher stream and viewers, we can use the application.onPublish and application.onUnpublish events, which are triggered when a signal is, or ceases to be published in Flash Media Server.

The challenge now is how to control, automatically, which is the backup stream and which is the main, that is, not simply store a list of active streams, we need to know which stream will be displayed to users if a failure occurs in main stream. One approach is to isolate each stream in a different instance of application, and, in addition, create two different types of applications, one for the main streams (master) and one for the backups. Each master instance will have only one stream available so that users can connect, which means that we will need to have as many instances as the number of live signals.

The main application should store/remove from a list all the active/inactive live streams (via events), so that the first stream of the list always will be associated with the stream being viewed by users. If this stream is unpublished, the application should join the users stream to the next item, which means that the backup will always be the next stream on the list.

The backup application should receive a live signal and publish it in the main applications, performing an internal multiplexing. These internal streams will be stored on main instances as backups, so, all main applications will have the same backup streams. This internal multiplexing can be implemented in a very simple way using the NetConnection and NetStream classes, also available for server side scripting.

To make clear the idea presented above, let’s take a look at this picture:

Failover for FME Streams

Failover for FME Streams

As we can see, this approach is a simple and efficient way to implement the failover of streams published by FME, which is very important in environments where high availability is a imperative requirement, and where the investment resources for bandwidth and hardware are limited.

More information about Flash Media Server Development can be found in Adobe Developer Connection

Advertisements

Scrum, e os benefícios para os Team Members

Freqüentemente leio posts e artigos sobre a utilização do Scrum, entretanto, na maioria das vezes, existe uma grande ênfase nos benefícios obtidos com ele do ponto de vista da empresa, como o aumento na velocidade das entregas, e nem sempre é discutido sobre o que os team members ganham, quais as vantagens para as pessoas que efetivamente desenvolvem as tarefas. Desta forma, achei que seria interessante expor aqui um pouco da experiência que estou tendo na Globo.com, onde atuo como team member de uma equipe desde que adotamos o Scrum oficialmente.

Algumas pessoas, em um primeiro contato com o Scrum, podem apresentar um certo receio sobre uma das prerrogativas propostas pelo framework, que é a disseminação de conhecimento por todo time, com o objetivo de reduzir as chamadas “ilhas de conhecimento” nas equipes. Isto é excelente do ponto de vista da empresa, porém, infelizmente alguns profissionais que detém um conhecimento específico pensam que seu emprego estará “garantido” enquanto ele for o único a dominar determinado assunto. Entretanto, a disseminação do conhecimento por todo time é extremamente positiva para o desenvolvimento profissional de cada um, uma vez que o conhecimento específico de cada membro é compartilhado, estabelecendo uma “via de mão dupla”.

Além disso, cada componente do time é livre para executar qualquer tarefa, seja ele ou não o especialista no assunto. Desta forma, esta transferência de conhecimento pode ser realizada de acordo com a vontade de cada um, até o ponto que o desenvolvedor irá fazer tarefas simples de design, e o designer irá implementar trechos simples de código.

Outro benefício bastante importante é a existência um escopo claro e bem definido daquilo que deve ser realizado, o que evita uma série de transtornos. Ninguém vira a noite se matando para implementar uma funcionalidade não prevista, ou alterando o que foi feito pois houve uma mudança de idéia. No Scrum existe um “compromisso público” que define o que será realizado, não existe margem para alterações não aprovadas pelo próprio time. Além disso, a existência de um backlog priorizado permite uma visão mais clara daquilo que deverá ser realizado, qual é a estratégia e os objetivos existentes.

A existência de reuniões diárias (daily meetings), também ajuda bastante no processo de comunicação entre os membros do time, sendo que cada um sabe exatamente o que o outro fez, e o que irá fazer, e isto é extremamente importante para todos tenham uma visão bem clara do que está sendo feito, quais foram os desafios e como eles foram superados. Finalmente, ao término de cada ciclo (sprint), cada um pode expressar o que foi bom ou ruim no último sprint o que facilita bastante a resolução de problemas de qualquer natureza.

Em suma, o Scrum pode ser bastante positivo também para os profissionais, basta saber aproveitar as novas oportunidades abertas por este modelo de desenvolvimento, em vez de ficar com medo das mudanças que naturalmente vão acontecer.

Keep it Simple

De uns tempos pra cá, desde que começamos a utilizar o Scrum na Globo.com, venho a cada dia reforçando minha idéia de que quanto mais simples, melhor. Muitas vezes, principalmente nós, engenheiros, queremos implementar as soluções mais mirabolantes para problemas muitas vezes não tão complexos, pela simples capacidade criativa que existe em nós. No caso específico de desenvolvimento de software, as vezes ficamos horas e horas tentando otimizar cada linha, cada processo, literalmente escovando bits, para ganhar um mínimo de performance. O problema é que o mercado de internet é extremamente rápido, e existe uma pressão imensa para inovação. Neste cenário, gastar tempo em pontos pouco críticos pode ser desastroso, a medida que a busca por uma solução perfeita pode literalmente impedir que novas funcionalidades sejam implementadas.

Sempre fui adepto do “bom é inimigo do ótimo”, ou seja, a busca ininterrupta por uma solução ótima pode inclusive destruir uma solução suficientemente boa. Entretanto, quando falo “Keep it Simple”, quero dizer: uma vez diante de um problema, tente simplificá-lo ao máximo, crie atalhos nos processos e limite-se naquilo que atende suas necessidades. Não tente criar um canhão para matar uma formiga. Uma solução simples, no meu ponto de vista, é muito mais elegante e melhor que uma solução aparentemente genial. No caso específico de software, quanto mais simples for a solução, mais fácil é o handover para outros membros do time, perde-se menos tempo em desenvolvimento e em manutenção, mais fácil é o teste, existe uma menor quantidade de pontos de falha. Note que ao contrário do que parece, as soluções simples não abrem mão da qualidade em nenhum momento, pelo contrário, elas contribuem para o ganho de qualidade, principalmente à longo prazo. Implementar uma solução simples não significa desenvolver fora dos padrões ou não utilizar as best pratices conhecidas, tanto que, em alguns momentos, ela será mais trabalhosa.

A medida que os membros do time  compartilham esta idéia de simplicidade,  a velocidade do time aumenta, sem comprometimento da qualidade, e os débitos técnicos causados por problemas de implementação tendem a reduzir, uma vez que fica mais fácil integrar novas funcionalidades. No time em que faço parte (time voltado para o produto Globo Vídeos), acredito que todos já tem este mindset, de que entregar muitas coisas simples é melhor do que entregar poucas coisas muito complexas. Por isso, “keep it simple”,  e você vai ver o quanto as soluções simples podem ser extremamente eficientes.