O novo suporte para mainframes do ElectricFlow DevOps Automation inclui a possibilidade de automação nativa pré e/ou pós deployment. Também inclui governança e segurança de pipelines. Um novo modelo de microservices nativo permite que sejam tratados como objetos de primeiro nível e sejam modelados independentemente de aplicações e ambientes, controle de deployment de containers dentro de aplicações ou stand-alone, compartilhamento de componentes funcionais para ambientes de runtime de containers.
As novidades para mainframes incluem:
- Automação a nível de sistema no z/OS, incluíndo código JCL e REXX;
- Implantação nativa para WebSphere e DB2 em mainframes;
- Integração com o Compuware ISPW permitindo estender as práticas DevOps para os ciclo devidas dos mainframes;
- Integração com o Compuware Topaz para incorporar análise estática de código, teste unitários e testes funcionais no pipeline de mainframes.
- A possibilidade de estender os itens anteriores para outras ferramentas de SCCM do mainframe através de APIs e DSLs.
- O catálogo de plugins de mainframe para o ElectricFlow atualmente inclui: Compuware ISPW e Topaz, IBM WebSphere e B2, z/OS para gerenciamento de sistemas e o gerenciador de configuração do CICS
InfoQ.com perguntou ao CTO da Electric Cloud, Anders Wallgren para descrever as funcionalidades de governança de pipeline e segurança disponíveis agora em implantações para mainframes:
O ElectricFlow suporta autenticação usando diretórios corporativos (LDAP/AD) através de uma arquitetura ACL (Access Control List). A arquitetura ACL suporta herança e negação de acesso, que são um superset do RBAC, fazendo com que a implementação do RBAC seja simples. Todos os objetos na plataforma (aplicações, releases, ambientes, usuários, grupos, etc) são governados por essas ACLs. O mecanismo de herança torna possível delegar acesso à certos objetos sem ter que delegar um usuário administrador do sistema. Extender essas funcionalidades ao mainframe significa que o mainframe deixa de ser uma cidadela da automação separada e se torna um componente completo e integrado. O ElectricFlow pode ser usado como um motor para reforçar políticas, garantindo que apenas atividades/ações/implantações aprovados passem pelo mainframe. Se alguém tentar se conectar via Telnet diretamente no mainframe e faz uma alteração em um processo ou componente do pipeline, o ElectricFlow detecta essas mudanças (e as rejeita ou reinicia o processo) através da comparação entre o que está sendo apresentado para a próxima etapa e o que deveria estar sendo apresentado. Se houver diferença, o ElectricFlow viabiliza a visibilidade e registra o que mudou em que estágio do pipeline, garantindo as primeiras migalhas de pão no caso de uma análise de incidente.
Wallgreen foi além e explicou que, por todo pipeline, critérios de entrada e saída (os chamados "gates") governam o processo do software através dos estágios do pipeline. Esses gates podem ser manuais ou automáticos. Gates manuais precisam de uma intervenção humana para aprovar ou rejeitar o processo que está de passagem para o próximo estágio e notificações são enviadas para os grupos de usuários ou indivíduos responsáveis pela tomada de decisão. A interface do usuário reflete que o pipeline está parado aguardando por uma aprovação humana. No entanto, gates automáticos pode ser usados para acelerar esse processo aonde for possível. Por exemplo, um gate pode instantaneamente permitir a evolução de deployment pelo pipeline baseado nos resultados de cobertura após a execução do estágio de testes unitários ou bloquear caso as taxas de sucessos dos testes não atinjam os gatilhos necessário.
Ferramentas para teste de segurança (estáticas ou dinâmica) podem ser incorporadas no pipeline para, por exemplo, garantir que bibliotecas de terceiros estejam aprovadas e dentro da validade no que diz respeito a informes de segurança. Os ambientes estão sujeitos a blackouts e paradas programadas através do sistema de calendário. Requisitos de dependências dos releases devem ser respeitados - se a aplicação A depende de uma nova versão do serviço B, a implantação da aplicação A deve ser bloqueado até que a versão necessária do serviço B esteja disponível.
O InfoQ pediu a Wallgren para explicar por que os anúncios a respeito de mainframes e microservices foram feitos simultaneamente:
Os microservices introduzem complexidades e desafios. Por isso o dashboard e as funcionalidades de gerenciamento são projetados para garantir visibilidade e o controle dos microservices. A transformação digital tem provocado mudanças em organizações de todos os tamanhos, especialmente as grande com sistemas de gravação vitais armazenados nos mainframes. Frequentemente, é difícil mover esses Sistemas de Gravação para sistemas distribuídos ou para nuvem. As organizações não podem simplesmente abandonar esses Sistemas de Gravação. É necessário encontrar um caminho para que estes sistemas se tornem uma parte integral de estratégia ou encontrar um caminho para uma transição segura na direção de eliminar esses sistemas. O ElectricCloud enxerga o mainframe e a transformação digital como um ecossistema. A combinação da integração do mainframe com funcionalidades de microservices torna a organização capaz de tornar o mainframe um componente integral da estratégia digital e cria um caminho, através dos microservices, de transição para uma realidade sem mainframes seguro e na velocidade do negócio. Um pacote para deploy (de microservices) pode ser composto por um número de itens um/alguns que podem estar relacionados ao z/OS.
O ElectricFlow já havia tratado desafios de gerenciamento de containers como scripts específicos bem como automação e dependência de versões em tempo de execução, particularmente para inventários de containers muito grandes. A nova versão do ElectricFlow disponibiliza o suporte nativo a microservices e uma série de novos plugins para realização de deploys em ambientes Docker nativos, Docker Swarm e Docker. O ElectricFlow Insights agora inclui novos dashboards que disponibilizam informações sobre os microservices implantados em um dado período de tempo, por ambiente e por cluster. O dashboard de microservices pode ser ordenado por sucessos, falhas, freqüência de implantação ou quais clusters estão sendo mais utilizados. O DevOps Insights disponibiliza detalhes de quantos microservices foram implantados pelo ElectricFlow versus quantos foram implantados diretamente.
O cliente da ElectricCloud SOMOS usou um mainframe para administrar e gerenciar mais de 41 milhões de números de telefones sem custo de ligação nos EUA e Canadá por 30 anos. Recentemente decidiram migrar a aplicação mainframe de 30 anos. Gary MacKay, ScrumMaster da SOMOS disse:
Um do muitos desafios que encontramos foi como modernizar e criar uma cultura e ambiente DevOps na SOMOS ao mesmo tempo em que migrávamos para uma arquitetura baseada em microservices. Escolhemos o ElectricFlow devido ao seu suporte a workloads em ambos containers e mainframes e por que é possível coordenar entregas destes workloads em todos os ambientes de desenvolvimento e produção.