modernisation des processus de livraison t.i. red hat day · 2017-11-29 · java ee (jboss eap)...

RED HAT DAYModernisation des processus de livraison T.I.

Martin SauvéArchitecte de solutionsmsauve@redhat.com

Adrian Cockroft - ancien architecte en chef chez Netflix

Les T.I. ont évoluées

Serveur d’applications 2000-2014

Framework / APIs

App

Services Intergiciels

Plateforme - opérations

App App App App App

Persistance | Sécurité| Transaction| Messagerie| HTTP

Déploiements| Gestion| Monitoring | HA | Logging

Machine virtuelle | Système exploitation

4

Le développement se transforme

ArchitectureInfrastructure

Monolithe

N-Tier

Microservices

Centre de données

Services gérés

Hybride

Processus

Waterfall

Agile

DevOps

WATERFALL DEVOPS

Passage à DEVOPS pour une livraison plus rapide en petites étapes

Architecture en petites composantes applicatives

MONOLITH

SVC

SVC

SVC

SVC

µSVC

µSVC

µSVC

µSVC

µSVC

µSVC

µSVC

µSVC

µSVC

µSVC

µSVC

µSVC

µSVC

µSVC

µSVC

µSVC

PRE-SOA SOA MICROSERVICES

Avancement technologique favorisant les µSVC: logiciels à moindre coût, conteneurs, latence et efficacité des réseaux.

Utilisation des conteneurs pour gérer les composantes

ConteneurVM

SVC

µSVC

VIRTUALISATIONTRADITIONNELLE

MICROSERVICES EN CONTENEURS: LÉGERS, FLEXIBLES, PRÊTS POUR LE CLOUD

VM

SVC

Plateforme de Conteneurs

Conteneur

µSVC

Conteneur

µSVC

Développer des applications modernes ‘Cloud-Native’

CONTENEUR

App Server

SVC

CONTENEUR

SVC

Un conteneurDans un conteneur

Traditionnelle Moderne

Utilisation du conteneur pour:- Résilience- Montée en charge- Portabilité- Configuration- Anti-fragilité

10

Qu’est-ce qu’un conteneur ?

11

Les développeurs ont plus de choix que jamais!

Funktion

50% du marché entreprise

Serveur d’applications 2015-...

Runtime

App

Cloud Platform

Data

Build| Deploy| Scheduling | Scaling | Elasticity | Metrics | Logging

Security IMDG Messaging

Runtime

Svc

Runtime

Svc

Infonuagique/Data Center

12

Pas une cible

OPTIONS POUR MODERNISER LES APPLICATIONS

ApplicationsExistantes

Rehost (lift/shift)

Replatform (lift/reshape)

Repurchase

Refactor (rewrite, decouple apps)

Analyse et priorisation Retire

Retain as is (for now)

ComplexitéDe

Réécriture ?

Applications à haut degré de changement ou d’utilisation

Petites applications ou applications statiques

RUNTIMES(Container images and Maven Artifacts)

JAVA EE(JBoss EAP)

MICROPROFILE

(WildFly Swarm)

OPENSHIFT SERVICES

REACTIVE(vert.x) NODE.JS APACHE

TOMCAT

CERTIFIED FRAMEWORKS(Maven Artifacts)

SPRING BOOT / CLOUD

NETFLIX OSS Ribbon

OpenShift.io

(DeveloperSaaS)

Generators

IDE

etc.

Management

APM

Metrics

ServiceDiscovery Config.

Logging

Health Check

Load Balancing

CI/CDSSOMessaging IMDG API Mgmt

NETFLIX OSSHysterix ...

OPENSHIFT APPLICATION RUNTIMES(RHOAR)

Pourquoi RHOAR ?Polyglotte

• Plateforme non-liée à un langage de programmation• Focus initial sur Java et JavaScriptMeilleures solutions OSS

• Conteneur, Kubernetes, MicroProfile, Java, JavaScript, SpringArchitectures multiples

• Monolithes agiles (Java EE existant, Spring MVC)• Mini et micro-services• Serverless [plan futur] Sécurité• Chaîne de développement sécurisée et validée

15

DEMO #1

OpenShift Application Runtimes

Plateforme Micro Services

16

Comment démarrer ?

T.I. BI-MODAL

MODE 1• 1 app = 1 VM

• Cycle de vie = Année

• Haute disponibilité

pour les VM

• Résilience =

Matériel/Serveur

• “Scale Up” (serveur ou

vm plus puissant)

MODE 1

MODE 2

MODE 2• 1 app = plusieurs VMs

• Cycle de vie = Jours / Heures

• Haute disponibilité non

nécessaire

• Résilience = Par l’application

• “Scale Out” (ajout de serveurs

ou vms)

Une approche gagnante

DÉVELOPPERApplication Microservices

MODERNISER Applications Traditionnelles

ÉTAPE

1

Nouvelles apps natives en nuage

Héritage informatique

Agile, Rapide, DevOps et exposer les APIsRénover et exposer les APIs

API

API

Moderniser l’intergiciele et l’infrastructure

Conteneurs et cloud hybride

ÉTAPE

2

BÂTIR DES PONTSIntégration/Caching/Frontière

ÉTAPE

3Microservices

1 – ÉTRANGLER LE MONOLITH

20

2 – AJOUT D’UN MICROSERVICE

Inventaire

X

21

3 – PUIS UN AUTRE

Catalogue

Inventaire

XX

22

4 – ÉCRASER LE MONOLITHE

23

5 – ENLEVER LES COMPOSANTES MORTES

24

Outils et écosystème

Kubernetes

● Configuration distribuée● Découverte de services● Catalogue de service● Balanceur de charge● Gestion des versions● Déploiements automatisés● Montée en charge à la demande ou

automatique● Bilan de santé et monitoring● Auto-guérison (self-healing)

OpenShift est Kubernetes

• Libre-service pour les équipes

• Flux de travail pour les développeurs

• Focus sur l’entreprise (RBAC, OAuth, LDAP…)

• Registre de conteneurs intégré

• Jenkins (CI/CD) intégré

• Déclencheurs et automatisation des builds et déploiements

• Réseautique Logicielle (SDN)

• Outil ligne de commande, API et console web

Kubernetes est une infrastructure déclarative pour les microservices

Red Hat – Travail dans les communautéshttps://github.com/kubernetes/community/blob/master/sig-list.md

45% des SIGS Kube sont co-gérés by Red Hat● API Machinery● AUTH● Autoscaling● Big Data● CLI● Network● Node● OpenStack● Scheduling● Service Catalog● Storage● Container Identity● Resource Management

Runtime Conteneurshttps://github.com/opencontainers/runchttps://github.com/containerd/containerdhttps://github.com/moby/mobyFocus sur les composantes suivantes:

● version/master● area/networking● area/storage● area/runtime● kind/performance● area/runtime● area/security● area/plugins● area/daemon

Kubernetes pour l’entreprise

https://devstats.k8s.io

DEMO #2

Pipeline Micro Services sur

Kubernetes/Openshift

31

Surveillance, surveillance, surveillance!

33

Envoy proxy

34

DEMO #3

Surveillance et Sécurité

35

Stratégie Multi-CloudsOpenShift ne dépend que de RHEL

Physique, Virtualisation, cloud public (AWS, Azure, GCE, SoftLayer, etc)

Applications facilement portables entre les différents environnements

OpenShift permet:

• Opérations uniformisées

• Expérience développeur uniformisée

• Expérience support uniformiséé

37

En résumé, réduction de la complexité … donc:

● Réduction des risques

● Réduction des coûts

● Augmentation de l’agilité

Stratégie Multi-Clouds

Réduction des risques

● *Vous* êtes responsable du cycle de vie et non le fournisseur de service

● Facilité de migration cloud à cloud. Risque de dépendance réduit

● Support complet de l’image du conteneur à l’hôte.● Sécurité Red Hat: SELinux, OpenSCAP, Isolation réseau,

Security Response Team, etc.

Réduction des coûts

● Uniformité de l’automatisation et des outils● Moins de formation requise pour les développeurs,

opérateurs, supports● Effectuer et gérer l’intégration d’entreprise UNE FOIS

○ Contrôle des changements, authentication, authorization, secrets, logging….

● Moins de ressources humaines pour opérer des environnements disparates

● Compétition entre les fournisseurs infonuagiques

Augmentation de l’agilité

● Re-assignation des ressource dev/eng/ops vers les différents cloud au besoin

● Re-déploiement des applications sur différents clouds ou dans votre centre de données au besoin

OpenShift est complémentaire au clouds publics

- OpenShift Dedicated est un service géré d’OpenShift par Red Hat

- OpenShift Service Broker permet l’accès aux services des clouds publics

OPENSHIFT SERVICE CATALOG

AnsibleServiceBroker

OpenShiftTemplateBroker

CloudServiceBroker

OtherServiceBrokers

ANSIBLE

OPENSHIFT

PUBLIC CLOUD

OTHER COMPATIBLE SERVICES

Ansible Playbook Bundles

OpenShiftTemplates

PublicCloudServices

OtherServices

DEMO #4

Multi-clouds et broker de services

40