Microsoft, VMware and Amazon jockey for pole position in race to manage the cloud

Summary: Three companies each have their own method of linking an organisation’s datacentre with public clouds, but each one holds risks and benefits for the customer that must be considered.

With Microsoft's new version of Windows Server, the company has committed to a proprietary model of computing where the Redmond software giant makes sure all roads lead to Azure, its own cloud offering.
Microsoft's update is just one of the moves underway as tech companies look to consolidate their positions in the vitally important cloud computing space. Three of the largest players, Microsoft, VMware and Amazon, are trying to strengthen their positions using very different strategies that will force big - and hard-to-reverse - decisions on the organisations that adopt their technologies, and raise issues about vendor lock-in and standards.

Better the devil you know

Microsoft's tactic is simple - most enterprises use its desktop operating system and a large amount use its server management software as well. (In the second quarter of 2012, just under half [47.9 percent] of all the revenue generated from worldwide server shipping came from Windows Server boxes, according to IDC.)

However, much of these workloads could easily move to the private cloud, where Microsoft is in competition with companies like VMware, or to the public cloud, where fewer companies use Microsoft's Windows Azure compared to Amazon Web Services's suite of technologies.
Microsoft's solution, along with tweaking its Windows Azure public cloud, is to have more of the characteristics of Amazon's, and to update Windows Server to be its 'cloud OS'. It has attempted to do this by increasing the capabilities of its Hyper-V hypervisor to add better replication and software-defined networking features, along with usability tweaks to bring the user interface in line with the clean, modern interface used in Azure.
Along with the above, it has closely tied Azure and Windows Server together. For instance, it has made it easier to tie data on the two systems together by introducing the Windows Virtual Hard Disk feature, which lets admins bundle data into a VHD file and sling it up into Azure.
With its cloud, Microsoft is betting that enterprise customers want to go from one familiar interface (Windows 7, in a few years Windows 8), into another (Windows Server), then perhaps dabble with some advanced cloud management (System Center 2012), and finally put some data on the road to the cloud which, yes, will look very much like the on-premise environment.

Microsoft's operating system versus VMware's application

In contrast, VMware is aiming to use its dominance of the application layer - via its widely used virtualisation technology - as a lever with which to move enterprises into its own cloud. As of July, VMware had 52.4 percent of virtualised workloads sitting on its hypervisor, while Microsoft had 26.6 percent, according to IDC. While Microsoft has great tools for managing Windows and Windows-virtualised environments, VMware has the edge when it comes to virtualised applications.
In VMware's world, administrators are not managing multiple operating systems but are instead managing applications. The benefits to this approach are the flexibility it brings administrators, with access control policies and data migration made easier by the greater granularity of VMware's technology.

In VMware's world, administrators are not managing multiple operating systems but are instead managing applications

However, it also has drawbacks - namely that if you want to manage all these virtual machines, you need to use VMware's technology, and if you want to move to a cloud, you need to find one that gives you the management tools you are used to with VMware.
Unfortunately, there are not many of these around, and those that do exist are either funded by VMware - Cloud Foundry - or built atop its vCloud Director software. Though VMware likes to point to examples of public and private clouds based around its vCloud Director software (a sportswear company, a telecommunications company, etc), none of them are very big compared to incumbents like Amazon.
VMware's problem is that its technology has been phenomenally successful in the datacentre, but when it comes to the cloud, companies like to have greater control over their technology. As a hypervisor is to data, so a water filter is to water: cloud companies do not necessarily want to build their money-making services around something proprietary operated by a competitor.
For this reason major clouds either use technology that is proprietary (Microsoft, via Hyper-V for Azure), open source (Red Hat via KVM), or shrouded in secrecy (Amazon Web Services, via a tweaked Xen hypervisor).
So if clouds are not willing to directly support VMware, it adds another step for administrators when migrating data into public clouds. To shift information into Amazon, for example, you need to use Amazon's EC2 VM Import Connector to pull in information from ESX VMDK images, among others.
So where does this leave VMware? In much the same position it's been in for the past two years - flailing around with its great success in the datacentre, and struggling to carve out a space for itself in the huge clouds. If you use VMware, then building a VMware-based cloud makes a lot of sense for you, and VMware is aware of this; it is adding more and more features and capabilities to its software in this area. However, get too attached and you could find yourself locked in.

Amazon wants it all

That leaves Amazon, which has come at the issue from the opposite direction to Microsoft and VMware.
While these two companies have sought to shift their customers' data up and into the cloud, Amazon has gone the other way and has focused on making it easier for administrators to pull data down from Amazon and into their on-premise datacentre.

Read this

AWS: The complete guide to Amazon's cloud

Read more

Its rationale is that its cloud can become the main cloud that companies use when going public, and to do this it is building a large set of technologies to make it easier to link private clouds with its own.
Amazon's strategy is one of divide and conquer, where it attacks the on-premise datacentre from many different points. It has its own initiatives, such as the Amazon Storage Gateway, to install itself via an agent into the private datacentre.
It also has partnerships, such as its important tie-up with Eucalyptus, a provider of on-premise cloud software.
Finally, Amazon, due to its size and the growing importance of its APIs, is being supported by the major enterprise companies, with organisations from Oracle to IBM building technologies that help data move from their applications into its cloud.
Amazon's strategy is the simplest one for the company, as it mostly involves standing back and letting the software interconnections accrue, but can be the greatest headache for the storage administrator. This is because Amazon's success has come from organic adoption by an ecosystem of software partners, contributors and hangers-on. This presents the enterprise with a lot of options, but few management capabilities, nor a single user experience.
Taken together, when we look at Microsoft, VMware and Amazon's attitudes to cloud we are presented with three choices. Either an administrator can get totally locked in to Microsoft and enjoy the simplification that comes from that; or they can get a bit more complication by opting for a fragmented-but-well-supported VMware experience; or they can take any concept of usability out back and shoot it in the head, and go for an all-Amazon solution, thereby enjoying the greatest possible amount of flexibility.
Each choice has its drawbacks and its benefits, but with three horses in the race for end-to-end clouds, it's likely the level of competition will bring lower prices and more features to the market as the companies compete for administrators' workloads.

Topics: Cloud, Amazon, Microsoft, VMware

Start-ups : la fin de la Silicon Valley ?

C'est le fondateur de Yammer, le réseau social d'entreprises vendu le mois dernier à Microsoft pour 1,2 milliard de dollars, qui lance le débat. La mythique Vallée californienne, creuset mondial des start-ups, « telle que nous la connaissons » serait sur le point de disparaître... 

Accès de déprime estivale ? David O. Sacks, le fondateur de Yammer, le réseau social d'entreprises qu'il a accepté de vendre la bagatelle de 1,2 milliard de dollars à Microsoft fin juin, prédit rien de moins que « la fin de la Silicon Valley telle que nous la connaissons. » Sur son compte Facebook, l'entrepreneur, ancien de chez PayPal, qui reste à la tête de l'équipe de Yammer en tant que vice-président dans la branche entreprises de Microsoft, se désole : « je pense que la Silicon Valley telle que nous la connaissons touche à sa fin. Pour créer une nouvelle société qui réussisse, il faut trouver une idée 1) qui échappe à l'attention des grandes sociétés Internet, qui sont mieux gérées qu'elles ne l'ont jamais été ; 2) que l'on peut lancer et éprouver pour environ 5 millions de dollars, le montant typique d'un premier tour de table, et 3) que l'on peut protéger des assauts de ces grandes entreprises une fois qu'elles ont compris de quoi il retourne. Combien d'idées de ce type reste-t-il ? » s'interroge ce quadra, diplômé de Stanford qui a aussi fondé le site de généalogie Geni.com.
Marc Andreessen se lance dans un débat de haut vol
Le débat est lancé, comme l'a relevé le site spécialisé TechCrunch. Un débat de haut vol. Ces quelques lignes ont attiré une cinquantaine de commentaires, notamment de bons connaisseurs de la Vallée, à l'image de Marc Andreessen, le fondateur du navigateur Netscape, devenu investisseur dans des start-ups et siégeant au conseil d'administration de nombreuses sociétés high-tech dont eBay, HP et Facebook. Combien d'idées donc ? « Un nombre infini », lui répond Andreessen, « car la créativité humaine est sans limite, et les opportunités sans fin. » David O. Sacks lui réplique qu'il y a trop d'acteurs en place pour que les start-ups arrivent désormais à émerger : « nous ne sommes pas à court d'idées mais nous serons peut-être à court de grandes nouvelles entreprises. » Et Andreessen de contre-argumenter : les start-ups attirent des talents des grands groupes, ce qui diminue la capacité de ces derniers à innover. De plus, une société établie privilégie la stabilité sur le changement, c'est « le dilemme de l'innovateur », elle tend à ne pas se cannibaliser elle-même par des innovations de rupture. On pourrait ici toutefois suggérer le contre-exemple d'Apple, qui n'a cessé de lancer des produits risquant de cannibaliser ses best-sellers, comme l'iPhone vis-à-vis de l'iPod ou l'iPad vis-à-vis des Mac.
Google et les grands groupes gorgés de cash, à court d'innovations ?
Les grands groupes peuvent-ils être de grands innovateurs ? Ce nouveau débat (lire l'intégralité des échanges sur le compte Facebook de David O. Sacks) fait écho aux échanges virulents entre Eric Schmidt, le président exécutif de Google, et Peter Thiel, cofondateur de Paypal et désormais capital-risqueur dans la Vallée, un des premiers à avoir investi dans Facebook notamment, il y a un mois lors de la conférence Brainstorm Tech organisée par le magazine Fortune à Aspen, dans le Colorado. « Vous avez 50 milliards de cash chez Google, pourquoi vous ne les investissez pas davantage dans la technologie, ou bien êtes-vous à court d'idées ? » avait lancé Peter Thiel à Eric Schmidt (lire la retranscription en anglais). « Il faudrait avoir l'honnêteté de dire que Google n'est plus une société technologique mais juste un moteur de recherche, une technologie développée il y une décennie » poursuit Thiel, dénonçant ces sociétés, comme Microsoft et Apple, qui accumulent des montagnes de cash et hésitent à verser à des dividendes, « parce qu'elles ne savent pas quoi en faire et ne veulent pas admettre qu'elles ne sont plus des entreprises high tech... » 

Le fondateur du réseau social d'entreprises Yammer lance le débat. DR. 

MPLS

1 - Introduction à MPLS

MPLS (Multi-Protocol Label Switching) est une technique réseau en cours de normalisation à l'IETF dont le rôle principal est de combiner les concepts du routage IP de niveau 3, et les mécanismes de la commutation de niveau 2 telles que implémentée dans ATM ou Frame Relay. MPLS doit permettre d'améliorer le rapport performance/prix des équipements de routage, d'améliorer l'efficacité du routage (en particulier pour les grands réseaux) et d'enrichir les services de routage (les nouveaux services étant transparents pour les mécanismes de commutation de label, ils peuvent être déployés sans modification sur le coeur du réseau).

Les efforts de l'IETF portent aujourd'hui sur Ipv4. Cependant, la technique MPLS peut être étendue à de multiples protocoles (IPv6, IPX, AppleTalk, etc,). MPLS n'est en aucune façon restreint à une couche 2 spécifique et peut fonctionner sur tous les types de support permettant l'acheminement de paquets de niveau 3.

MPLS traite la commutation en mode connecté (basé sur les labels); les tables de commutation étant calculées à partir d'informations provenant des protocoles de routage IP ainsi que de protocoles de contrôle. MPLS peut être considéré comme une interface apportant à IP le mode connecté et qui utilise les services de niveau 2 (PPP, ATM, Ethernet, ATM, Frame Relay, SDH ...).

La technique MPLS a été voulue par l'IETF relativement simple mais très modulaire et très efficace. Certains points clé sont maintenant mis en avant par l'IETF et par certains grands constructeurs dominés par Cisco, ainsi que par les fournisseurs de services aux premiers desquels se trouvent les opérateurs de réseaux. Un grand effort pour aboutir à une normalisation a été consentie par les différents acteurs, ce qui semble mener à une révolution des réseaux IP.

2 - MPLS: Objectifs et Missions

L'un des objectifs initiaux était d'accroître la vitesse du traitement des datagrammes dans l'ensemble des équipements intermédiaires. Cette volonté, avec l'introduction des gigarouteurs, est désormais passée au second plan. Depuis, l'aspect "fonctionnalité" a largement pris le dessus sur l'aspect "performance", avec notamment les motivations suivantes :

Intégration IP/ATM

Création de VPN

Flexibilité : possibilité d'utiliser plusieurs types de media (ATM, FR, Ethernet, PPP, SDH).

Differential Services (DiffServ)

Routage multicast

MPLS pourra assurer une transition facile vers l'Internet optique. MPLS n'étant pas lié à une technique de niveau 2 particulière, il peut être déployé sur des infrastructures hétérogènes (Ethernet, ATM, SDH, etc.). Avec la prise en charge de la gestion de contraintes molles et dures sur la qualité de service (DiffServ, Cisco Guaranteed Bandwidth). Avec la possibilité d'utiliser simultanément plusieurs protocoles de contrôle, MPLS peut faciliter l'utilisation de réseaux optiques en fonctionnant directement sur WDM.

Traffic Engineering permettant de définir des chemins de routage explicites dans les réseaux IP (avec RSVP ou CR-LDP). L'ingénierie des flux est la faculté de pouvoir gérer les flux de données transportés au dessus d'une infrastructure réseau. Aujourd'hui, cette ingénierie des flux est essentiellement faite à l'aide d'ATM, avec comme conséquence une grande complexité de gestion (en effet IP et ATM sont deux techniques réseaux totalement différentes, avec parfois des contraintes non compatibles). Avec l'intégration de cette fonctionnalité, MPLS va permettre une simplification radicale des réseaux.

Les labels peuvent être associés à un chemin, une destination, une source, une application, un critère de qualité de service, etc. ou une combinaison de ces différents éléments. Autrement dit, le routage IP est considérablement enrichi sans pour autant voir ses performances dégradées (à partir du moment ou un datagrame est encapsulé, il est acheminé en utilisant les mécanismes de commutation de niveau 2). On peut imaginer qu'un des services les plus importants sera la possibilité de créer des réseaux privés virtuels (VPN) de niveau 3. Ainsi, des services de voix sur IP, de multicast ou d'hébergement de serveurs web pourront coexister sur une même infrastructure. La modularité de MPLS et la granularité des labels permettent tous les niveaux d'abstraction envisageables.

3 - Le routage classique

IP est un protocole de niveau réseau fonctionnant dans un mode non connecté, c'est-à-dire que l'ensemble des paquets (ou datagrammes) constituant le message sont indépendants les uns des autres : les paquets d'un même message peuvent donc emprunter des chemins différents utilisant des protocoles IGP (interior gateway protocol), tels que RIP (routing information protocol) de type "Vecteur de distance", et OSPF (open shortest path first) de type "Etat de liens" , ou bien des protocoles EGP (exterior gateway protocol), tel que BGP (border gateway protocol). Chaque routeur maintient une table de routage, dans laquelle chaque ligne contient un réseau de destination, un port de sortie, et le prochain routeur relaie vers ce réseau de destination.



A la réception d'un datagramme, les noeuds intermédiaires (ou routeurs) déterminent le prochain relais (ou next-hop) le plus approprié pour que le paquet rallie sa destination. Ensuite l'adresse mac destination (niveau 2 du model OSI) du datagramme est remplacée par l'adresse mac du routeur relaie (ou next-hop), et l'adresse mac source du datagramme est remplacée par l'adresse mac du routeur courant, laissant sans changement les adresses ip (niveau 3 du model OSI) du datagramme afin que le prochain routeur effectue les même opérations sur le paquet pour les sauts suivants. Ce calcul fastidieux est effectué sur tous les datagrammes d'un même flux, et cela autant de fois qu'il y a de routeurs intermédiaires à traverser. Il est donc gourmand en terme de ressource machine. Le mode non connecté du protocole IP, qui était initialement l'un de ses atouts, en particulier pour sa scalabilité, est devenu aujourd'hui un frein à son évolution.

4 - La commutation de labels

Lorsqu'un paquet arrive dans un réseau MPLS (1). En fonction de la FEC auquelle appartient le paquet, l'ingress node consulte sa table de commutation (2) et affecte un label au paquet (3), et le transmet au LSR suivant (4).



Lorsque le paquet MPLS arrive sur un LSR [1] interne du nuage MPLS, le protocole de routage fonctionnant sur cet équipement détermine dans la base de données des labels LIB (Label Base Information), le prochain label à appliquer à ce paquet pour qu'il parvienne jusqu'à sa destination [2]. L'équipement procède ensuite à une mise à jour de l'en-tête MPLS (swapping du label et mise à jour du champ TTL, du bit S) [3], avant de l'envoyer au noeud suivant (LSR ou l'egress node) [4]. Il faut bien noter que sur un LSR interne, le protocole de routage de la couche réseau n'est jamais sollicité.



Enfin, une fois que le paquet MPLS arrive à l'egress node [1], l'équipement lui retire toute trace MPLS [2] et le transmet à la couche réseau.

5 - Principes MPLS

Basée sur la permutation d'étiquettes, un mécanisme de transfert simple offre des possibilités de nouveaux paradigmes de contrôle et de nouvelles applications. Au niveau d'un LSR (Label Switch Router) du nuage MPLS, la permutation d'étiquette est réalisée en analysant une étiquette entrante, qui est ensuite permutée avec l'étiquette sortante et finalement envoyée au saut suivant. Les étiquettes ne sont imposées sur les paquets qu'une seule fois en périphérie du réseau MPLS au niveau du Ingress E-LSR (Edge Label Switch Router) où un calcul est effectué sur le datagramme afin de lui affecter un label spécifique. Ce qui est important ici, est que ce calcul n'est effectué qu'une fois. La première fois que le datagramme d'un flux arrive à un Ingress E-LSR. Ce label est supprimé à l'autre extrémité par le Egress E-LSR. Donc le mécanisme est le suivant: Le Ingress LSR (E-LSR) recoit les paquets IP, réalise une classification des paquets, y assigne un label et transmet les paquets labellisés au nuage MPLS. En se basant uniquement sur les labels, les LSR du nuage MPLS commutent les paquets labellisés jusqu'à l'Egress LSR qui supprime les labels et remet les paquets à leur destination finale.

L'affectation des étiquettes aux paquets dépend des groupes ou des classes de flux FEC (forwarding équivalence classes). Les paquets appartenant à une même classe FEC sont traités de la même manière. Le chemin établi par MPLS appelé LSP (Label Switched Path) est emprunté par tous les datagrammes de ce flux. L'étiquette est ajoutée entre la couche 2 et l'en-tête de la couche 3 (dans un environnement de paquets) ou dans le champ VPI/VCI (identificateur de chemin virtuel/identificateur de canal virtuel dans les réseaux ATM). Le switch LSR du nuage MPLS lit simplement les étiquettes, applique les services appropriés et redirige les paquets en fonction des étiquettes. Ce schéma de consultation et de transfert MPLS offre la possibilité de contrôler explicitement le routage en fonction des adresses source et destination, facilitant ainsi l'introduction de nouveaux services IP. Un flux MPLS est vu comme un flux de niveau 2.5 appartenant niveau 2 et niveau 3 du modèle de l'OSI.

6 - Label

Un label a une signification locale entre 2 LSR adjacents et mappe le flux de trafic entre le LSR amont et la LSR aval. A chaque bond le long du LSP, un label est utilisé pour chercher les informations de routage (next hop, lien de sortie, encapsulation, queueing et scheduling) et les actions à réaliser sur le label : insérer, changer ou retirer. La figure ci dessous, décrit la mise en oeuvre des labels dans les différentes technologies ATM, Frame Relay, PPP, Ethernet et HDLC. Pour les réseaux Ethernet, un champ appelé shim a été introduit entre la couche 2 et la couche 3. Sur 32 bits, il a une signification d'identificateur local d'une FEC. 20 bits contiennent le label, un champ de 3 bits appelé Classe of Service (CoS) sert actuellement pour la QoS, un bit S pour indiquer s'il y a empilement de labels et un dernier champ, le TTL sur 8 bits (même signification que pour IP). L'empilement des labels permet en particulier d'associer plusieurs contrats de service à un flux au cours de sa traversé du réseau MPLS.

7 - Implicit Routing (LDP)

La distribution implicite de labels aux LSR est réalisée grâce au protocole LDP (Label Distribution Protocol). LDP définit une suite de procédures et de messages utilisés par les LSR pour s'informer mutuellement du mapping entre les labels et le flux. Les labels sont spécifiés selon le chemin " Hop By Hop " défini par l'IGP (Interior Gateway Protocol) dans le réseau. Chaque noeud doit donc mettre en oeuvre un protocole de routage de niveau 3, et les décisions de routage sont prises indépendamment les unes des autres.



LDP est bi-directionnel et permet la découverte dynamique des noeuds adjacents grâce à des messages Hello échangés par UDP. Une fois que les 2 noeuds se sont découverts, ils établissent une session TCP qui agit comme un mécanisme de transport fiable des messages d'établissement de session TCP, des messages d'annonce de labels et des messages de notification.



LDP supporte les spécifications suivantes :

les labels sont assignés à un noeud amont à partir des informations contenues dans la table de routage:

3 FEC (Forwarding Equivalent Classes) sont définies : il est possible de mapper un label soit à un flux de trafic, à un préfixe d'adresse IP ou à un router-ID. Le flux de trafic reçoit le même traitement de forwarding selon le label qui lui est associé.

une connexion LDP peut être établie entre 2 LSR directement ou indirectement connectés

il existe 2 modes de rétention de label : soit " conservatif " soit " libéral ". Pour le mode de rétention " conservatif " , seul le label correspondant au meilleur bond est retenu. Par contre, pour le mode de rétention " libéral ", tous les labels transmis par les LSR adjacents pour un flux donné sont retenus. Ce mode permet un reroutage rapide en cas de problème car des labels alternatifs sont disponibles instantanément.

8 - Explicit Routing

L'Explicit Routing est la solution MPLS pour faire du Traffic Engineering dont l'objectif est le suivant :

utiliser efficacement des ressources du réseau

éviter les points de forte congestion en répartissant le trafic sur l'ensemble du réseau. En effet, le plus court chemin déterminé par le routage classique IP pour atteindre une destination peut ne pas être le seul chemin possible et certains chemins alternatifs peuvent être sous-utilisés alors que le plus court chemin est sur-utilisé.

Historiquement, le Traffic Engineering a été réalisé grâce à des métriques de liens associées à des protocoles de routage internes (RIP, OSPF, IS-IS). A la fin des années 90, il a également été possible de faire du Traffic Engineering avec des technologies de niveau 2 telles que ATM et Frame Relay. Aujourd'hui, MPLS émerge comme un nouveau mécanisme de Traffic Engineering en offrant une plus grande flexibilité de routage IP (bande passante, QoS,...), grâce à l'Explicit Routing. Dans ce cas, le LSP n'est plus déterminé à chaque bond comme pour l'implicit routing : c'est l'ingress node qui choisit le chemin de bout en bout. Au niveau des LSR en coeur de réseau, seul le label MPLS est analysé (pas l'en-tête du datagramme IP).



L'Explicit Routing permet à un opérateur de faire du Traffic Engineering en imposant au réseau des contraintes sur les flux, du point source jusqu'au point destination. Ainsi, des routes autres que le plus court chemin peuvent être utilisées. Le réseau détermine lui-même le chemin en suivant les étapes ci-dessous :

connaissance de l'état du réseau : topologie, bande passante réelle d'un lien, bande passante utilisée, bande passante restante. Des extensions ont été apportées aux protocoles de routage OSPF et IS-IS car la distribution dynamique des bases de données était limitée aux noeuds adjacents et à une seule métrique.

calcul d'un chemin répondant aux contraintes spécifiées. Les extensions d'OSPF et d'IS-IS sont nécessaires.

établissement du ER-LSP (Explicitly Routed Path). La source connaît le chemin complet de l'ingress node à l'egress node et c'est elle qui spécifie les LSR à l'intérieur du LSP. Deux options de signalisation spécifiées pour l'établissement du LSP : RSVP ou CR-LDP (Constraint-Based Routing LDP) :

CR-LDP est l'alternative à RSVP; il est jugé plus fiable dans la mesure où il met en oeuvre TCP (orienté connexion). De plus, CR-LDP peut interfonctionner avec LDP et utilise les messages LDP pour signaler les différentes contraintes. Les fonctions de CR-LDP sont réalisées par des instructions matérielles (asics) ne nécessitant pas de fréquents rafraîchissements, contrairement à RSVP dont les fonctions sont réalisées par le logiciel nécessitant de fréquents messages de rafraîchissement.

envoi du trafic sur le chemin trouvé

supervision de l'état des LSP et le transmet à l'IGP

ré-optimisation des LSP quand nécessaire

Les fonctions supportées par ER-LDP sont :

ER-LSP de bout en bout

strict/loose explicit routing : dans un LSP routé de manière " stricte ", chaque bond est spécifié. Une section du LSP peut être routée de manière " imprécise " lorsque sont introduits 2 LSR non directement connectés.

spécification d'une classe de service

réservation de bande passante

route pinning : dans une section de ER-LSP routée de manière " imprécise ", les bonds sont sélectionnés selon une transmission bond par bond

ER-LSP preemption : établissement/maintien de priorité

9 - Support de la QoS

9.1 - Signalisation et QoS

L'intérêt principal de MPLS est de permettre de se passer des couches inférieures ATM, Ethernet, PPP, Frame Relay et de fournir directement à la couche IP un mode connecté. Vu les similitudes qu'il y a entre traiter un " label " et traiter un champ VPI/VCI de cellule ATM, la majorité des premières implémentations réutilisent un coeur de commutateur ATM. De fait, pour les constructeurs d'équipements, il est relativement facile de transformer un commutateur PNNI/ATM, en commutateur/routeur MPLS/IP de coeur de réseau : ceci revient à remplacer la couche logicielle du plan de commande par une " couche logicielle MPLS ", c'est à dire remplacer PNNI Signalling par LDP (Label Distribution Protocol) et PNNI Routing par OSPF (ou IS-IS, etc.).

LDP est le protocole de signalisation qui permet d'affecter des labels à un chemin au sein d'un réseau. En ce sens, il correspond à un protocole de signalisation et d'un point de vue fonctionnel s'apparente à PNNI Signalling. Cependant, LDP ne contient pas de paramètres permettant de formuler une demande de ressources à l'établissement d'un LSP (même s'il est possible de demander un traitement spécifique pour tous les paquets empruntant un même LSP, selon le modèle DiffServ).

Deux approches ont été retenues à l'IETF pour permettre d'associer des ressources et de garantir de la QoS sur un LSP : CR-LDP pour Constraint based Routing LDP, définit des extensions à LDP, et RSVP-Tunnels, définit des extensions à RSVP pour la commande de LSP. L'IETF a décidé de ne pas trancher entre ces deux approches concurrentes et de laisser ce soin au marché. Elles permettent toutes les deux d'associer de la ressource à un LSP. La première peut le faire selon les deux modèles " QoS ATM " (catégorie de service, paramètres de trafic et de QoS), et " QoS IP " (modèle Intserv), alors que la deuxième permet essentiellement de la " QoS IP ".

Une utilisation combinée de LDP+CR-LDP, ou de RSVP-Tunnels permet donc d'établir des LSP en leur associant de la bande passante.

9.2 - Routage et QoS

Dans son expression la plus simple, MPLS utilise les fonctions de routage IP pour établir un LSP : le message d'établissement est alors routé comme le serait n'importe quel autre paquet IP contenant la même adresse destination. Dans ce cas, le routage se fait " hop by hop ", chaque routeur décidant par lui même de l'interface de sortie vers laquelle il envoie le message, indépendamment de ce que les routeurs précédent ont pu choisir. Ce mode de fonctionnement permet à un opérateur d'établir simplement un LSP entre deux extrémités de son réseau (pratique dans le cadre des VPNs). De plus, un tel mode de fonctionnement permet de sécuriser des LSP en autorisant leur reroutage en cas de faute dans le réseau (comme pour des Soft PVC en PNNI).

L'inconvénient d'un routage " hop by hop " dans un environnement dynamique est qu'il y a un risque de création de boucles. Le problème des boucles en MPLS a fait l'objet de divers documents, sans que de réelle solution soit trouvée : en routage " hop by hop ", on sait détecter des boucles, on ne sait pas les éviter complètement. Au cours de l'établissement, quand RSVP-Tunnels ou CR-LDP est utilisé, MPLS permet d'établir des LSP avec ressources associées, automatiquement à travers le réseau.

En MPLS, un LSP auquel on veut associer de la bande passante, s'il est routé via le protocole de routage IP, suivra la même route que n'importe quel autre LSP vers la même destination : la route qui minimise la somme des poids administratifs (seul paramètre déclaré par OSPF). Dans le cas de MPLS, les routeurs choisissent la route et vérifient a posteriori que la ressource nécessaire à l'établissement du LSP est effectivement présente sur cette route. La probabilité que la route retenue ne dispose pas de la ressource est plus importante en MPLS qu'en PNNI.

OSPF et IS-IS n'ont pas été définis pour router des trafics nécessitant un certain niveau de QoS, ou un minimum de bande passante. Ils ne fournissent donc pas à un routeur IP les informations dont celui-ci aurait besoin pour router un LSP en fonction de ce qui est signalé en RSVP-Tunnels ou CR-LDP. Pour surmonter ces insuffisances, des extensions ont été proposées pour OSPF et IS-IS (par exemple OSPF-TE: une extension au traffic engeneering ) pour leur permettre de diffuser au sein d'un réseau IP les informations de QoS dont les routeurs pourraient avoir besoin pour router des LSP.

9.3 - Architecture pour la QoS

Deux types d'architectures sont étudiées pour définir la QoS IP :

Integrated Services (IntServ)

Differential Services (DiffServ)

IntServ suppose que pour chaque flux demandant de la QoS, les ressources nécessaires sont réservées à chaque bond entre l'émetteur et le récepteur. IntServ requiert une signalisation de bout en bout, assurée par RSVP, et doit maintenir l'état de chaque flux (messages RSVP, classification, policing et scheduling par flux de niveau 4). IntServ permet donc une forte granularité de QoS par flux et pour cette raison, est plutôt destiné à être implémenté à l'accès.

IntServ définit 2 classes de services :

Guaranteed : garantie de bande passante, délai et pas de perte de trafic

Controlled Load : fournit différents niveaux de services en best effort

DiffServ, quant à lui, est davantage destiné à être appliqué en coeur de réseau opérateur. Les différents flux, classifiés selon des règles prédéfinies, sont agrégés selon un nombre limité de classes de services, ce qui permet de minimiser la signalisation. DiffServ ne peut pas offrir de QoS de bout en bout et a un comportement " Hop By Hop ".

DiffServ définit 2 classifications de service (Expedited, Assured) qui peuvent être corrélées aux classifications de service IntServ (Guaranteed, Controlled Load).

DiffServ utilse les 6 premiers bits du champ TOS de l'entête IP afin de classifier le trafic dans des classes ou contrats au niveau de l'Ingress-LSR. Ce champ s'appellera DS-Field dans DiffServ. Voir la comparaison dans les deux figures ci dessus entre ces deux champs. Au niveau des LSR, DiffServ définit des PHB (Per Hop Behaviors) afin de construire ces LSPs. Ainsi au niveau des Edges LSR, DiiServ utilise le champs DS-Field, et à l'intérieur du corps MPLS, il invoque les PHBs.





MPLS est amené à inter fonctionner avec DiffServ, car LDP supporte avant tout de la QoS à faible granularité.



IntServ et DiffServ sont donc 2 mécanismes complémentaires permettant d'établir une QoS consistante sur les réseaux MPLS et non MPLS.

10 - VPN

Définitions (RFC2547):

Deux sites distincts ont une connectivité IP sur le même backbone, seulement s'ils appartiennent à un même VPN sur ce backbone.

Deux sites qui ne sont pas dans le même backbone, n'ont aucune connectivité IP entre eux sur ce backbone.

Si tous les sites dans un VPN appartiennent à la même entreprise, alors il s'agit d'un intranet.

Si tous les sites dans un VPN appartiennent différentes entreprises, alors il s'agit d'un extranet.

Un site peut être dans plusieurs VPN: Dans un intranet et dans un, ou plusieurs extranets.

Les offres d'un service VPN IP répondent aux besoins des entreprises nécessitant:

Un service de réseau IP privé sur une infrastructure de réseau IP public.

Utilisant la couche réseau IP, niveau 3.

Une scalabilité aisée.

Possibilité d'utilisation d'un adressage privé sur un réseau public.

QoS.

Accès contrôlé et étanche vis à vis des autres flux sur l'infrastructure public.

Les informations de routage à l'intérieur d'un VPN sont distribuées de la manière suivante :

du site client vers le VBG (VPN Border Gateway) source : via RIP, OSPF ou en routage statique

au niveau du VBG source : exportation vers BGP

entre VBG source et VBG destination : via BGP

au niveau du VBG destination : importation à partir de BGP

du VBG destination vers le site client : via RIP, OSPF ou en routage statique

Le VBG source applique 2 labels au paquet de data lorsqu'un VPN est utilisé (Cisco utilse une autre methode: La VPN-IP@ = 96 bits: 64 bits identifiant le VPN et 32 bits de l'@ IP-V4 classique).

le premier label (extérieur) identifie le chemin vers le VBG destination, et change à chaque bond

le second label (intérieur) spécifie le VPN-ID attribué au VPN et n'est pas modifié entre le VBG source et le VBG destination

Cette paire de labels permet d'implémenter aisément les mécanismes des VPN dans MPLS:

11 - Traffic Engineering

Les motivations initiales pour la définition de l'architecture MPLS étaient de doter le monde IP d'un mode connecté et ainsi d'améliorer les performances des routeurs en traitant les paquets IP directement au niveau 2 (commutation) sans avoir à remonter systématiquement au niveau 3 (routage) à chaque bond. En effet, commuter un paquet IP à partir d'un " label " revient à utiliser le label entrant comme pointeur dans un tableau dont la case correspondante contient l'interface de sortie vers laquelle le paquet doit être envoyé, ainsi que le nouveau label à lui affecter. Une telle opération, qui correspond exactement au traitement du champ VPI/VCI d'une cellule entrant dans un commutateur ATM, est à priori beaucoup plus simple que l'opération classique de routage d'un paquet IP.

Ceci étant, les performances des routeurs IP étant devenues ce qu'elles sont, l'argument de l'augmentation des performances des commutateurs/routeurs MPLS/IP perd un peu de son intérêt : les algorithmes de routage de paquets les plus récents offrent des performances (en rapidité de traitement) quasi similaires à celles d'une simple opération de commutation. L'industrie a dès lors mis l'accent sur l'intérêt de MPLS comme outil permettant le " Traffic Engineering ".

Par " Traffic Engineering MPLS ", il faut comprendre, établissement de connexions " à la demande ", " gestion de trafic ", gestion des routes, gestion des ressources, gestion de l'écoulement de flux de trafic à travers un réseau IP. La possibilité de faire suivre à des paquets IP un chemin à travers le réseau ne correspondant pas forcément au chemin que ces mêmes paquets auraient suivi s'ils avaient été routés au niveau 3 (c'est à dire à partir des informations issues du protocole de routage interne du réseau, i.e. RIP, OSPF, IS-IS, EIGRP, etc.), ceci afin de mieux gérer les ressources du réseau ". En effet, via un Label Switched Path (LSP), MPLS permet d'imposer le chemin que les paquets IP doivent suivre pour atteindre une destination donnée. Un LSP est donc unidirectionnel.

MPLS et ses LSPs constituent dès lors un outil de gestion et d'optimisation de l'utilisation des ressources d'un réseau IP : les LSP sont montés par voie de gestion à l'avance par l'opérateur selon un chemin que celui-ci peut avoir préalablement choisi et déterminé....

Une utilisation " Traffic Engineering " de LSP MPLS s'apparente à la fonction Soft PVC unidirectionnel (contrairement à un LSP, un VC peut aussi être bidirectionnel) qui existe en commutation ATM. Pour établir un Soft PVC, l'opérateur se contente généralement d'identifier par voie de gestion les extrémités qu'il veut joindre. La connexion est ensuite établie automatiquement entre ces deux extrémités, la route que cette connexion suit à travers le réseau étant déterminée par les éléments de coeur de réseau. Dans le cas de PNNI, la spécification laisse le routage d'un Soft PVC sous la responsabilité des noeuds ATM. Ceci étant, la majorité des MIB propriétaires permettent à un opérateur de spécifier lui-même s'il le désire le chemin qu'un Soft PVC doit suivre à travers le réseau.

La principale différence entre un LSP MPLS et un Soft PVC ATM est qu'il est possible d'associer à un Soft PVC une catégorie de service ATM, ainsi que des paramètres de trafic et de QoS. Dans un réseau MPLS simple, établir des LSP revient alors à établir des Soft PVC UBR unidirectionnels : on marque un chemin à travers le réseau sans lui associer de ressources.

12 - Agrégation de flux

L'une des forces annoncées de MPLS est sa capacité d'agrégation de flux : la possibilité de réunir le trafic entrant dans un routeur via plusieurs LSP dans un seul et unique LSP sortant. Une telle configuration correspond à monter une connexion multi-point à point (fonction de VC merge en ATM), comparable à un arbre inversé dont le routeur de sortie serait la racine. Cette fonction permet de réduire au maximum le nombre de connexions que les routeurs de coeur de réseau ont à gérer.

Dans ce même but, MPLS introduit un concept de hiérarchie au niveau des LSP et d'empilement des labels. Il est donc possible de construire des LSP, encapsulés dans un autre LSP, lui-même encapsulé dans un LSP, etc. Ce concept d'encapsulation rappelle évidemment la possibilité en ATM de mettre des VC dans des VP. Cependant, en MPLS, le nombre de niveau d'encapsulation (ou de hiérarchie) n'est a priori pas limité à 2.

13 - Applications

Les applications les plus courantes du MPLS sont les suivantes :

L'ingénierie de trafic est activée par des mécanismes MPLS permettant de diriger le trafic via un chemin spécifique, qui n'est pas nécessairement le chemin le moins coûteux. Les administrateurs de réseau peuvent mettre en oeuvre des politiques visant à assurer une distribution optimale du trafic et à améliorer l'utilisation globale du réseau.

La bande passante garantie constitue une amélioration à forte valeur ajoutée par rapport aux mécanismes d'ingénierie de trafic traditionnels. MPLS permet aux fournisseurs de services d'allouer des largeurs de bande passante et des canaux garantis. La bande passante garantie permet également la comptabilité des ressources QoS (qualité de service) de manière à organiser le trafic 'prioritaire' et 'au mieux', tels que la voix et les données.

Le reroutage rapide permet une reprise très rapide après la défaillance d'une liaison ou d'un noeud. Une telle rapidité de reprise empêche l'interruption des applications utilisateur ainsi que toute perte de données.

Les réseaux privés virtuels MPLS simplifient considérablement le déploiement des services par rapport aux VPN IP traditionnels. Lorsque le nombre de routes et de clients augmente, les VPN MPLS peuvent facilement monter en charge, tout en offrant le même niveau de confidentialité que les technologies de niveau 2. Ils peuvent également transporter des adresses IP non-uniques à travers un domaine public.

La fonction Classe de service (CoS) MPLS assure que le trafic important est traité avec la priorité adéquate sur le réseau et que les exigences de latence sont respectées. Les mécanismes de qualité de service IP peuvent être mis en oeuvre de façon transparente dans un environnement MPLS.

14 - Discussion autour de la documentation

Vous pouvez poser toutes vos questions, vos remarques et vos expériences à propos de MPLS. Pour cela, rendez-vous sur le Forum "Les réseaux privées virtuels".

15 - Suivi du document

En 2001, par Benbella Benduduh et Jean Marc Fourcade, création du document.

Introduction to MPLS

MPLS in a Nutshell

Configure Cisco MPLS L3 VPNs

 

La grande mystification des Community Managers

Les Community Managers sont de plus en plus nombreux sur les réseaux sociaux. Depuis que les entreprises ont compris qu’elles devaient être présentes sur le Web pour maîtriser la communication autour de leur marque, elles embauchent ces gestionnaires de communauté pour relayer leur bonne parole. Sauf que personne ne les remet en cause… jusqu’à maintenant.

Les community managers ne rassemblent pas
Oui, ça peut surprendre, mais c’est la première des grandes mystifications des community managers. Ils ne rassemblent pas, ils divisent. Un bon community manager va cibler une population qui a les mêmes goûts ou qui partage les mêmes centres d’intérêt. Où est le rassemblement ? Ils mettent dans des groupes les blancs, les noirs, les homos, ceux qui aiment le Nutella, le Coca, le Japon ou le caca. Qu’ils le veuillent ou non, c’est exactement le contraire du rassemblement, c’est du communautarisme primaire.
Les communautés ne vous enrichissent pas
Lorsque vous rejoignez une communauté, dites-vous bien que vous n’allez pas vous enrichir. Bien sûr, vous allez pouvoir découvrir une recette au Nutella que vous ne ferez jamais. Mais en réalité, qu’allez-vous vraiment apprendre ? C’est un peu comme si vous alliez dans une manifestation contre la guerre et quand vous rencontrez une autre personne dans cette manifestation, vous lui dites : « Ah toi aussi tu es contre la guerre ? Moi aussi ». Ça vous fait une belle jambe, vous partagez le même point de vue. Mais qu’avez-vous appris ? Il n’y a pas de débat, pas d’enrichissement, pas de confrontation de point de vue. Tout le monde est d’accord pour avancer dans la même direction : celle que le community manager veut vous imposer. Le community manager veut que vous restiez entre vous, car c’est plus simple à gérer pour lui. Ne sortez pas du rang s’il vous plait, je ne veux pas voir une tête dépasser.
Les communautés vous bâillonnent et tuent Internet
Là encore, je vois des yeux qui s’écarquillent. Une voix dans votre tête dit : (lire avec l’accent bourguignon) « Comment ça ? Les communautés tuent Internet ? Il est pas bien celui-là ». Et pourtant, en rejoignant une communauté sur les réseaux sociaux, vous plantez un couteau dans le dos de l’Internet originel. Celui où Internet était un lieu ouvert et d’échanges. Car regardez un peu les communautés présentes sur les réseaux sociaux, il y a un community manager qui vous divertit et c’est tout. Vous, en tant que participant à cette communauté, vous avez le droit d’aimer ce que dit le community manager, de commenter et de partager ce qu’il dit. Vous n’êtes pas à l’origine des discussions. Le community Manager vous donne l’illusion que vous pouvez vous exprimer sans contrainte. Avant, il y avait des modérateurs, ils animaient les forums, supprimaient les commentaires qui ne respectaient pas la Nétiquette et rangeaient les discussions. Aujourd’hui, essayez de trouver une grosse communauté sur un réseau social où ce sont les fans qui lancent la majorité des sujets. Vous n’en trouverez pas. Pour la simple et bonne raison que la liberté d’expression dans les communautés sur les réseaux sociaux n’est qu’un écran de fumée. Le fan n’est pas là pour s’exprimer, mais il est là pour rendre virale la parole de l’entreprise. Ce n’est pas la fonction d’Internet, c’est la fonction d’un prospectus.
Que faire contre ce phénomène ?
Au risque de paraître paradoxal, pour lutter contre les communautés il faut les rejoindre. Inscrivez-vous dans un maximum de communautés mais uniquement dans celles avec lesquelles vous n’avez aucune affinité. Vous détestez le café ? Rejoignez la page Nespresso. Allez dire en commentaire que vous n’aimez pas le café, que leurs capsules sont polluantes, trop chères ou pas assez grosses. On s’en fiche. Lisez les commentaires, réagissez. Unissez-vous pour faire gonfler le chiffre d’une communauté et mettez vous d’accord pour la quitter tous en même temps quelques semaines plus tard. Mettez au point des méthodes aussi efficaces que celles utilisées par les Community Managers pour rendre viral leurs Jeux concours, leurs offres promotionnelles etc. Bref, prenez la parole, transformez les communautés en forum avec des voix divergentes, des engueulades, des blagues vaseuses, des détournements… Bref  de l’inattendu. Car franchement, cet Internet là est sans surprise et sans saveur. Est-ce vraiment ce que vous voulez ? N’oubliez que vous faites partie de ces communautés, que sans vous, elles n’existent pas. Et au final, si ces communautés sont sans intérêt, c’est de votre faute… et de la mienne.
Et comme je ne suis pas à un paradoxe près :

N’oubliez pas, vous pouvez suivre Gizmodo.fr sur les réseaux sociaux :  

Facebook, Twitter, Google+ !

Par Norédine, le 18 août 2012 à 15:56

Internet en 2002 et en 2012 : la comparaison

Quoi de mieux qu’un retour dans le temps en ce week-end ensoleillé ? Une infographie nous propose ainsi de jeter un oeil dans le rétro, en 2002, et de faire un état des lieux de l’Internet de l’époque !

Réalisée par Best Education Sites , l’infographie qui suit nous propose de comparer Internet sur plusieurs pans, entre l’année 2002 et l’année 2012. Bien entendu, entre ce lap de temps de 10 ans, les changements et les évolutions ont été nombreux. Par exemple, en 2002, les internautes n’étaient que 569 millions dans le monde. Aujourd’hui, ils sont 2.27 milliards. De la même façon, on parlait de 3 millions de sites en 2002, et de 555 millions en 2012.
Il ne faudrait pas non plus oublier qu’en 2002, Internet Explorer se taillait la part du lion avec ses 95% de parts de marché (sic !) !
Et là, on se sent vieux, d’un coup…

IBM serait prêt à racheter certaines activités de RIM

IBM se serait dit prêt à racheter le réseau de serveurs sécurisés qu'utilise le canadien pour ses terminaux. Et si une rumeur laissait entendre que Samsung et RIM collaboreraient pour le prochain OS du canadien, le sud-coréen a réfuté en bloc.

RIM est en grande difficulté. BlackBerry 10, sa planche de salut, est repoussé à l'année prochaine.

REUTERS/Mark Blinch

Le canadien RIM est en grande difficulté. A tel point que l'on peut se demander s'il parviendra à redresser la barre. Sur son premier trimestre décalé, le groupe a vendu 7,8 millions de smartphones, contre 11,1 millions un mois plus tôt. Sur le trimestre, le canadien a perdu 518 millions de dollars. Sans parler des milliers d'emplois supprimés.
>>> A lire : Cinq raisons de penser que RIM ne s'en sortira plus
En mai dernier, le groupe avait chargé deux banques d'affaires de le conseiller sur ses options stratégiques, ce qui avait définitivement lancé les rumeurs de partenariats, mais surtout de rachat. Parmi les plus persistantes, la reprise de la division smartphone par Facebook. Une rumeur qui ne s'est pas concrétisée. La firme a dans tous les cas indiqué qu'elle attendrait le déploiement de ses smartphones tournant sous son nouvel OS Blackberry 10 pour envisager une telle opération.
Mais RIM pourrait quand même se séparer de l'une de ses activités. L'américain IBM se serait positionné de façon informelle pour le rachat de son réseau de serveurs utilisé pour ses téléphones, a indiqué le site internet Bloomberg, sans dévoiler ses sources.
Les rumeurs se multiplient décidément pour le canadien. L'une des dernières en date, une possible collaboration avec Samsung pour l'élaborration du nouvel OS de RIM. Contacté par le site Cnet, Le sud coréen a néanmoins réfuté en bloc une telle démarche. "Samsung Electronics n'a pas considéré l'acquisition de RIM ou d'une licence BlackBerry 10". Difficile de faire plus concis.

Cloud computing et mobilité: consolider le réseau est prioritaire

Selon une étude de Forrester Research, consolider le réseau est un préalable prioritaire pour tous projets de Cloud computing, de mobilité ou de solutions analytiques.

Le 7 août 2012 par Pierre Mangin 0

Plus de la moitié des décisionnaires informatiques (54% en France) considèrent que le renforcement de leur infrastructure réseaux est un préalable incontournable et, donc, une priorité en termes d’investissement. Selon un rapport de Forrester en date du 2 août (sur la base d’un sondage Forrsights), « les investissements dans les réseaux sont la base des projets de Cloud computing, de mobiles et solutions analytiques. Ils s’avèrent nécessaires – sinon indispensables- pour faire de l’entreprise connectée une réalité ».
46% des décideurs interrogés (Europe et Amérique du Nord) déclarent que la consolidation est une de leurs premières priorités. En Europe, ce pourcentage est encore plus élevé, avec une moyenne de 50% de réponses similaires (54% pour la France, 48% pour le Royaume Uni et 47% pour l’Allemagne).

Le cloud, une réelle priorité

L'entreprise connectée améliore l'expérience des utilisateurs, clients, fournisseurs

Les équipements mobiles et l’administration des applications restent des étapes cruciales pour venir à «l’entreprise connectée», mais, un peu paradoxalement, seulement un tiers des responsables réseaux & télécoms considèrent les investissements y afférant comme stratégiquement importants.
L’enquête montre également que près de 40% des sondés, tous pays confondus, déclarent que déplacer les applications de communication vers le Cloud est une réelle priorité, et 25% prévoient d’adopter les « Communications-as-a-Service » (CaaS). Ce que l’on retient de ce sondage est qu’en France, à la deuxième question, le résultat est légèrement plus élevé, avec 32%.

La L4G LTE moins prioritaire que le Wifi

Améliorer et renforcer les capacités des réseaux sans fil est également une priorité. Mais la mise à disposition de la connectivité mobile 4G LTE n’est prioritaire que pour moins de 20% des entreprises interrogées. En Europe, le pourcentage tombe à 13%, car la connexion locale sans fil Wifi reste, de loin, le choix le plus prisé dans les entreprises : elle est citée comme très utile pour 85% des sondés.

La consolidation du réseau, une priorité pour les entreprises selon Forrester Research (08/2012)

«La mobilité, la connectivité intelligente et le réseau, ainsi que les modèles de cloud-as-a-service sont les grandes initiatives technologies que mobiliseront les directeurs des systèmes d’information, afin de mieux gérer les réseaux sociaux, de modifier l’expérience utilisateur, la « consumérisation », et les services ‘over-the-top’, souligne Dan Bieler, analyste chez Forrester Research, responsable de cette étude. Une entreprise connectée renforce profondément son propre réseau et ses outils de collaboration pour améliorer ses activités internes, centrées sur le client, ses relations commerciales et avec ses partenaires.»
La plupart des entreprises ont tout juste commencé à évaluer les multiples possibilités et le potentiel du modèle machine-to-machine (M2M), « qui est étroitement lié à la vision de l’entreprise connectée ». En Europe, 13% des sondés estiment que les initiatives M2M sont une stratégie télécom prioritaire (soit plus que dans le reste du monde : 11%).

Steve Wozniak voit l’avenir du cloud, et ce sera horrible !

Steve Wozniak, le co-fondateur d’Apple, ne voit pas le cloud et son avenir d’un très bon oeil. Plus précisément, il imagine déjà cet avenir. Et de son aveu, ce sera « horrible ».

Dropbox, iCloud, SkyDrive, Google Drive : à l’heure actuelle, nombreuses sont les solutions capables de stocker vos données dans le Cloud, ou plutôt, dans les nuages, en bon français. Ceci dit, cette technologie a beau avoir ses (nombreux) avantages, elle traîne également quelques boulets. Par exemple, le fait qu’elle soit en proie à des « chutes de tension », empêchant les utilisateurs d’avoir accès à leurs données un temps donné. Le dernier exemple marquant en date nous vient de chez microsoft, lorsque sa solution windows Azure tomba en rade 2 heures durant, laissant ses utilisateurs loin de leurs données.

Steve Wozniak voit d’ailleurs la chose arriver, et s’est exprimé sur le sujet il y a peu :

« Je m’inquiète vraiment du fait que toutes les données soient amenées à aller dans les nuages. Je pense que ça va mener à une situation horrible. Je pense que de nombreux problèmes vont apparaître dans les 5 années à venir. [...] Avec le cloud, rien ne vous appartient vraiment. Vous avez déjà tout délégué. [...] Plus nous allons envoyer des données sur la toile, et moins nous aurons de contrôle sur ces mêmes données. »

Partagez-vous cette manière de voir les choses ? Avez-vous déjà stocké vos données importantes dans les nuages ? Le cas Megaupload, sur l’impossibilité de récupérer ses données (légales, qui plus est…) vous a t-il échaudé sur la question ?