Archives de
Étiquette : AWS

Le Service Level Agreement chez AWS

Le Service Level Agreement chez AWS

Article mis à jour le 16 janvier 2019 avec l’ajout du SLA pour 3 composants du service Kinesis (Data Firehouse / Video Streams / Data Streams)

Chez Corexpert, nos clients nous posent souvent cette question :

« On nous parle toujours de Haute Disponibilité et Très Haute Disponibilité chez AWS, mais s’engagent-ils vraiment ? Existe-t-il un SLA ? »

Qu’est ce que le SLA ?

Le SLA, ou Service Level Agreement, est le niveau de qualité et de performance contractuel d’un service ou d’une infrastructure technique. Dans le cas de AWS, fournisseur Cloud, on parlera donc bien d’un service, vu qu’on évolue dans le monde IaaS – Infrastructure as a Service !

Le SLA doit cadrer en premier lieu de quelle fourniture nous parlons, et les critères de performances sur lesquels le fournisseur va s’engager. On pourra donc parler de temps de réponse, de fonctionnalité assurée, de disponibilité complète du service etc.

SLA chez AWS

Nous allons parcourir ci-dessous les principaux services ou services majeurs de l’offre AWS, qui possèdent un SLA à la date de rédaction de cet article. Bien évidemment la liste est non exhaustive.

Amazon Route 53 : SLA du DNS AWS

Le service DNS de AWS, Amazon Route 53, possède un SLA de disponibilité du service du niveau le plus haut possible. En effet, on a ici un engagement de disponibilité de 100% sur le service, ce qui est explicité par « Amazon Route 53 n’échouera pas pour répondre à vos requêtes DNS dans le cycle de facturation d’un mois ». Pourquoi parler d’un mois ? Car AWS, s’engage, en cas d’éventuelle défaillance avérée, de vous rembourser sous forme de crédits sur ce cycle de facturation.

sla-amazon-route-53

Extrait de la page SLA – Amazon Route 53 au 10 janvier 2019

Amazon EC2 ou Elastic Cloud Compute : SLA des VM AWS

Service principal de AWS, Amazon EC2 et Amazon EBS fournissent respectivement l’hyperviseur managé pour exécuter vos Machines Virtuelles, aka instances EC2 et le stockage virtualisé Amazon Elastic Block Store (EBS). Le SLA a été étendu à Amazon Elastic Container Service (ECS) et AWS Fargate (deux services ayant traits aux conteneurs Docker) depuis 2018.

Le SLA des services, avec l’engagement de Amazon Web Services, est d’au moins 99.95% mensuel. Soient moins de 22 minutes.

Si une indisponibilité est avérée entre 99.90 et 99.99%, AWS s’engage à effectuer une remise de 10% en crédits AWS sur le service EC2 et en deçà de 99.0% de disponibilité AWS propose une remise de 30% en crédits.

Il est important de noter que le SLA est lié à l’état « Region Unavailable« . Si vous ne le savez pas déjà, une région est l’ensemble de plusieurs zones (2+) de disponibilités mais dans le cadre du SLA, AWS précise que l’état « Région indisponible » vous concerne si plus d’une zone de disponibilité où vous exécutez des instances EC2 est indisponible, c’est-à-dire que les instances n’ont plus accès à Internet.

L’indisponibilité de EBS est avérée lorsque les volumes de stockage ne génèrent plus d’I/O avec une file d’attente non vide.

Amazon RDS, SLA des bases de données managées AWS

Amazon RDS est le service de Base de données managée par AWS, il supporte à ce jour MySQL, Oracle, PostgreSQL, MariaDB, Microsoft SQL Server, AuroraDB. Mais le SLA proposé par AWS, concerne uniquement les instances Multi-AZ (c’est à dire avec un serveur en Stand-By mode dans une autre zone de disponibilité) des moteurs SQL : Oracle, MariaDB, MySQL & PostgreSQL. Ce SLA est de 99.95% de disponibilité du service. L’indisponibilité est avérée quand toutes les requêtes de connexion échouent pendant une minute sur l’instance RDS multi-AZ.

sla-amazon-rds

Engagement de AWS pour RDS et remboursement en crédits au 10 janvier 2019

Amazon S3, SLA du stockage AWS

Amazon S3 est le service de stockage d’objets, il est l’un des plus anciens services de AWS et possède une durabilité des données de 99.999999999% en mode de stockage standard. Toutefois le SLA concerne la disponibilité d’accès à la données stockée via l’API AWS. Le SLA de Amazon S3 est donc calculé sur le comptage d’erreurs ou d’indisponibilité de l’API sur 5 minutes.

L’engagement de AWS est de conserver une disponibilité au-delà de 99.9% mensuel, ce qui représente moins de 43 minutes 12 secondes.

Si AWS ne peut assurer cette disponibilité sur la région où est stocké votre bucket S3, alors 10% de remise sur le coût de stockage S3 seront reversés en crédits, et en deçà de 99.0%, alors la remise en crédit s’élèvera à 25% du coût du service Amazon S3.

Depuis janvier 2019, ces règles ont été étendues à Amazon Elastic File System (EFS) avec les mêmes engagements que pour S3. Amazon EFS est un système de stockage de fichiers simples managé (AWS gère l’infrastructure pour vous).

Amazon CloudFront, SLA du CDN AWS

Amazon Cloudfront est le service CDN de AWS, avec plusieurs dizaines de « Edge Locations », ce service met en cache les requêtes web selon vos comportements et pattern d’URLs choisis. Il permet des diffusions et donc des chargements de données accélérés sur les sites web et applications mobile, notamment lorsque du contenu media transite.

AWS s’engage à maintenir une disponibilité globale du service au-dessus de 99.9% mensuel (identique à Amazon S3). Les remises effectuées sur le service, en cas de défaillance avérée, également basé sur la fréquence des erreurs d’accès aux données sont identiques à celles de Amazon S3.

AWS Shield, SLA du service de protection anti-DDoS

Lancé lors du re:Invent 2016, AWS Shield est l’officialisation de la protection anti DDoS de AWS. Le service utilise et protège les autres services Amazon CloudFront et Amazon Route 53, et son SLA, ramené sur des périodes de 24 heures, est lié directement aux SLA des produits cités précédemment. On pourra donc traduire ce SLA, par un simple rappel que l’utilisation du service AWS Shield devant Amazon CloudFront ou Amazon Route 53 ne modifie pas leur SLA.

Amazon API Gateway, SLA sur la gestion des API

Depuis janvier 2019, AWS s’engage à assurer une disponibilité de 99.95% mensuel du service Amazon API Gateway. Ce service entièrement managé facilite la gestion, la surveillance et la sécurité des API de n’importe quelle taille. En cas de rupture du service, le crédit alloué est identique à ceux de RDS : 10% de remise entre 99.0% et 99.95% et 25% de remise pour une disponibilité mensuelle moindre à 99.0%.

Amazon EMR, SLA sur les frameworks Big Data

En janvier 2019, Amazon EMR bénéfice d’un engagement en terme de disponibilité de la part d’AWS. Les frameworks Big Data gérés par le service possède un SLA de 99.9% mensuel.

emr_sla.Engagement de AWS pour EMR et remboursement en crédits au 10 janvier 2019

Amazon Kinesis, SLA sur la gestion des données en streaming

Amazon Kinesis traite de la collecte, du traitement et de l’analse de données en streaming en temps réel. Le SLA sur lequel s’engage AWS touche trois composants principaux de Kinesis : Videos Streams, Data Streams et Data Firehose. L’engagement de disponibilité des services est de 99.9% mensuel avec une remise de 10% à 25% en cas d’indisponibilité.

Synthèse des SLA chez AWS

Service AWS SLA mensuel SLA minutes/mois
Amazon Route 53 100.00 % 0 seconde
Amazon EC2 99.99 % 4 minutes 30 secondes
Amazon RDS 99.95 % 21 minutes et 36 secondes
Amazon S3 99.90 % 43 minutes et 12 secondes
Amazon CloudFront 99.90 % 43 minutes et 12 secondes
AWS Shield Cf. CloudFront ou Route 53 Cf. CloudFront ou Route 53
AWS API Gateway
99.95 % 21 minutes et 36 secondes
Amazon EMR
99.90 % 43 minutes et 12 secondes
Amazon Kinesis
(Data / Videos Stream /
Data Firehose
99.90 % 43 minutes et 12 secondes

 

Calcul du SLA d’une infrastructure AWS

Partons d’une infrastructure Web App, relativement classique. Elle est composée de plusieurs serveurs applicatifs frontaux, ici EC2 C4.Large, le code exécuté est le même sur chaque instance, et nous avons une redondance multi-zone de disponibilités. La base de données est un MySQL sur RDS en Multi-AZ (Stand-By Instance). Les éléments statiques du sites sont stockés sur S3. CloudFront, est placé devant le Load Balancer, il met en cache les éléments statiques de S3 et reroute les autres requêtes sur le LoadBalancer. Route53 gère le nom de domaine du site.

cloudcraft-web-app

Infrastructure Web : Amazon Route 53, CloudFront, S3, EC2 et RDS

Voici comment nous pouvons calculer le SLA de cette infrastructure, bien entendu celui-ci est dans le cas d’une défaillance de tous les services AWS utilisés sur une région, et dans le cadre du SLA de chacun de ses services. Dans ce cas l’infrastructure ne peut prétendre à un SLA supérieur sans redondance supplémentaire.

  • RDS Multi-AZ MySQL : SLA de 99,95 %
  • EC2 : SLA de 99.95 %
  • CloudFront : SLA de 99.9 %
  • S3 : SLA de 99.9%
  • Route 53 : 100.0 %

Le SLA de l’infrastructure brute sera de :

99.95% x 99.95% x 99.9% x 99.9% x 100% = 99,70 %

Si l’on considère que l’indisponibilité S3 n’est pas critique pour la conservation de la disponibilité de l’infrastructure web (par exemple une API) et qu’on gère via Route 53 l’éventuel downtime de CloudFront en pointant vers le Load Balancer en secours, nous gagnerons 0,2% de SLA juste par modification et optimisation du Design de l’infrastructure :

99.95% x 99.95% x 100% = 99,90 %

N’hésitez pas à poser vos questions ou nous contacter pour plus d’informations.

Retour sur la Re:Invent 2018

Retour sur la Re:Invent 2018

Bien des nouveautés AWS ont été présentées à la Re:Invent de 2018 ! IoT, serverless, database, supervisions des services, analyse des données, blockchain, machine learning, stockage… il y en a eu pour tous les goûts ! Le machine learning a été particulièrement mis en avant cette année, vous pouvez retrouver ici un recap par Julien Simon (AI et Machine learning Evangeliste AWS).

Au lieu d’effectuer un inventaire des nouveaux services (qu’AWS a très bien fait de son côté), nous avons interrogé les membres de l’équipe ayant décollés pour Las Vegas. Quels sont les services et fonctionnalités les plus intéressantes annoncées ? En tant que participant, quels sont les points forts de cette Re:Invent ? Des points négatifs ?

Sylvain (Professional Solutions Architect AWS)

Pour sa deuxième année consécutive de participation au Re:Invent, Sylvain est très intéressé par les mises à jour concernant serverless.

StepFunction – l’orchestration des services est facilitée avec l’intégration de nombreux services (ECS, Fargate, DynamoDB, SNS, SQS, Batch, Glue et SageMageker) facilitant l’automatisation, la sécurité et la supervision des workflows. Pour en savoir plus…

Lambda avec ALB – Application Load Balancers (ALB) peut maintenant être lié avec des Lambdas pour les requetes HTTPS. Un schéma pour mieux comprendre

Lambda with ALB

♥ Keynote d’Andy Jassy
♥ Rencontres avec la communauté
♥ Goodies ou Swag
♥ Certifications accessibles

⊗ Beaucoup d’informations à absorber
⊗ Versatilité du niveau des sessions / workshops : il est difficile de cerner le niveau / qualité des ateliers et des intervenants.
⊗ Canadiens ont eu un swag spécial indisponible aux Français !

Mohamed (Professional Solutions Architect AWS)

Première expérience de la Re:Invent pour Mohamed qui a particulièrement apprécié les alternatives proposés par AWS pour le réseaux et une nouvelle base de données time series.

Transit Gateway – un hub central de connexion entre les VPC d’AWS et une infrastructure on-premise. Simple et facile, fini les bricolages à base de rebond SSH ou de redirection de port avec NGINX. En savoir plus…

Timestream – une base de données managée time series, alternative à DynamoDB (avec un pattern spécifique) et à d’autres solutions Opensource tel qu’InfluxDB.
Amazon Timestream

♥ Ambiance (course de DeepRacer, nombreuses animations & jeux)
♥ Re:Play (Skrillex)
♥ Logistique impressionnante

⊗ Énormément d’informations à digérer
⊗ Pas assez de sessions niveau 400
⊗ Le jet-lag

Marouen (Professional Solutions Architect AWS)

Les mises à jour apportant de la flexibilité à l’usage des services AWS ont été retenu par Marouen.

DynamoDB On demand – la base de données NoSQL de AWS est maintenant bien plus flexible : il n’est plus nécessaire de surdimensionner les tables afin de pouvoir absorber les pics d’activités. En savoir plus…

Amazon FSx – plus besoin de devoir monter un EFS sur Linux et de le partager en SMB afin de pouvoir exploiter un file system managé et distribué sous Windows

♥ Les chat talk permettant de poser des questions aux Product Owners des services AWS
♥ Les jokes sur Oracle lors des Keynotes
♥ La nourriture à profusion

⊗ Las Vegas (le bruit, les casinos…)

Germain (Sales Executive)

Germain a apprécié la volonté d’AWS d’améliorer les solutions cloud hybrides.

Amazon Outpost – ce service permet d’harmoniser les services et fonctionnalités d’AWS avec ceux présents on-premise et vice-versa !
Actuellement en preview, pour en savoir plus et s’inscrire…

VMware on AWS – l’intégration de VMware Cloud sur AWS est renforcé avec Outpost mais aussi avec l’intégration du service de base de données managées Amazon RDS dans l’environnement VMware.

♥ Keynotes : immanquable mais dense techniquement
♥ De plus en plus de place aux profils non techniques
♥ Vu 360° des offres AWS et périphériques, particulièrement crucial pour se projeter à moyen-terme sur le marché

⊗ Nécessite plus de préparation : un ciblage plus en amont des sessions, une arrivée à l’event plus tôt, etc.

Encore à l’affût d’informations ? Vous pouvez retrouver les sessions enregistrées et toutes les vidéos tournées durant le Re:Invent 2018. Les slides sont disponibles également.

D’autres interrogations ? Vous souhaitez profiter des avantages du cloud ? Un projet de migration ? Contactez-nous !

L’automne, c’est la saison de l’IA !

L’automne, c’est la saison de l’IA !

« Nos collègues à InTW’IT sont aussi des innovateurs, découvrez leur savoir-faire ! »

L’automne a été chargé en événements autour de l’IA pour TeamWork !

Tout d’abord, le 27 septembre, Arnaud JEAN, Data Architect, a présenté une application de Edge Computing lors du Meetup AWS. En effet, grâce à un modèle de Deep Learning créé spécialement, nous avons développé un jeu sur DeepLens (d’AWS) pour apprendre l’alphabet en ASL (langue des signes américaine).
Cette présentation a mis en avant les différentes compétences des équipes sur AWS, l’IoT, le edge computing, et le deep learning.
Le jeu est depuis visible dans l’Innovation Corner d’AWS à La Défense ! 😊

Le Github du projet est disponible ici ! Et une vidéo explicative du projet ci-dessous.


Le lendemain, le 28 septembre, deux ateliers ont été tenus par TW dans le cadre du forum PMI de Lyon. Cette conférence, organisée par le PMI (Project Management Institute), est destinée aux chefs de projets. Et cette année, le thème était l’intelligence artificielle !

Dans le premier atelier, Nicolas BOULITEAU, chef de projet DPP et Virginie MATHIVET, directrice de la R&D, ont présenté ce qu’était (ou non) l’IA et en quoi cela pouvait être utile à des managers et chefs de projets.
Dans le deuxième atelier, Solen SANSCHAGRIN, Data Scientist et Adrien RUEL, Data Scientist Junior, ont présenté une application de NLP (Natural Language Processing) et Sentiment Analysis créée au sein de TeamWork. Celle-ci permet de détecter l’agressivité de communication, pour prévenir la personne qui l’a écrit, avant qu’elle n’envoie son message par mail ou qu’elle ne le publie. De cette façon, la communication s’en trouve facilitée.
Une vidéo sera disponible prochainement sur ce dernier atelier.

Solen et Nicolas ont ensuite donné une nouvelle conférence pour le forum PMI de Toulouse cette fois-ci, et pas n’importe laquelle : la conférence d’ouverture !
Dans celle-ci, Solen et Nicolas ont indiqué ce qu’était l’IA, à quoi cela pouvait servir et ont même présenté plusieurs programmes utilisant l’IA à destination des managers et chefs de projets.

Pendant ce temps, les 10 et 11 octobre, Virginie était à Amsterdam pour le World AI Summit, une conférence internationale autour de l’IA. Pendant deux jours, elle a présenté les dernières avancées, les applications actuelles, et a permis de rester à jour sur l’état de l’art. De plus certaines conférences ont été très inspirantes !
World-AI-Summit
Enfin, les 24 et 25 octobre, c’était le BlendWebMix 18 à la cité internationale de Lyon ! Virginie y était en tant que speaker avec une conférence « Hoaxbuster – version IA ». Le but ? Démystifier l’IA en insistant sur ce que ce n’est pas, et en prenant comme sources des articles de blogs, de journaux, des documentations… Bref, une remise au point nécessaire dans un environnement où l’IA est le mot-clé à la mode, malheureusement parfois sans réelle fondation…

Des projets dans l’IA ? Une volonté d’utiliser le Deep learning et l’IoT (Internet des Objets) pour améliorer votre productivité ? Contactez nous !

L’audit, cas pratique

L’audit, cas pratique

Une entreprise est souvent amenée à réaliser un audit de maturité sur le cloud d’AWS en amont d’un chantier d’améliorations.

Faire appel à un consultant, expert dans le domaine, apporte un regard extérieur objectif sur les points forts et les points faibles de l’existant. L’audit est un outil important pour analyser si la structure en place respecte au minimum les bonnes pratiques.
L’objectif est de donner une vision globale et d’établir les premières ébauches d’un plan d’actions.

Il existe de nombreuses thématiques à auditer concernant la maturité sur le Cloud. Nous vous partageons ci-dessous les principales.

Sécurité & Gouvernance
L’audit portera sur la segmentation des environnements de travail (production, développement, sandbox…), la politique de chiffrement des données (gestion et rotation des clés en particulier) et la configuration de système d’alertes (avec le service CloudTrail). Un point important à analyser est la gestion des utilisateurs : permissions, droits d’accès et également le processus de validation des tâches mis en place.

Réseau
L’accent portera sur la stratification des couches réseaux : identifier ceux ouverts au monde (@open bar !), lister les subnets privés et les ressources attachées, vérifier les connections VPN et l’utilisation de bastion (point d’accès unique sécurisé). Les mécanismes pour procéder à l’intégration de nouvelles adresses IPs et la stratégie pour sécuriser les points d’entrées (CloudFront ? AWS Shield ? Firewall ?) sont des exemples sur lesquels le consultant se penchera.

Fiabilité & Robustesse
La résilience du système sera étudiée dans cette catégorie avec l’analyse du dispositif de détections de pannes, du plan de reprise d’activités (DRP) et la configuration du scaling en cas de montée / baisse de charge. AWS proposant pour de nombreux services (EC2, VPC, RDS…) l’hébergement sur plusieurs zones de disponibilité, la répartition des ressources sur ces zones sera passée à la loupe afin d’éviter tous risques de perte de données ou d’arrêt de service.

audit-cogs

Organisation des ressources & Documentation
Souvent, parent pauvre du secteur de l’IT, la documentation se doit d’être complète et correctement maintenue (DAT, runbook, périodicité des livrables). La supervision des ressources est aussi une thématique qui sera passée au crible : l’inventaire est-il configuré correctement ? Les conventions de nommages et de tagging sont bien établies et respectés ? Il est important aussi de notifier le degré d’automatisation de process et jusqu’où le DevOps est-il opérationnel.

Pratiques Devops
En lien avec la catégorie précédente, il s’agira d’étudier comment le DevOps est intégré au sein de la structure. Le consultant doit identifier les mécanismes mis en place concernant le gestionnaire de référentiel tel que GitHub ou Bitbucket et quel modèle de branche est privilégié (par exemple Gitflow). Également concerné, la qualité du code (règle de codage de type PSR-2) et le degré de couverture de code sont des éléments auxquels le consultant proposera des ajustements.

Monitoring et Visibilité
L’audit portera ici sur le traitement des événements importants : centralisation des journaux de logs aussi bien pour l’applicatif que pour l’infrastructure, utilisation d’outils de monitoring (établissement de dashboard avec CloudWatch ou services tiers), réactivité du système (temps réel)… La question des cycles de vie concernant les logs est aussi un point abordé dans cette catégorie.

Gestion des données
Le stockage et l’utilisation des données sont des thématiques largement mis en avant du fait de l’actualité. En effet avec la promulgation du Règlement européen de protection des données personnelles (GDPR), les informations sensibles et personnelles doivent être disponibles et sécurisées. Ces contraintes peuvent influer sur la stratégie en place autour des backups, des volumes de stockage et sur le fonctionnement des bases de données. Cette conformité est vérifiée par le consultant.

Optimisation des coûts
Le cloud permet de nombreuses améliorations aussi bien en termes de souplesse au sein de l’infrastructure que de coût mais reste un environnement complexe. De ce fait, il est important de maitriser ces coûts et de vérifier que l’infrastructure est optimisée en ce sens. Des services d’AWS comme Trust advisor ou des outils tiers comme ceux proposés par CloudCheckr permettent des suivis et des alertes concernant la facturation. La configuration de ces outils et l’adoption d’une stratégie concernant les cycles de vies des ressources (lifecycle policy) sont des problématiques abordées lors d’un audit.

audit-cloud

L’audit peut être exhaustif mais également restreint à certaines ressources ou services d’AWS. L’important est que le périmètre d’actions soit bien délimité afin que le commanditaire et le consultant aboutissent ensemble à un compte rendu lisible et des solutions concrètes à mettre en place. L’entreprise est partie prenante d’un audit en fournissant les accès aux ressources et une présentation générale du S.I adhérant aux éléments audités.
Le consultant réalise alors un rapport d’audit et une présentation est effectuée devant le comité de direction.

Corexpert est un Advanced Consulting Partner d’AWS riche de plus de 10 ans d’expérience dans la plateforme AWS. Vous souhaitez bénéficier de nos conseils sur votre implantation dans le cloud d’AWS ? De mener à bien votre projet de migration ?  N’hésitez pas à nous contacter !

TeamWork et Corexpert atteignent les 50 certifications AWS !

TeamWork et Corexpert atteignent les 50 certifications AWS !

AWS est un environnement proposant chaque jour de nombreuses améliorations de leurs services : il suffit de jeter un coup d’œil sur la page regroupant les nouveautés pour voir la volonté d’innovation d’AWS.

Comment vérifier l’expertise nécessaire lors de la conception, du déploiement et de l’exploitation des ressources AWS lorsque celles-ci sont en perpétuelle mutation ?
En passant les attestations proposées par AWS !

Réparties en plusieurs pôles, ces certifications récompensent l’utilisation pertinente des services d’AWS, promeuvent l’établissement d’architecture raisonnée et vérifient les connaissances du candidat avec des exemples concrets issus de la sphère professionnelle. Régulièrement mises à jour et encadrées par des organismes de contrôle, ces certifications sont des garanties de l’expertise du candidat sur le sujet.

aws-certifications-5

Aujourd’hui, TeamWork et Corexpert ont atteint une distinction particulière concernant le nombre de certifiés : nos équipes comptent plus de 50 certifications. Cet engagement pour le cloud d’AWS démontre la capacité de la plateforme à s’adapter et proposer des solutions pour tous types de projets. Nos experts sont prêts à répondre à toutes vos questions sur le cloud et à vous guider dans vos projets innovants. Recherche d’optimisation des coûts, volonté de migration vers le cloud, automatisation de processus, intégrations de services AWS en complément d’un environnement sur site ; toutes ces thématiques (et bien d’autres !) peuvent être partagées avec notre équipe pour élaborer une stratégie hybride ou entièrement sur le cloud !

En plus de ces certifications, TeamWork et Corexpert possèdent également des compétences reconnues dans la migration SAP et est un partenaire plébiscité par AWS pour AppStream 2.0.

Corexpert fête ses 10 ans sur le territoire lyonnais !

Corexpert fête ses 10 ans sur le territoire lyonnais !

Corexpert existe depuis maintenant douze ans mais cette année 2018 marque les 10 ans de présence de Corexpert sur la région lyonnaise. Petit tour d’horizon de l’entreprise avec Alexis Daguès, CEO et co-fondateur de Corexpert.

Corexpert a été créé en 2006 à Anglet puis une agence s’est ouverte à Lyon deux ans plus tard. Pourquoi ce choix de rester en province plutôt que d’aller à Paris par exemple ?

Le siège historique a été créé dans le pays basque, nous avons privilégié la création de la société dans une région que les associés appréciaient particulièrement ou étaient d’origine.

Corexpert déploie sur la plateforme AWS depuis maintenant plus de 8 ans. Comment s’est construit cette relation ? Comment ce partenariat a-t-il évolué au fil des années ?

Corexpert a incubé de nombreux projets dont certains ont donné naissance à d’autres sociétés (startup) dans des environnements tels que le jeu vidéo en ligne par exemple. Cela a restreint rapidement à l’époque le choix d’un partenaire tel que AWS pour supporter des audiences internationales, à fort trafic. Nous avons démarré avant que AWS ouvre son bureau à Paris ! Dès 2013, le sujet de devenir partenaire est arrivé et nous avons concentré progressivement notre activité sur des projets utilisant le leader du cloud public.

Corexpert est très moteur dans la sphère locale : organisateur des meetups AWS, partenariat à des événements AWS lyonnais, initiateur du premier AWS DevDay. Est-ce que cette volonté de promouvoir l’événementiel local a toujours été voulue ?

L’organisation du meetup est une initiative personnelle en 2015 et largement soutenue par l’arrivée de Julien Simon, Technical Evangelist AWS. Corexpert est l’initiateur des premiers AWSome Day à Lyon, ainsi que le premier DevDay en France, soutenu directement par le créateur des DevDay venu de Seattle et par Intel. Nous sommes des experts techniques et l’évènementiel n’était pas notre priorité : une sagesse du terroir dont je suis issu dit “A Grand diseux, Petit faiseux” mais nous avons dû sortir les mêmes armes pour exister.

Depuis ces 10 ans d’implémentation sur Lyon, Corexpert a mené à bien de nombreux projets faisant appels à un champ de compétences variées. De ces expériences, lequel a été le plus ambitieux ou plus enrichissant ? Sur quelles domaines ces expériences ont-elles été le plus enrichissantes ?

Issu du monde du développement logiciel et non de l’infrastructure, chaque projet a eu sa part de challenge. C’est ce que nous recherchons, la complexité, le besoin de faire travailler nos méninges, de construire des chaînes de déploiement automatisé avant même l’arrivée du concept de DevOps. Certains projets ambitieux ont particulièrement marqué notre développement, dans l’analytics en temps réel, le geomapping, le matchmaking dynamique et scalable dans le jeu vidéo, les serveurs publicitaires, les plateformes de paiements… Nous accompagnons des projets passionnants sur des secteurs parfois de disruption.

La participation au AWS Summit à Paris l’année dernière en 2017 a été un moment fort avec la démonstration d’Amazon Rekognition (introduit en 2016) avec Amazon Alexa. Quel retour d’expérience sur ce projet ?

Ce projet était un démonstrateur de notre expertise à créer une solution de bout en bout, avec un time to market hors du commun. Les développeurs sont dotés de superpouvoirs avec les services Cloud, c’était d’ailleurs la thématique de la Keynote de Werner Vogels, CTO de Amazon au Re:Invent 2017. Cette démo de 10 minutes a déclenché des demandes de projets en Nouvelles Zélande, Chine, New-York et Paris bien sûr.

Fin 2017, TeamWork a réalisé l’acquisition de Corexpert, connu surtout pour son expertise dans le monde SAP. En dehors d’atouts de complémentarité de services, quels avantages dans cette acquisition ?

En rejoignant le groupe créé par Philippe Rey-Gorrez à Genève en 1999, nous avons doté Corexpert d’une nouvelle compétence rare sur le marché Cloud : le déploiement d’infrastructures SAP. De plus, TeamWork s’est diversifié dans différents univers Data Analytics où les équipes pluridisciplinaires accompagnent les clients sur leur stratégie data de la collecte logicielle ou physique (IoT) mais aussi vers l’exploitation de ces données pour trouver de nouveaux axes business (Deep Learning).

Un autre univers s’est ouvert également, le Business Consulting nous permettant d’introduire l’innovation dans les Directions Générales, Financières et là encore le Cloud AWS est un accélérateur pour des “Proof of Value” par exemple.

Enfin nous avons construit ensemble avec la branche Système et Infrastructure de TeamWork, une offre de NextGen Managed Services Provider avec une offre Cloud de Maintien en Condition Opérationnelle (Run), extrêmement agressive sur le marché.

AWS met à jour très régulièrement ces services en ajoutant de nouvelles possibilités ou améliorant la gestion des fonctionnalités. Quel service semble le plus prometteur à recevoir des modifications majeures ?  Quel service semble être plébiscité par les utilisateurs en ce moment ?

Je crois beaucoup aux solutions de End User Computing (Amazon AppStream 2.0) notamment, permettant de virtualiser et streamer n’importe quelle application dans un navigateur, sans avoir à gérer le cluster de serveurs.

Clairement la conteneurisation est devenue la hype du moment, mais personnellement je crois bien plus au FaaS (Function as a Service) tel que Lambda et à Serverless en général.

Internet des objets (IoT), machine learning, serverless, migration d’infrastructure sur le cloud, toutes ces thématiques vont ou sont déjà des enjeux majeurs pour les entreprises. Comment l’équipe de Corexpert est-elle préparée à répondre à ces problématiques ?

On ne découvre pas les services, on les pratique au quotidien. Corexpert n’est pas opportuniste et nous sommes convaincus par les solutions que nous proposons, nous avons un avis tranché et objectif. Si un client souhaite expérimenter, soit, en revanche par défaut nous ne proposons que des solutions avec un recul en production et en run de notre côté.

Avec l’expansion des services AWS, la demande croissante d’information sur le cloud et la nécessité d’une expertise en continue, comment Corexpert se projette pour la suite ?

Corexpert est l’expert AWS en Région, nous nous adaptons à une demande du marché extrêmement variée de migrations dites “All-In”, hybridations, développements cloud natives etc. Cela passe par une structuration interne pour supporter notre croissance, une forte démarche de capitalisation de nos connaissances; j’ai du mal à croire que nous nous lasserons de l’innovation apportée par le leader du Cloud, qui devrait tripler en quelques années le nombre de services majeurs proposés.

Et pour finir combien de machines à café épuisées à la tâche ?

7 machines !

Un projet innovant ? Des interrogations sur la migration de ressources sur le cloud ? N’hésitez pas, contactez nous !

Bien débuter avec Amazon EC2 Container Service (101) – Cluster & task

Bien débuter avec Amazon EC2 Container Service (101) – Cluster & task

Nous continuons dans la série “Bien débuter avec Amazon EC2 Container Service” en se concentrant sur les tasks et les clusters qui vont les héberger.

1 – Qu’est ce qu’un Cluster

Un cluster ECS est un regroupement d’instances EC2 qui vont héberger vos containers.

Exemple d'un cluster ECS
Exemple d’un cluster ECS

Un cluster peut contenir une ou plusieurs instances, de différents types et taille. Dans notre exemple, nous utiliserons une t2.micro.

2 – Création d’un cluster ECS

Nous allons nous connecter à la console web aws pour ecs. Nous allons cliquer sur “Cluster” dans le menu de gauche. Dans l’écran suivant (liste des clusters), nous allons cliquer sur “Create Cluster” pour créer notre premier cluster.

Dans l’écran de création de cluster nous avons un formulaire très complet avec de nombreuses options. Nous allons utiliser les champs suivants :

  • Cluster Name : helloworldCluster
  • Provisioning Model : On-Demand Instance
  • EC2 instance type : t2.micro
  • VPC : choisir la VPC où vous désirez créer vos instances
  • Security group : Choisir/Créer un security group qui ouvre le port 80

Cliquez sur le bouton bleu “Create” pour créer le cluster. Il devrait maintenant apparaître dans la liste des clusters

ECS Cluster
ECS Cluster

3 – Task Definition ou comment définir le lancement des containers

Une task definition est une liste des paramètres qui vont permettre le lancement de nos containers.

Pour la créer, nous allons cliquer sur “Task definitions” dans le menu de gauche, puis sur le bouton bleu “Create new Task Definition”.

Cette première task definition va nous permettre de lancer un container, qui aura son port HTTP (80) lié au port 8080 sur l’instance hôte.

Pour notre exemple nous allons remplir les champs suivants :

  • Task Definition Name : Helloworld-1
  • Container Definitions : cliquez sur “add container”
    • Container name : Helloworld
    • Image : 123456789012.dkr.ecr.eu-west-1.amazonaws.com/helloworld:latest
    • Memory Limits (MB) : 128
    • Port mappings :
      • Host : 8080
      • Container : 80
      • protocol : tcp
    • Cliquez sur le bouton “Add”

Vous pouvez ensuite cliquer sur le bouton bleu “Create”

ECS Task definition
ECS Task definition

De nombreuses autres options sont disponibles dans le Container Definitions, pour permettre une définition fine des besoins des containers (Mapping de volumes, lien entre containers …)

4 – Exécution d’une task

Maintenant que nous avons créé notre Cluster de machine hôte et que nous avons décrit la manière de lancer le container, nous pouvons enfin l’exécuter.
Pour cela, nous allons cliquer sur le menu “Cluster” puis choisir dans la liste notre cluster helloworldCluster. Nous arrivons donc ici :

ECS Cluster Hello world
ECS Cluster Hello world

Cliquez sur l’onglet “Task” puis sur le bouton bleu “Run new Task”
Dans l’écran suivant nous allons choisir tous les éléments que nous avons créé précédemment

ECS run task
ECS run task

La task est créée et est prête à recevoir des messages.

5 – Connexion au container

Il ne reste plus qu’à valider que le container répond bien à nos requêtes HTTP.
Nous allons nous connecter directement à l’instance hôte sur le port 8080.
Pour trouver son IP, il suffit de cliquer sur le nom de la task (dans notre cas 67f6a5b4-4…) pour afficher les détails.
Dans la partie container il faut cliquer sur le triangle à côté du nom du container (helloworld) pour afficher les détails, l’IP sera dans la section “Network Bindings”

ECS host IP
ECS host IP

Vous pouvez ensuite aller dans votre navigateur préféré, et entrez l’url du container pour afficher la page

ECS task result
ECS task result

Félicitations, vous avez fait fonctionner votre premier container sur Amazon EC2 Container Service.

Dans le prochain article nous verrons comment aller plus loin en créant un service se basant sur l’image de container existante. Ainsi plusieurs containers seront lancés et pourront répondre à vos requêtes

Bien débuter avec Amazon EC2 Container Service (101) – ECR

Bien débuter avec Amazon EC2 Container Service (101) – ECR

Docker est une technologie qui fait grand bruit depuis plusieurs années maintenant dans le domaine de l’IT.

docker-vs-aws
AWS vs docker in google search

Tous les grands cloud publics (Amazon Web Service, Google Cloud, Microsoft Azure) proposent une solution plus ou moins intégrée pour la gestion des containers. Dans ces articles nous allons vous expliquer comment débuter avec succès sur le service managé Amazon EC2 Container Service.

Cette série d’articles suppose que vous avez créé un VPC où seront créé les instances hôtes pour les containers docker, que la CLI AWS est installée sur votre poste et nous utiliserons une image “Hello-world” (dockercloud/hello-world) disponible sur le docker hub.

1 – Création du dépôt Docker Privé (ECR)

Pour être déployé, une image de container doit être mis à disposition dans un dépôt docker.
Plusieurs solutions sont disponibles, Amazon Web services (AWS) nous propose un dépôt privé managé (ECR) à un tarif intéressant (0,1$/Go/mois au 01/08/2017).

Pour déployer notre image sur ECR ( Amazon EC2 Container Registry ) nous allons tout d’abord récupérer cette image sur le docker hub.

Maintenant que nous avons notre image, nous allons la déposer sur ECR
Nous allons nous connecter à la console web aws pour ecs.

1a – Si vous n’avez pas encore utilisé le service

  • vous allez tomber sur la page “get Started”, il vous suffira alors de cliquer sur le bouton bleu “getStarted” au milieu de la page.
  • Sur l’écran suivant (Getting Started with Amazon EC2 Container Service), décocher la case pour ne pas déployer la demo ECS (sample)
Getting Started with ECS
Getting Started with ECS

1b – Si vous avez déjà utilisé ECS

Il suffit de cliquer sur “Repositories” puis sur “Create Repository”

2 – Sur la page suivante

vous allez pouvoir donner un nom à votre dépôt, helloworld dans notre cas. Puis l’on passe à l’étape suivante (Next step)

ecr-name

3 – La dernière page

elle nous donne toutes les indications pour utiliser le dépôt qui vient d’être créé.

2 – Ajout d’une image sur ECR

Nous allons déposer notre image HelloWorld sur le dépôt. Pour cela nous allons nous connecter sur ECR à partir de notre machine (notre dépôt est en ireland)

Nous obtenons une ligne de commande qui va nous permettre de nous connecter à ECR

Nous sommes maintenant connectés, nous pouvons pousser l’image locale

Si vous vous connectez sur la console web AWS, vous pourrez voir votre image dans le dépôt

Docker Image in ECR repository
Docker Image in ECR repository

Dans le prochain article nous allons utiliser cette image pour lancer un container docker sur ECS.

@ Très bientôt

Le SLA chez Amazon Web Services #AWS

Le SLA chez Amazon Web Services #AWS

Cet article a été mis à jour en janvier 2019 avec les modifications du SLA fourni par AWS. Les compléments d’information ont été intégrés directement dans l’article d’origine.

Chez Corexpert, nos clients nous posent souvent cette question :

« On nous parle toujours de Haute Disponibilité et Très Haute Disponibilité chez AWS, mais s’engagent-ils vraiment ? Existe-t-il un SLA ? »

 

Qu’est ce que le SLA ?

Le SLA, ou Service Level Agreement, est le niveau de qualité et de performance contractuel d’un service ou d’une infrastructure technique. Dans le cas de AWS, fournisseur Cloud, on parlera donc bien d’un service, vue qu’on évolue dans le monde IaaS – Infrastructure as a Service !

Le SLA doit cadrer en premier lieu de quelle fourniture nous parlons, et les critères de performances sur lesquels le fournisseur va s’engager. On pourra donc parler de temps de réponse, de fonctionnalité assurée, de disponibilité complète du service etc.

SLA chez AWS

Nous allons parcourir ci-dessous les principaux services, ou services majeurs de l’offre AWS, qui possèdent un SLA à la date de rédaction de cet article. Bien évidemment la liste est non exhaustive.

Amazon Route 53 : SLA du DNS AWS

Le service DNS de AWS, Amazon Route 53, possède un SLA de disponibilité du service du niveau le plus haut possible. En effet on a ici un engagement de disponibilité de 100% sur le service, ce qui est explicité par « Amazon Route 53 n’échouera pas pour répondre à vos requêtes DNS dans le cycle de facturation d’un mois ». Pourquoi parler d’un mois ? Car AWS, s’engage, en cas d’éventuelle défaillance avérée, de vous rembourser sous forme de crédits sur ce cycle de facturation.

sla-amazon-route-53

Extrait de la page SLA – Amazon Route 53 au 29 décembre 2016

Amazon EC2 ou Elastic Cloud Compute : SLA des VM AWS

Service principal de AWS, Amazon EC2 et Amazon EBS fournissent respectivement l’hyperviseur managé pour executer vos Machines Virtuelles, aka instances EC2 et le stockage virtualisé Amazon Elastic Block Store. [Le SLA a été étendu à Amazon Elastic Container Service (ECS) et AWS Fargate (deux services ayant traits aux conteneurs Docker) depuis 2018].

Le SLA des services, avec l’engagement de Amazon Web Services, est d’au moins 99.95% mensuel. Soient moins de 22 minutes.

Si une indisponibilité était avérée entre 99.95 et 99.0%, AWS s’engage à effectuer une remise de 10% en crédits AWS sur le service EC2, en deça de 99.0% de disponibilité AWS proposera une remise de 30% en crédits. [La période d’indisponibilité est maintenant de 90.0% à 99.99% depuis 2018 pour la remise de 10% de crédit AWS.]

Il est important de noter que le SLA est lié à l’état « Region Unavailable« . Si vous ne le savez pas déjà, une région est l’ensemble de plusieurs zones (2+) de disponibilités, mais dans le cadre du SLA, AWS précise que l’état « Région indisponible » vous concerne si plus d’une zone de disponibilité où vous exécutez des instances EC2 est indisponible, comprendre les instances n’ont plus accès à Internet.

L’indisponibilité de EBS est avérée lorsque les volumes de stockage ne génèrent plus d’I/O avec une file d’attente non vide.

Amazon RDS, SLA des bases de données managées AWS

Amazon RDS est le service de Base de données managée par AWS, il supporte à ce jour MySQL, Oracle, PostgreSQL, MariaDB, Microsoft SQL Server, AuroraDB. Mais le SLA proposé par AWS, concerne uniquement les instances Multi-AZ (c’est à dire avec un serveur en Stand-By mode dans une autre zone de disponibilité) des moteurs SQL : Oracle, MariaDB, MySQL & PostgreSQL. Ce SLA est de 99.95% de disponibilité du service. L’indisponibilité est avérée quand toutes les requêtes de connection échouent pendant une minute sur l’instance RDS multi-AZ.

sla-amazon-rds

Engagement de AWS pour RDS et remboursement en crédits au 10 janvier 2019

Amazon S3, SLA du stockage AWS

Amazon S3 est le service de stockage d’objets, il est l’un des plus anciens services de AWS, et possède une durabilité des données de 99.999999999% en mode de stockage standard. Toutefois le SLA, concerne la disponibilité d’accès à la données stockée via l’API AWS. Le SLA de Amazon S3 est donc calculé sur le comptage d’erreurs ou d’indisponibilité de l’API sur 5 minutes.

L’engagement de AWS est de conserver une disponibilité au-delà de 99.9% mensuel, ce qui représente moins de 43 minutes 36 secondes.

Si AWS ne peut assurer cette disponibilité sur la région où est stocké votre bucket S3, alors 10% de remise sur le coût de stockage S3 seront reversés en crédits, et en deça de 99.0%, alors la remise en crédit s’élèvera à 25% du coût du service Amazon S3.

[Depuis janvier 2019, ces règles ont été étendues à Amazon Elastic File System (EFS) avec les mêmes engagements que pour S3. Amazon EFS est un système de stockage de fichiers simple managé (AWS gère l’infrastructure pour vous).]

Amazon CloudFront, SLA du CDN AWS

Amazon Cloudfront est le service CDN de AWS, avec plusieurs dizaines de « Edge Locations », ce service met en cache les requêtes web selon vos comportements et pattern d’URLs choisis. Il permet des diffusions et donc des chargements de données accélérés sur les sites web et applications mobile, notamment lorsque du contenu media transite.

AWS s’engage à maintenir une disponibilité globale du service au-dessus de 99.9% mensuel (identique à Amazon S3). Les remises effectuées sur le service, en cas de défaillance avérée, également basé sur la fréquence des erreurs d’accès aux données sont identiques à celles de Amazon S3.

AWS Shield, SLA du service de protection anti-DDoS

Lancé lors du re:Invent 2016, AWS Shield est l’officialisation de la protection anti DDoS de AWS. Le service utilise et protège les autres services Amazon CloudFront et Amazon Route 53, et son SLA, ramené sur des périodes de 24 heures, est lié directement aux SLA des produits cités précédemment. On pourra donc traduire ce SLA, par un simple rappel que l’utilisation du service AWS Shield devant Amazon CloudFront ou Amazon Route 53 ne modifie pas leur SLA.

Amazon API Gateway, SLA sur la gestion des API

Depuis janvier 2019, AWS s’engage à assurer une disponibilité de 99.95% mensuel du service Amazon API Gateway. Ce service entièrement managé facilite la gestion, la surveillance et la sécurité des API de n’importe quelle taille. En cas de rupture du service, le crédit alloué est identique à ceux de RDS : 10% de remise entre 99.0% et 99.95% et 25% de remise pour une disponibilité mensuelle moindre à 99.0%.

Amazon EMR, SLA sur les frameworks Big Data

En janvier 2019, Amazon EMR bénéfice d’un engagement en terme de disponibilité de la part d’AWS. Les frameworks Big Data gérés par le service possède un SLA de 99.9% mensuel.

emr_sla.Engagement de AWS pour EMR et remboursement en crédits au 10 janvier 2019

Amazon Kinesis, SLA sur la gestion des données en streaming

Amazon Kinesis traite de la collecte, du traitement et de l’analse de données en streaming en temps réel. Le SLA sur lequel s’engage AWS depuis janvier 2019 touche trois composants principaux de Kinesis : Videos Streams, Data Streams et Data Firehose. L’engagement de disponibilité des services est de 99.9% mensuel avec une remise de 10% à 25% en cas d’indisponibilité.

Synthèse des SLA chez AWS

Service AWS SLA mensuel SLA minutes/mois
Amazon Route 53 100.00 % 0 seconde
Amazon EC2 99.99 % 4 minutes 30 secondes
Amazon RDS 99.95 % 21 minutes et 36 secondes
Amazon S3 99.90 % 43 minutes et 12 secondes
Amazon CloudFront 99.90 % 43 minutes et 12 secondes
AWS Shield Cf. CloudFront ou Route 53 Cf. CloudFront ou Route 53
AWS API Gateway
99.95 % 21 minutes et 36 secondes
Amazon EMR
99.90 % 43 minutes et 12 secondes
Amazon Kinesis
(Data / Videos Stream /
Data Firehose
99.90 % 43 minutes et 12 secondes

 

Calcul du SLA d’une infrastructure AWS

Partons d’une infrastructure Web App, relativement classique. Elle est composée de plusieurs serveurs applicatifs frontaux, ici EC2 C4.Large, le code exécuté est le même sur chaque instance, et nous avons une redondance multi-zone de disponibilités. La base de données est un MySQL sur RDS en Multi-AZ (Stand-By Instance). Les éléments statiques du sites sont stockés sur S3. CloudFront, est placé devant le Load Balancer, il met en cache les éléments statiques de S3 et reroute les autres requêtes sur le LoadBalancer. Route53 gère le nom de domaine du site.

cloudcraft-web-app

Infrastructure Web : Amazon Route 53, CloudFront, S3, EC2 et RDS

Voici comment nous pouvons calculer le SLA de cette infrastructure, bien entendu celui-ci est dans le cas d’une défaillance de tous les services AWS utilisés sur une région, et dans le cadre du SLA de chacun de ses services. Dans ce cas l’infrastructure ne peut prétendre à un SLA supérieur sans redondance supplémentaire.

  • RDS Multi-AZ MySQL : SLA de 99,95 %
  • EC2 : SLA de 99.95 %
  • CloudFront : SLA de 99.9 %
  • S3 : SLA de 99.9%
  • Route 53 : 100.0 %

Le SLA de l’infrastructure brute sera de :

99.95% x 99.95% x 99.9% x 99.9% x 100% = 99,70 %

Si l’on considère que l’indisponibilité S3 n’est pas critique pour la conservation de la disponibilité de l’infrastructure web (par exemple une API) et qu’on gère via Route 53 l’éventuel downtime de CloudFront en pointant vers le Load Balancer en secours, nous gagnerons 0,2% de SLA juste par modification et optimisation du Design de l’infrastructure :

99.95% x 99.95% x 100% = 99,90 %

N’hésitez pas à poser vos questions ou nous contacter pour plus d’informations.