Arquivo da tag: Microsoft

O que é DevOps e será que você deveria aderir, ou não..?

Existem sempre muitas tendências e “buzzwords” acontecendo no setor de TI. DevOps é mais uma destas palavras que circulam já faz alguns anos e ainda causa muito barulho e até um pouco de confusão. A seguir, pretendo esclarecer e desmistificar o tema, apresentando conceitos básicos que podem ser úteis na hora de decidir qual o momento de aderir à cultura DevOps no seu time ou empresa.

Você se recorda de ter brincado de Lego com seus amigos alguma vez em sua vida, criando e recriando diferentes cenários? Apesar de parece estranho, se você já fez isto alguma vez e gostou, é provável que goste da prática de DevOps e seja aquela pessoa que fará a diferença no seu time por compreender bem o processo de criar e recriar cenários.

O sucesso – e obviamente o fracasso – na prática do DevOps está relacionado à forma em que você trabalha para que algumas engrenagens básicas, que movimentam a TI, funcionem de maneira sincronizada. São elas: Pessoas, Processos, Ferramentas e Colaboração.  É fundamental começar a montagem dos blocos com estes quatro elementos em mente.

Antes de abordar o conceito básico de DevOps, é bom entender o que não é DevOps: Analistas, Operadores, Engenheiros de Software e quaisquer outras funções ou profissões não são DevOps, ou seja, não existe o famoso Analista de DevOps, a não ser em ambientes onde DevOps não é compreendido corretamente. O mesmo se aplica a um departamento ou softwares de automação e orquestração, que muitas vezes são descritos como DevOps. Softwares como Jenkins, Juju, Chef, Terraform etc. são excelentes ferramentas que contribuem na automação (e orquestração) de processos, mas não deve ser confundidos com o conceito de DevOps.

A justificativa para o que mencionei acima é bem simples: O Conceito de DevOps está relacionado à cultura utilizada por um grupo de pessoas que atuam de forma colaborativa durante o ciclo de vida de um serviço de TI. O grupo de pessoas pode ser formado por Analistas de Sistemas, Analistas de Suporte, Programadores, Operadores, Analistas de QA, Arquitetos de Solução entre outros, buscando a entrega do serviço do início ao fim. Estas pessoas trabalham de forma colaborativa e criam processos, que ao atingirem um alto nível de maturidade confiabilidade, podem – devem – ser automatizados através de ferramentas.  Assim sendo, temos conectados os quatro elementos básicos que começam a compor a Cultura e fizemos a fusão dos times de Desenvolvimento e Operações criando o nosso DevOps.

Além deste entendimento básico da estrutura, existem muitos outros conceitos envolvidos na Cultura DevOps, difundidos na comunidade engajada nesta prática. Um destes conceitos refere-se a outro conjunto de quatro elementos conhecido como CAMS (em inglês, refere-se a “Culture, Automation, Measurement, Sharing”). Em tradução livre: Cultura, Automação, Medição (ou Medir), Compartilhamento. É possível conectar e montar os blocos entre Engrenagens e CAMS facilmente, pois, a Cultura está relacionada com as Pessoas e ao Compartilhamento. A Automação está diretamente relacionada aos Processos e Ferramentas. E por último a Medição relacionando-se às quatro engrenagens básicas (Pessoas, Processos, Ferramentas e Colaboração).

A representação a seguir foi criada apenas para efeito didático e pode ser organizada e reorganizada de várias formas, movendo os elementos, inserindo mais elementos ou ainda retirando alguns de acordo com a maturidade na cultura DevOps.

DevOps

DevOps Representação

Agora chegou a hora de você parar e analisar se deve aderir à Cultura DevOps. Faça um exercício, simulando sua situação real atual, distribuindo o que você já possui de recursos dentro dos times de Desenvolvimento (Dev) e Operações (Ops). É bem comum perceber a existência da maioria dos elementos como Ferramentas, Processos, Automação (mesmo que em nível inicial) etc. Então o que é necessário para poder afirmar que é possível a adesão imediata? A resposta é simples mais uma vez: Falta apenas implantar e compartilhar a cultura, criando um ambiente onde pessoas dos times de Desenvolvimento e Operações colaboram na busca de resultados comuns para entregar um serviço, sistema, solução ou como queira descrever tal entrega (DevOps juntos do início ao fim do ciclo). E para completar não se esqueça de medir o desempenho do conjunto. E, “voilà”, sua prática de DevOps funciona!

Acredito que pelo menos 95% das pessoas que leem os conceitos básicos e que façam o teste concluem que falta muito pouco para iniciar esta nova jornada para um funcionamento muito mais eficiente e com menores custos operacionais através da Cultura DevOps.

Espera aí que tem bônus! A seguir deixo descrições um pouco mais detalhadas e técnicas sobre alguns pontos principais da Cultura DevOps e no final do texto tem uma lista com alguns livros para você utilizar como referência.

Bônus:

O Básico para quem precisa compreender o conceito:
DevOps é a prática onde times de desenvolvimentos de sistemas e times de suporte/operação de TI atuam em conjunto em todo ciclo de vida do serviço, desde o processo de design e desenvolvimento até o suporte de produção. O DevOps também é caracterizado pela maneira que a equipe de operações atua, utilizando muitas técnicas que os desenvolvedores de seus sistemas trabalham. Por outro lado o time de desenvolvimento passa a compreender um pouco mais do que acontece durante a operação de um serviço/sistema devido à proximidade com o time operacional.
Podemos simplificar o conceito, dizendo que DevOps é prática onde times de Desenvolvimento e Operações atuam de forma colaborativa durante o ciclo de vida de um serviço ou produto.

Existem alguns componentes centrais na prática de DevOps que devem ser compreendidos:
Cultura, Automação, Medição (ou Medir), Compartilhamento (CAMS em inglês)
O termo – em inglês – CAMS refere-se a “Culture, Automation, Measurement, Sharing”

Apesar dos termos serem autoexplicativos, a seguir, explico o CAMS um a um:

Cultura: Refere-se à maneira como as pessoas envolvidas na prática do DevOps atuam e pensam. DevOps é muito diferente dos modelos tradicionais de gestão de TI, onde as equipes de Desenvolvimento e Operações trabalham em ciclos completamente diferentes, utilizando processos isolados. E a Cultura é fundamental, pois, se você não investir nela, todas as tentativas de automação serão em vão. A Automação necessita de pessoas engajadas e ferramentas para funcionar.
Automação: Aqui é um dos lugares por onde você começa quando já entende sua cultura. Neste ponto, as ferramentas podem começar a unir uma malha de automação de tarefas para o DevOps. As ferramentas para gerenciamento de versões, provisionamento, gerenciamento de configuração, integração de sistemas, monitoramento e controle e também orquestração tornam-se peças importantes na construção de uma estrutura de DevOps.
Medição: Medir é uma prática fundamental no gerenciamento de qualquer atividade e, com DevOps não é diferente. Se você não conseguir medir, não poderá melhorar. Uma implementação bem sucedida de DevOps deverá medir tudo o que puder com a menor frequência possível. Métricas de desempenho, métricas dos processos e também métricas de pessoas.
Compartilhamento: Compartilhar ideias e problemas é a maneira de manter ativo o ciclo do CAMS. Criar esta cultura onde as pessoas possam compartilham ideias e problemas é primordial. Outra motivação interessante na cultura DevOps é a forma como as histórias de sucesso de DevOps ajudam os outros. Na prática do DevOps é sempre bem vindo o compartilhamento das ideias, e falar sobre problemas não deve ser encarado como uma situação de acusação pessoal ou menosprezo por causar alguma falha durante o ciclo. O que importa de verdade é entender o que acontece de errado e corrigir os problemas.
Agora que já passamos pelo básico, vamos conhecer as 5 metodologias utilizadas no DevOps:

  1. Pessoas sobre processos e processos sobre ferramentas (People over Process over Tools): Esta metodologia começa buscando as pessoas certas para cumprir um papel necessário. Em segundo lugar, assegure-se de que o processo esteja correto e ótimo. Por fim, melhore a eficiência do processo, reduzindo etapas, através de automação baseada em ferramentas.
    Para deixar claro, as ferramentas de automação são as últimas. Não faz sentido automatizar processos errados mesmo que você utilize as ferramentas certas. Automação serve para ajudar atingir excelência operacional e não para criar mais problemas!
  2. Entrega Contínua (Continuous Delivery): Entrega/Distribuição Contínua é a capacidade de fornecer mudanças de todos os tipos – incluindo novas funcionalidades, alterações de configuração, correções de bugs e produção de experiências – nas mãos dos usuários, de forma segura e rápida de forma sustentável. Muitos times já tem atuado com metodologias Ágeis e técnicas relacionadas a CI/CD, sendo assim, parte da metodologia utilizada na prática do DevOps já é conhecida. Como o tema aqui é DevOps, não vou me aprofundar em CI/CD. Você pode buscar no Google ou clicar aqui para saber mais.
  3. Gestão Enxuta (Lean Management): A Gestão Enxuta (Lean Management) é uma abordagem para administrar-se uma organização que tem base no conceito de melhoria contínua, uma abordagem de longo prazo para o trabalho que sistematicamente busca alcançar pequenas mudanças incrementais nos processos, a fim de melhorar a eficiência e a qualidade. É derivada da metodologia “Lean Manufacturing”, amplamente utilizada nas linhas de produção de automóveis.
  4. Controle de Mudança no estilo “Operações Visíveis” (Visible Ops style Change Control): O Visible Ops é uma metodologia que faz parte do ITIL desde o ano 2000 aproximadamente e basicamente reflete o que foi abordado no “item 1.Pessoas sobre processos e processos sobre ferramentas”, onde a excelência operacional não está apenas na utilização de ferramentas e sim na utilização do conjunto Pessoas/Processos/Automação criando um ciclo de entrega de serviço simples, eficiente e com custos que proporcionem que o negócio (ou produto final) seja competitivo.
  5. Infraestrutura como Código (Infrastructure as Code): A infraestrutura como Código (IaC) é um tipo de configuração de TI em que desenvolvedores ou equipes de operações gerenciam e provisionam automaticamente os recursos de TI utilizando ferramentas de automação, em vez de usar um processo manual para configurar dispositivos de hardware e sistemas operacionais. A infraestrutura como Código é também descrita como infraestrutura programável ou definida por software. É possível utilizar ferramentas dos próprios fornecedores dos equipamentos/serviços ou utilizar ferramentas de terceiros como as conhecidas Chef, Puppet, Terraform etc.

DevOps é um assunto bastante amplo e contempla todas as áreas da TI, portanto, se você tem interesse é sempre bom manter o conhecimento em dia, pois, como sabemos, estamos em constante mudança e, a cada ano, os ciclos de vida em TI estão sempre mais curtos. A parte boa é que a maioria dos conceitos e áreas de conhecimento utilizadas na prática de DevOps são conhecidos e facilitam a adoção de DevOps. Os desafios quando falamos deste assunto é mantermos uma cultura favorável a colaboração e como montar e desmontar os blocos de acordo com as necessidades do negócio, como um brinquedo de blocos Lego.

A seguir, a lista que mencionei:
Obs. Estou disponibilizando a lista com os Títulos todos em inglês, pois, estou fora do Brasil há algum tempo e não tenho certeza se existem traduções para todos.

  1. The Visible Ops Handbook: Implementing ITIL in 4 Practical and Auditable Steps, by Gene Kim, Kevin Behr, and George Spafford
    https://www.amazon.com/Visible-Ops-Handbook-Implementing-Practical/dp/0975568612 
  1. Continuous Delivery, by Jez Humble and David Farley
    https://www.amazon.com/Continuous-Delivery-Deployment-Automation-Addison-Wesley/dp/0321601912 
  1. Release It!, by Michael Nygard
    https://pragprog.com/book/mnee/release-it 
  1. Effective DevOps, by Jennifer Davis and Katherine Daniels
    http://shop.oreilly.com/product/0636920039846.do
  1. Lean Software Development: An Agile Toolkit, by Mary and Tom Poppendieck
    https://www.amazon.com/Lean-Software-Development-Agile-Toolkit/dp/0321150783
  1. Web Operations, by John Allspaw and Jesse Robbins
    https://www.amazon.com/Web-Operations-Keeping-Data-Time/dp/1449377440
  1. The Practice of Cloud System Administration, by Christine Hogan, Strata R. Chalup, and Thomas A. Limoncelli
    http://the-cloud-book.com/
  1. The DevOps Handbook, by Gene Kim, Jez Humble, Patrick Debois, and John Willis
    http://itrevolution.com/devops-handbook
  1. Leading the Transformation, by Gary Gruver and Tommy Mouser
    http://itrevolution.com/books/leading-the-transformation/
  1. The Phoenix Project, by Gene Kim, Kevin Behr, George Spafford
    https://en.wikipedia.org/wiki/The_Phoenix_Project_(novel)

 

Eu gostaria muito de saber a sua opinião sobre o assunto.
Opine e participe da discussão aqui no Blog ou no meu perfil do LinkedIn!
Um abraço!

Publicidade

Cloud Computing: Como funciona um Datacenter da Microsoft (Vídeo)

A maioria dos profissionais de tecnologia – e de outras áreas também – estão acostumados ao Termo Cloud Computing (Computação em Nuvem). Mas será que a maioria sabe o que é um datacenter preparado para este modelo?

Venho abordando o tema de vários pontos de vista, com conceitos técnicos – os modelos SaaS / PaaS / IaaS -, soluções de mercado e como Cloud Computing pode solucionar problemas relacionados ao negócio. No entanto, muitos não tem ideia do tamanho e da capacidade de um datacenter que atende a este modelo de Computação em Nuvem.

Pesquisando conteúdo, encontrei um vídeo publicado pela Microsoft no Youtube, onde é possível dar um passeio por dentro de um datacenter da Microsoft. Então decidi compartilhar, pois, nada melhor do que visualizar o que acontece por trás de todos estes conceitos, siglas, soluções que abordo neste blog.

Espero que gostem!
Caso haja alguma dúvida, por favor, escrevam. E se por algum motivo o vídeo apresentar algum problema, por favor, alguém informe.

Um abraço!
Antonio Ricardo

SharePoint 2010: BCS – Business Connectivity Services

Hoje decidi abordar algo bem específico no SharePoint 2010, que é o BCS – Business Connectivity Services, pois, tenho percebido que muita gente ainda acredita que o SharePoint é uma solução que tem pouca integração, ou ainda, muitos mantém a ideia que o SharePoint 2010 fica apenas no mundo da colaboração. Vamos lá…

Cada vez mais as empresas estão adotando modelos complexos de soluções tecnológicas (seja Tecnologia da Informação, Tecnologia Operacional entre outras), criando ambientes híbridos, ou seja, múltiplas soluções de diferentes fornecedores e em diferentes plataformas.

Considerando este cenário híbrido em relação aos seus ambientes, existe um ponto crítico a ser avaliado e muito bem desenvolvido, que é a INTEGRAÇÃO destes sistemas e de seus respectivos dados e/ou informações e é justamente neste ponto (a integração) que entra em ação o BCS – Business Connectivity Services no SharePoint 2010.

Mas o que é o BCS?(Até agora não falei… :-S)
BCS – Business Connectivity Services é (resumidamente) um conjunto de soluções, que fazem parte do SharePoint 2010, que facilitam a integração de dados entre o SharePoint e as demais soluções que você já possui. Com o BCS um desenvolvedor de sistemas – que tenha conhecimento em .NET e SharePoint, por exemplo – é capaz de fazer integrações (troca de dados bidirecional) com SAP, Soluções e Bancos de Dados Oracle e vários outros sistemas disponíveis no mercado. No meu ponto de vista, o BCS é uma forma de expandir suas soluções de forma infinita, integrando recursos de colaboração, computação social, business intelligence entre outros recursos em qualquer sistema que você já possua ou deseja utilizar.
(Lembrando que esta minha abordagem é do ponto de vista da arquitetura e não estou entrando em nenhum detalhe técnico, pois, meu foco aqui neste blog é sempre produzir textos que possam ser entendidos por todos os públicos.)

Caso você tenha interesse em conhecer detalhes técnicos do BCS, existem publicações específicas (livros técnicos) e também muitos recursos na Internet, como o MSDN, as Comunidades Técnicas Microsoft entre outras fontes de aprendizagem.

Baixe o Poster do BCS no site de Downloads da Microsoft em http://www.microsoft.com/en-us/download/details.aspx?id=2847

Abaixo, um exemplo da arquitetura do BCS. 

Consolidando e compartilhando informações: Tome melhores decisões

Uma das grandes vantagens de possuir um ambiente online de colaboração é a capacidade de tomar decisões baseadas em informações concretas e ter a chance de discutir, publicar – em suma, colaborar – decisões com equipes geograficamente distribuídas em tempo real – quando necessário – e também possuir histórico das análises feitas para a tomada de uma decisão, mantendo sua base de conhecimento.

Esta capacidade de colaborar já tem um certo tempo de vida, pois, com os sistemas de controle de chamados técnicos, por exemplo, as empresas já vem atuando desta forma faz um bom tempo, porém, o interessante é a evolução para a integração de sistemas de Tecnologia da Operação com a Tecnologia de informação, e isto significa diminuir a distância que existe entre as áreas mais direcionadas a operações de produção – chão de fábrica, operação de data centers, operação de indústrias com a cadeia de produção complexas, como a indústria de petróleo, deixando esta área operacional mais próxima a de negócios e a T.I., o que resulta em informações mais complexas, porém, mais ricas em conteúdo para tomada de decisões estratégicas de um determinado setor ou empresa.

Um exemplo que costumo citar é o da empresa OSI Soft , que possui uma excelente solução de Tecnologia Operacional que é capaz de efetuar desde uma coleta de dados de um equipamento de chão de fábrica – como uma bomba, por exemplo -, criar o histórico desta coleta, informar o estado deste equipamento e também gerar relatórios baseados nas informações deste dterminado equipamento. O interessante deste fluxo é que os resultados podem ser apresentados em uma plataforma de colaboração como o Microsoft Sharepoint, o que proporciona que estas informações possam ser disponibilizadas de acordo com qualquer necessidade do negócio. Podemos ter uma página que mostre um painel online do estado de um equipamento, também podemos publicar informações históricas para que engenheiros analisem e discutam resultados, além de podermos utilizar um Blog do SharePoint de uma determinada área – podemos pensar na área de Qualidade – para que esta avalie e discuta com áreas técnicas resultados insatisfatórios em relação a segurança dos trabalhadores baseados em um defeito em um equipamento que cause risco de vida.

Meu objetivo neste artigo é criar uma linha de pensamento e discussão, onde as empresas consigam enxergar a colaboração e a computação social como uma ferramenta que agrega muito valor na tomada de decisões, além de manter a base de conhecimento que muitas vezes é perdida e gera retrabalho. 

Lembre-se que o SharePoint é uma plataforma onde você pode desenvolver suas próprias aplicações, integrá-las com outras aplicações através de padrões do mercado – a OSI Soft tem interfaces para este fim – e que possui um recurso essencial que é a busca de informações históricas.

Quero ressaltar como em todos meus artigos, que minha opinião é realmente pessoal, e que não tenho nenhum tipo de patrocínio ou interesse de vender algum produto aqui. Neste caso estou citando a OSI Soft porque é uma empresa que tem uma solução que conheço e que realmente acredito ser interessante. (No final do artigo, publiquei um exemplo de arquitetura publicado no site da OSI Soft)

Um grande abraço,
Antonio Ricardo Gonçalves

Colaboração + Grupos de Trabalho + Projetos = Resultados

     Alguns dos maiores beneficiados com as Redes Sociais Corporativas são os responsáveis por projetos, sejam eles coordenadores, gerentes ou patrocinadores.

     A partir de sistemas web desenvolvidos para tal finalidade, tornou-se possível gerenciar projetos de maneira mais eficiente e eficaz, através de soluções que disponibilizam controle de tarefas, custos, prazos, recursos humanos entre outras dezenas de possibilidades. É possível acompanhar qualquer um dos envolvidos em projetos, independentemente de localização geográfica, função (seja o envolvido, um gestor de departamento ou um técnico de um prestador de serviços).

     Utilizando como exemplo prático o Project Server / EPM 2007 da Microsoft, a partir do momento que um colaborador passa a ser um membro de um projeto, ele irá obter acesso a uma área (grupo de trabalho) onde ele poderá compartilhar (fornecendo e recebendo) informações, controlar as suas atividades, participar de conferências / reuniões on-line entre outros recursos. Algo bem interessante é a possibilidade deste colaborador ter acesso a um conjunto de informações de outros projetos que estão ocorrendo e aqueles que já foram finalizados, pois, desta forma ele poderá reutilizar processos, documentos e também conhecimentos previamente utilizados.

Área de Trabalho do EPM 2007

A seguir segue o link para quem deseja conhecer um pouco mais a respeito do EMP 2007. Trata-se de uma demonstração da solução:
http://www.microsoft.com/project/en/us/demo-enterprise-project-management.aspx

Um Abraço,
Antonio Ricardo Gonçalves