a

Tecnologia que interessa!

Tecnologia da informação aplicada - por Christian Guerreiro.

Notícias e novidades em Tecnologia da Informação, Dicas de Apps para Android e iPhone, Big Data, Computação em Nuvem, Governança de TI, ITIL, COBIT, Segurança, Software Livre, Virtualização

Página do Tecnologia que Interessa no Facebook! Twitter do Tecnologia que Interessa! Perfil Google+ de Christian Guerreiro - Tecnologia que Interessa!

quinta-feira, 25 de setembro de 2014

Ripple, o protocolo de transferência monetária instantânea mundial

Ripple, o protocolo de transferência de dinheiro mundial

O Ripple é uma iniciativa que busca estabelecer um "protocolo aberto para transferência monetária via web", ou seja, seria um facilitador de transferências de dinheiro entre instituições. A idéia é que o protocolo se torne o SMTP ou HTTP do dinheiro. Um plano bastante ambicioso, na minha opinião.

Uma das características mais interessantes do protocolo é que ele é agnóstico em relação à moeda, o que significa que a conversão entre moedas dos mais diversos países pode ser feita sem envolver as criptomoedas como Bitcoin, por exemplo, que é vista com ressalvas por muitos.

O protocolo passou a ser suportado recentemente por dois bancos dos EUA, o New Jersey-based Cross River Bank e o CBW Bank, o que sugere que há alguma possibilidade de sucesso da iniciativa.

Entretanto, os entraves, especialmente regulatórios, são muitos, e acredito que será difícil, ou pelo menos levará muito tempo, até que este tipo de idéia seja bem aceita em termos mundiais.

De todo modo, é fato que a tecnologia continua transformando de maneira significativa a maneira como vivemos e lidamos com dinheiro, nos comunicamos, nos divertimos, comemos, enfim.

E você, acha que o Ripple pode decolar, ou vai fazer um "voo de galinha" ? :)

Via GigaOM.
Mais...

Shellshock seria falha de segurança pior que Heartbleed

Linux - falha no bash, shellshock é pior que heartbleed

Mais um dia, mais uma falha de segurança. Mais uma falha GRAVE de segurança. Tem gente dizendo que é muito pior que o heartbleed.

De acordo com o especialista Unix Stéphane Chazelas, que reportou a falha à Red Hat, ela envolve a manipulação, pelo BASH, de variáveis de ambiente especificamente mal formadas com intuito malicioso, e permitiria a execução de comandos que deveriam ser de acesso restrito.

Levando em conta que o BASH é o interpretador de comandos padrão de muitas distribuições Linux, está presente no MAC OS X e provavelmente em muitos sistemas embarcados derivados do Linux, a falha é muito preocupante.

Acrescente a isso o fato de que 60% da web está hospedada em servidores Linux, e que mecanismos como CGI fazem uso do shell, e temos uma situação realmente alarmante.

Não bastasse tudo isso, as informações dão conta de que a falha existe há bastante tempo, e, diferentemente do Heartbleed, que afetava uma versão específica do OpenSSL, pode ter sua correção bastante dificultada, especialmente em sistemas legados.

Imagine os milhares de roteadores wifi com DDWRT e OpenWRT espalhados pelo mundo, por exemplo. Quem vai atualizar esses sistemas ?

Penso que isso só comprova a necessidade de abordar a questão da segurança em diversas camadas, de forma que uma falha de difícil correção como esta possa ser contornada através do uso de outra solução de segurança que atue em outro nível.

E você, o que pensa a respeito ? Compartilhe comigo!

Update: pra quem usa Ubuntu, orientações pra atualizar o bash e eliminar a vulnerabilidade aqui.

Via GigaOM.
Mais...

segunda-feira, 22 de setembro de 2014

Openstack = VMware de pobre ?


Vasculhando o backlog de emails atrasados sobre a VMware pra escrever algo aqui no blog sobre as novidades do VMworld desse ano, me deparo com este interessantíssimo artigo do Cloud Architect Musings sobre se o Openstack deve ser um automóvel ou um cavalo mais rápido.

A questão posta faz uma alusão à famosa frase de Henry Ford: "Se eu perguntasse às pessoas o que elas queriam, elas teriam dito cavalos mais rápidos.".

A afirmação sugere que nem sempre os clientes/usuários sabem o que é melhor pra eles, e provavelmente por isso que Steve Jobs era "contra" as pesquisas de mercado (leia sobre a controvérsia em torno da frase aqui).

Bom, mas voltando ao Openstack, a alusão à frase de Henry Ford se deve ao fato de que, de acordo com informações do CAM, os principais pedidos de melhorias no Openstack estão relacionados à implementação de funcionalidades comuns há algum tempo nas soluções proprietárias, em especial a VMware, como o vMotion e o High Availability. Isso sugere que os clientes querem mais um "VMware mais barato" do que uma solução inovadora.

A questão colocada é se este é realmente o caminho, ou se os desenvolvedores do Openstack deveriam fazer como Ford e Jobs, ignorar os pedidos dos clientes e investir em algo diferente, novo.

E é aí que chegamos à figura lá do início. A análise do tipo de funcionalidade que faz sentido oferecer nos tempos atuais passa pela identificação dos perfis de aplicação que o IDC classifica, em tradução livre minha, como 1ª, 2ª e 3ª geração.

O que temos hoje, segundo o artigo, é a realidade composta pela proliferação de plataformas como o Openstack e Amazon Web Services, voltados para aplicações de 3ª geração, ainda que entre 80 e 90% das aplicações corporativas sejam de 2ª geração.

Daí a discussão sobre o rumo que o Openstack deve tomar.

Desenvolver funcionalidades "estilo VMware" seria caminhar na direção do cavalo mais rápido, sendo defendido pelos mais pragmáticos, sob o argumento de que este seria o caminho para evitar que as empresas adotem outras soluções, que certamente irão amadurecer com o tempo, o que faria com que estas empresas nunca enxerguem a necessidade de migrar para o Openstack.

Ignorar as demandas dos clientes seria caminhar na direção de Jobs e Ford, focando em inovação, em preparar o Openstack pra atender melhor as aplicações de 3ª geração, aguardando que os clientes enxerguem a necessidade inevitável de migrar.

A solução defendida pelo Kenneth, entretanto, é o que ele chamou de "abordagem bimodalidade", que consiste em criar uma arquitetura que permita atender aos dois tipos de necessidade, numa infraestrutura comum porém com isolamento entre os mundos distintos representados por uma "zona de legado" (que acomodaria aplicações de 2ª geração) e uma "zona de nova geração", baseada em hypervisors de código aberto e com foco em aplicações de 3ª geração.

Curiosamente, uma das novidades lançadas no VMworld 2014 foi justamente uma integração maior entre Openstack e VMware, chamada de VMware Integrated Openstack (VIO) que permite utilizar o VMware vSphere como hypervisor gerenciado pelo Openstack.

Interessante observar o desenrolar dessa história.
Mais...

quarta-feira, 10 de setembro de 2014

Bania.io: mais produtividade com um simples email



Descobri um serviço curioso hoje, chamado Bania.io. A idéia simples e genial do serviço consiste em enviar um email para um endereço que reflita algo que você tenha como meta ou hábito, com o objetivo de registrar sempre que realizar algo que contribua para aquela meta ou hábito.

Ao enviar um email para blogar@bania.io, recebi a resposta da imagem acima, que representa o quão "produtivo" fui com relação à minha meta de blogar no último mês.

E o mais legal é que não há necessidade de cadastro, basta enviar um email pra "NomedaMetaTarefaHabito"@bania.io sempre que realizar alguma atividade produtiva. É possível enviar vários emails pra vários endereços e assim acompanhar suas metas de maneira ridiculamente simples.

O serviço se baseia na "filosofia" de produtividade denominada "Don't break the chain", que recomenda registrar em um calendário sempre que fizer algo produtivo, de forma que, com o tempo, o calendário servirá de estímulo para que faça cada vez mais coisas produtivas e alcance seus objetivos.

Há diversas técnicas de produtividade, e cada uma delas tem aspectos bem interessantes que volta e meia me identifico, mesmo sem conhecer detalhadamente as técnicas, como no caso das prioridades baseadas no tempo, que percebir ser bem comum em várias delas.

E você, usa alguma técnica pra ser mais produtivo ? Compartilhe aqui comigo!

Mais...

segunda-feira, 8 de setembro de 2014

Ferramenta Microsoft migra máquinas virtuais VMware e Amazon

Ferramenta Microsoft migra máquinas virtuais VMware e Amazon

A Microsoft está preparando uma ferramenta que irá migrar cargas de trabalho físicas e virtuais para a sua nuvem Azure. Um preview limitado do novo Migration Accelerator foi liberado, e suporta máquinas físicas e virtuais (VMware e Hyper-V), bem como Amazon Web Services.

O lançamento da nova ferramenta de migração vem na esteira das notícias de que o serviço de nuvem da Microsoft tem crescido mais que a Amazon.

Segundo a Microsoft, o Migration Accelerator "automatiza todos os aspectos da migração, incluindo a descoberta de cargas de trabalho na sua origem, instalação de agente remoto, adaptação e configuração de endpoint".

A tecnologia que permite as migrações vem da InMage, adquirida em julho pela Microsoft, e cuja solução baseada em appliance captura dados continuamente com base nas mudanças de sistemas Windows e Linux, para, em seguida, realizar backups locais ou replicação remota através da rede.

Mais...

quarta-feira, 27 de agosto de 2014

Remix of the Century - 110 anos de rankings da Billboard pra ouvir quando quiser!

Remix of the Century - 110 anos de rankings da Billboard

Que tal ouvir qualquer música do famoso ranking da Billboard nos últimos 110 anos? Legal, né? Pois é exatamente isso que o projeto "Remix of the Century" oferece.

Achei a idéia sensacionalmente extraordinária! Entre no site, clique na "bolinha" e descubra detalhes da música, podendo ouví-la no Spotify ou no Tomahawk.

É possível ainda escolher opções que indicam, através de cores e posição no gráfico, se a música é dançante, quanto tempo ficou nas paradas, a duração, se é ao vivo, se é barulhenta e muito mais!

Enfim, um passatempo muito divertido e informativo pra quem gosta de música.

E então, o que achou do projeto? Fala aí!


Mais...

Uber vs Lyft: o mercado de "caronas" está bombando!

Uber Táxi Carona Aplicativos Android Google Play

O The Next Web informa que a briga "esquentou" entre o controverso app de caronas Uber e seu principal concorrente, o Lyft. Não bastasse a revolta dos apps de táxi (e dos próprios taxistas), agora a batalha envolve um concorrente mais direto, que teria usado táticas "pouco ortodoxas", pra dizer o mínimo. Transcrevo a seguir trecho do TNW:
Lyft’s claims against Uber are baseless and simply untrue. Furthermore Lyft’s own drivers and employees, including one of Lyft’s founders, have canceled 12,900 trips on Uber. But instead of providing the long list of questionable tactics that Lyft has used over the years, we are focusing on building and maintaining the best platform for both consumers and drivers.
These attacks from Lyft are unfortunate but somewhat expected. A number of Lyft investors have recently been pushing Uber to acquire Lyft. One of their largest shareholders recently warned that Lyft would “go nuclear” if we do not acquire them.  We can only assume that the recent Lyft attacks are part of that strategy.
Pegou pesado, não ? A alegação de que até um dos fundadores do Lyft se deu ao trabalho de cancelar caronas no Uber é, se confirmada, "nigrinhagem", como diriam alguns amigos baianos. O número total de cancelamentos também impressiona: 12.900!

É, parece que esse negócio de carona é da China, hein?

Aliás, descobri que o Uber já está diversificando os serviços, e além de integrar opções de taxi, agora faz até delivery. Onde isso vai parar?

Espero que não pare antes de chegar a Salvador :)

E você, o que acha desta controvérsia toda? Já usou o Uber? Gostou? Odiou?
Mais...

segunda-feira, 25 de agosto de 2014

ITIL ou DevOps ? O que você precisa saber sobre dois dos métodos mais adotados do mundo!

Mais uma vez me deparo com uma daquelas situações em que um texto simplesmente sensacional me deixa tão entusiasmado que me vejo na obrigação de compartilhá-lo com você.

O site australiano IT News traz uma análise extremamente útil sobre os dilemas atuais que envolvem duas das siglas mais comentadas nos últimos anos: ITSM e DevOps.

Deleite-se com mais este excelente texto, em tradução e adaptação livres deste blogueiro.

Há uma batalha feroz em curso sobre a melhor maneira de abordar os negócios de TI, com duas grandes escolas de pensamento competindo pelo domínio: IT Service Management (ITSM) e DevOps.

ITSM favorece um processo formal, planejado pela organização de TI, enquanto DevOps enfatiza um estilo dinâmico, mais fluido, livre das amarras da burocracia. Eles são, se você perguntar aos defensores mais estridentes de qualquer abordagem, a antítese um do outro.

Então, quem está certo? E o que são estas abordagens, de qualquer maneira?

O que é ITSM?


Information Technology Service Management (GSTI no Brasil) começou a vida dentro da IBM em 1972, fruto de oito anos de pesquisa em Information Systems Management Architecture (ISMA), que culminou com a publicação de A Management System for the Information Business in 1980.

Essas idéias foram construídas ainda em 1986 no Reino Unido, pela Agência Central de Computação e Telecomunicações (CCTA) - um órgão do governo, dada a difícil tarefa de melhorar a qualidade e eficiência de TI. A CCTA já havia desenvolvido o Structured Systems Analysis and Design Method (SSADM) para desenvolvimento de software, e o PRojects IN Controlled Environments (PRINCE) para gerenciamento de projetos.

Uma equipe liderada por Peter Skinner e John S. Stewart trabalhou com várias empresas de consultoria, incluindo IBM, para desenvolver o "pesado" Government IT Infrastructure Management Method, ou GITTMM. A IBM forneceu à equipe CCTA um conjunto de checklists para gerenciamento de serviços de TI derivados do seu trabalho sobre a referida ISMA, e a equipe expandiu esses conceitos para definir boas ("melhores") práticas conhecidas. O princípio orientador foi, de acordo com Stewart, simples:
"A abordagem padronizada pode ser adaptada por organizações individuais como base para os seus processos próprios, repetitivos."
O GITTMM foi mais tarde renomeado para IT Infrastructure Library (ITIL) por duas razões principais: em primeiro lugar, porque não era um método, e em segundo lugar, com a palavra "governo" o nome teria desanimado a adoção das idéias para além dos departamentos governamentais.

O ITIL define essencialmente que processo uma organização de TI deve seguir para tudo, desde como implantar um novo aplicativo, como definir a política de segurança, de como controlar licenças de software a como lidar com as chamadas de suporte. E três décadas após a necessidade de tal idéia ser reconhecida pela primeira vez, o ITIL é hoje mais ou menos onipresente. Se julgado pela concepção de Stewart do princípio central da biblioteca, o projeto teria de ser considerado um sucesso retumbante.

E ainda assim o problema original que se propôs a resolver - que os projetos de TI não estavam à altura das expectativas de alta qualidade ou de baixo custo - não parece ter sido resolvido.

Depois de quase 30 anos de ITIL na prática, ainda ainda lemos sobre falhas em rotinas de TI e em larga escala.
As páginas de iTnews estão continuamente cheias de argumentos para demonstrar porque.

O consultor Greg Ferro é um crítico ferrenho do ITIL.

"A premissa fundamental ITIL é que atividades de tecnologia podem ser segmentadas como máquinas ou funções de trabalho em uma fábrica onde cada tarefa pode ser atribuída a uma máquina, com recursos humanos fixos aplicados à tarefa e financiamento aplicado à máquina", diz ele. "Isso simplesmente não funciona quando as máquinas e processos da fábrica sofrem mudança transformacional a cada três a cinco anos."

"ITIL não é sobre a entrega ou excelência. Na minha experiência, ITIL e PRINCE2 evitam a excelência através de um foco em entregáveis e gestão de custos."

Ele está convencido de que ITIL teve seu dia e que é hora de seguir em frente.

"Na última década, tenho trabalhado para dezenas de empresas que utilizam modelos ITSM/ITIL e todas elas eram locais de trabalho miseráveis ​​e infelizes", diz ele. "Quando eu trabalhei em empresas que não usam ITIL, achei que eram ótimos lugares para trabalhar, enquanto o valor real do negócio estava sendo criado e entregue."
"É sobre a felicidade. ITIL é igual a miséria e infelicidade. Quem quer isso?"

Leia mais enquanto explicamos a escola de pensamento oposta...

O que é DevOps?

Muitos que têm manifestado insatisfação com processos ITIL descobriram que o modelo DevOps - uma extensão da metodologia ágil - resolve muitas questões que ITIL e ITSM não conseguem.

DevOps como conceito ganhou destaque em 2009, principalmente com o lançamento de "DevOps Days" na Bélgica por Patrick Debois. DevOps é uma palavra que combina Desenvolvimento e Operações, que descreve o que parece ser a síntese da abordagem: desenvolvimento e operações trabalhando em conjunto.

A maior dificuldade com DevOps é que ninguém, nem mesmo seus defensores, parece bastante certo do que DevOps é exatamente. Alguns chamam de método de desenvolvimento de software, alguns uma abordagem para o gerenciamento de TI, enquanto outros o chamam de "movimento global".

O ponto em comum na descrição DevOps é em grande parte uma reação à abordagem de silos tomada por muitas empresas quando implementam processos do ITIL.

No mundo ITIL, os desenvolvedores são responsáveis ​​por atualizações e alterações, enquanto as operações de TI são responsáveis ​​por manter tudo funcionando. Esta abordagem leva muitas vezes a incentivos incompatíveis, onde a operação é motivada a reduzir a mudança (e manter as coisas estáveis), enquanto o desenvolvimento é totalmente sobre mudar as coisas.

A ascensão da abordagem Agile para desenvolvimento de software no início de 2000 - e sua ênfase em ciclos de liberação rápida - colocou pressão sobre os processos formais de gestão de mudança e de transição de serviços recomendados pelo ITIL. Se um comitê de mudança só se reúne uma vez por semana, liberações em produção não podem acontecer mais rápido. Mas se a empresa segue Agile ao pé da letra, como muitas empresas on-line fazem, você pode liberar mudanças em produção várias vezes por dia. Os dois mundos não se encaixam muito ordenadamente.

Portanto, assim como a abordagem Agile para desenvolvimento de software substitui o método cascata SSADM, o DevOps visa substituir a formalidade lenta dos processos ITIL quando se trata de operações. DevOps requer que os desenvolvedores possuam o ciclo de vida completo de uma aplicação, desde o desenvolvimento, testes, implantação e suporte em produção, todo o caminho até o descomissionamento.

As grandes empresas online como o Flickr têm compartilhado sua abordagem de fusão de desenvolvimento e operações em diversas conferências, e a técnica tem ressoado com aqueles também com pressa para entregar valor aos clientes.

A pedra angular da abordagem DevOps é a automação. Sem ela, as grandes organizações não poderiam conceber tais ciclos de liberação rápida, sem introduzir erros. Ferramentas como o Puppet, Jenkins e Selenium são todas voltadas para automatizar tarefas que eram anteriormente centradas em humanos. Em vez de um comitê de mudança de seres humanos que se reúne uma vez por semana, um teste de software automatizado determina se um lançamento está pronto para implantação em produção.

As ferramentas de automação já existem há décadas, mas a sua utilização sempre foi um pouco limitada. O humilde utilitário UNIX make foi criado em 1976, e as ferramentas subseqüentes, mesmo internas da HP como a ferramenta MEDUSA, podem pedir antiguidade em relação a ferramentas mais recentes como Puppet, Ansible, e Jenkins.

Mas como acontece com tantas tecnologias, sem dúvida, as ferramentas anteriores chegaram muito cedo. Simplesmente não havia necessidade generalizada suficiente para serem utilizadas fora de nichos ou empresas específicas. O estilo DevOps de automação explodiu em popularidade porque o timing estava certo.
Automação tem sido muito demandada desde a virada do milênio, inicialmente para as grandes empresas online como Google, Yahoo, Facebook, entre outros. O sucesso dessas empresas dependia de economias de escala para o sucesso comercial, e ninguém podia se dar ao luxo de contratar um grande número de seres humanos para alcançá-la. As tarefas de curadoria de resultados de pesquisa, execução de leilões do AdWords, e mostrar quais dos seus amigos tornaram-se solteiros são impossíveis para seres humanos, quando se tem milhões de membros. Pagando um desenvolvedor realmente bom o triplo do salário de mercado para escrever software que substitui 15 administradores de sistemas parece um bom negócio.

A automação também cabe na cultura do desenvolvimento online da 'era digital'. Técnicas e códigos originalmente desenvolvidos por estas grandes empresas online foram liberados para o mundo em geral (considere o Apache Hadoop e a biblioteca de interface de usuário do Yahoo!), geralmente muito tempo depois que permitiu qualquer vantagem competitiva significativa para a empresa original. É mais fácil para uma ferramenta ou prática para se tornar amplamente adotada, se muitas pessoas sabem que a ferramenta existe, e ainda mais fácil, se o custo de aquisição é baixo. Operações "digitais" de hoje dentro de bancos ou empresas de telecomunicações são frequentemente reciclagem de código desenvolvido para redes sociais uma década antes.

Até o final dos anos 2000, uma massa crítica de ferramentas e técnicas que tinham surgido começaria a desafiar seriamente o domínio do ITIL.

Mas será que isso realmente tem que ser uma escolha difícil entre ITIL ou DevOps?

Podem as duas abordagens co-existir?

Leia sobre como os líderes empresariais discutem essa opção...

Lições do passado, presente e futuro

Mudanças culturais à parte, a causa raiz do crescimento do DevOps se dá pelos benefícios acumulados através de um maior uso de automação.

Ela evita muitos dos famosos problemas de comunicação entre silos, principalmente porque, na maioria dos casos, os seres humanos que poderiam se comunicar foram substituídos por computadores. Ao contrário dos humanos, os computadores fazem exatamente o que são ditos pra fazer, então não há essa coisa de falha de comunicação. Os computadores também fazem tarefas repetitivas com grande precisão. Seria uma abordagem ITIL funcional, se a maioria dos seres humanos fossem substituídos por Jenkins, Puppet e scripts shell?

Don Meij, CEO da Domino Pizza, diz que os problemas operacionais que afligem a maioria das organizações de TI têm geralmente mais a ver com a implementação do que com a escolha da abordagem.

"Muitas empresas tornam tudo uma questão de processo", diz ele. "CEOs se apaixonam por processos. É quase como se justifica o que se faz. É o câncer de uma organização se você não gerenciar adequadamente."

Peter Nikoletatos, diretor de TI atuando na Universidade de New England, diz que o IT Service Management e ITIL ainda serão relevantes no futuro. Mas as organizações precisam melhorar a forma como aplicam.

"ITIL é um framework que exige adaptação", diz ele. "A maioria das organizações erram ao buscar muita sofisticação. Isso torna as coisas muito burocráticas."

"O entusiasmo para execução ao implementar ITIL deve ser moderado. Você precisa ter um cronograma realista. Construir os serviços de forma incremental. Comece com coisas simples: gerenciamento de incidentes e gerenciamento de problemas."

"Do ponto zero para o ITIL totalmente implantado pode levar de dois a três anos. Isso é um investimento significativo de tempo. Você não tem que fazer tudo isso."

"Nem todas as organizações se prestam ao Agile", continuou ele. "ITIL é apenas uma maneira de pensar sobre um problema, mas não a única. ITIL é conveniente porque a maioria das pessoas entende. Com o Agile, ainda estamos aprendendo como usá-lo. Demora alguns anos para construir provas de que isso funciona".

O que confunde tudo é o ritmo acelerado de mudanças no setor de TI em geral, cortesia da Lei de Moore. O tipo de automação possível hoje era impensável em meados dos anos 80, ao mesmo tempo, a explosão de dados e processamento de dados criou novos problemas que não existiam então. Com a paisagem mudando sob seus pés tanto assim, pode uma abordagem para gerenciar as coisas realmente cobrir todas as bases?

Para o deleite dos consultores em todos os lugares, a resposta sobre adotar ITIL ou DevOps parece perpetuamente ser: "Depende."

Como a velha piada de gerenciamento de projetos: você normalmente só pode escolher duas das três variáveis ​​- rápido, barato e bom. Tanto ITIL quanto DevOps pretendem buscar os mesmos objetivos - resultados finais de negócio melhores. Poderia ser o caso de que ITIL foi otimizado para qualidade boa e barata, com menos ênfase na velocidade, enquanto DevOps oferece um ponto de otimização diferente - muito mais rápido e, invariavelmente, mais barato. A pergunta que muitos estão esperando para responder é se ele vai entregar a mesma qualidade.

Uma maneira mais construtiva de fazer uma escolha entre os dois é avaliar o custo da mudança para qualquer solução.

O software se beneficia de mudança rápida, porque o custo de mudança é baixo. Quanto mais baixo o custo da mudança, mais mudança você pode se dar ao luxo de contemplar. Mas o hardware raramente é tão fácil mudar. Aqueles que implantam hardware ainda precisam considerar as ramificações de longo prazo de suas ações, ou, pelo menos, o impacto do custo de errar e ter que mudar.

Faz sentido usar a técnica que combina a quantidade e o custo de mudanças ao seu ambiente. Algo que não muda com freqüência, e custa muito quando isso acontece, requer um planejamento cuidadoso e de gestão da mudança. Mas, para as coisas que são relativamente fáceis de mudar e não custam tanto, tentar muitas opções diferentes rapidamente faz muito mais sentido.

Nessa base, a necessidade de reinvenção é um pouco exagerada. Não há nada que diga que processos ITIL não podem ser automatizados. Ele é, afinal, apenas uma estrutura, pronta para ser adaptada às especificidades do seu negócio, enquanto continua a fornecer uma maneira padronizada de pensar sobre problemas de negócios.

Adeptos ITIL podem aprender muito emprestando idéias do DevOps, pois adeptos do DevOps tendem a reciclar seus softwares de gerenciamento de configuração e compartilhar receitas Puppet através da internet.

Compare e contraste

 ITILDevOps
Optimizado paraEconomia de escalaVelocidade para o mercado
Despesas de execuçãoAltaBaixa
Tempo para execução2-3 anos6 meses+
Níveis de pessoal necessárioMédio para AltoBaixo para Médio
EstabilidadeBem estabelecidaAinda em evolução
Habilidades de mercado disponíveisAmplamente disponívelPoucos, mas em rápido crescimento
Melhor paraProcessos padronizados, repetitivosInovação
Mais...

Seguidores

Tecnologia do Blogger.