Affichage des articles dont le libellé est Cloud. Afficher tous les articles
Affichage des articles dont le libellé est Cloud. Afficher tous les articles

mercredi 2 juillet 2014

Un laptop à un euro pour bientôt?

Un modèle initié par les opérateurs téléphoniques

Mon premier téléphone portable (un sorte de grosse brique grise signée Bouygues Telecom) était onéreux à l'achat et s'accompagnait d'un forfait non moins onéreux.
Puis les opérateurs téléphoniques, sans doute soumis à un marché de plus en plus compétitif, firent progressivement évoluer leur modèle vers une approche où le coût du périphérique était absorbé par le prix de l'accès au service. On vit alors surgir des offres où, sous réserve d'engagement longue durée, on offrait un mobile d'entrée de gamme pour un euro symbolique.

La déclinaison sur les smartphones

Le marché des smart phones semble connaître aujourd'hui le même type de mutation avec des périphériques "low-cost" toujours plus puissants associés à des offres longue durée (24 mois en règle générale).

Le "cloud", nouveau champ de bataille

Bref, ce n'est plus le plus le matériel que l'on vent, mais le service et l'accès à celui-ci. Les grands acteurs - Apple, Google, Microsoft et bien d'autres - l'ont bien compris et ont déjà déplacé la ligne de front vers le "cloud".
Google et même allé plus loin, en proposant le ChromeBook, laptop "low-cost" nativement connecté et entièrement conçu autour de son offre de service.


Alors, à quand un laptop à 1€?

lundi 16 juin 2014

An end to end JavaScript application with Parse and Durandal

An end to end JavaScript application with Parse and Durandal

A little test of Parse Cloud code (see Parse documentation) along with DurandalJS framework (see website), i.e. jQuery, requireJS, KnockoutJS, SamyJS and so on...
So a full Javascript solution from back to front end with a little HTML5 / CSS (Bootstrap) on top.

First glance about Parse makes it very promising. It seems that Facebook and more recently Apple already understood it.

To be continued...

vendredi 9 mai 2014

Cloud computing : Microsoft is in da house

I recently played with Microsoft Azure and it clearly was impressive. Here below are some thoughts about it

Waouh effect

I tried the platform for almost 24 hours. During these three days, I was able to implement a small cloud infrastructure with:
- on network (Burgundy) with its own DNS and Active Directory server (Vougeot)
- a SQL Server 2008 R2 server (Pommard)
- a Sharepoint 2013 server (Gevrey)


Tested infrastructure



I am clearly not an OS nor a network engineer, but I did it quite easily using standard virtual machines provisioned on Azure.
Why three days? mainly because I passed half of my time configuring my SharePoint site and browse trough the different pages offered by Azure administration tool to discover the platform capacities.

By the way, what about the administration tool? I would say that it took me 1 hour, no more, to discover it by myself and understand the main principles of it. A great work has been done here to simplify the administration and make it as simple as possible.

I used Google App engine some months ago, and clearly, it was not as mature as Azure is, proposing a set of services to host application in an PaaS approach, but having impact on produced code.
I use a bit iCloud from Apple but it is mainly a SaaS approach with a continuous approach between device software and cloud storage.
Microsoft on its side propose a global approach, with provision of hardware and software, on a transparent and global approach.

So yes, Azure clearly does the "Waouh effect". If you want to check, just do it. It's free.

Free, you said?

Yes, the trial is free. You get 150€ of service credit and a 30-days limit to use it. Mine was used in 3 days, due to the SQL Server resource that was costing a lot.

Cost repartition


As you can see above, SQL server service represent around 70% of global cost. This is mainly due to the fact that SharePoint is particularly greedy in SQL transactions and as I played a lot with it in order to obtain the configuration I wanted, it costed me a big part of my credit.

Having seen that, a proper alternative may be SharePoint online, but I didn't had the opportunity to test it yet.


lundi 14 avril 2014

The Holy Grail: How to develop seamlessly in the cloud | VentureBeat |Cloud | by Jay Simons

http://venturebeat.com/2012/10/31/the-holy-grail-how-to-develop-seamlessly-in-the-cloud/

In this article, the author provide very concrete information to build quickly and for an affordable price a complete development (and running) platform. Quite interesting as soon as you see cloud as the future toolset for development team.
I would have added Microsoft Azure to the panel of solutions presented here.

samedi 21 septembre 2013

A quick return of experience on Google App Engine

English: Architecture of the Google App Engine...

Architecture of the Google App Engine. (Photo credit: Wikipedia)

Offers on cloud computing are growing faster nowadays. In this article, I propose to have a look on Google with its Google App Engine platform (GAE) that I had the opportunity to use recently.

GAE was first released in April 2008 and is based on a Python web-server. The offer consists of
an out-of-the-box application platform including a development kit, an application server, a non-relational data store as well as a huge bunch of web-services that can be used freely or through a pay-per-use scheme.

Provided with the standard GAE plateform is a no-SQL database accessible through either Java or Python API (this last one being apparently the preferred one for the access to the data store)

GAE pricing model follows a pay-per-use scheme with a free start and fees to pay when quotas are reached.
In the same way, used services (search, geolocalization...) are available through a pay-per-use scheme with a free start for non professional use.

I tried Google App Engine with Java recently and was quite satisfied with the whole ecosystem. In order to access to the database, I also add the ORM Objectify that greatly accelerated my development.
I particularly liked the integration with Eclipse, which is the Java IDE that I use. The data store use was a bit weird for me as the beginning and I had to change my relational schemes way-of-thinking.

The only point I may raised would concern the migration of the hosting of the application from the GAE environment to an other one (for instance not submitted to Patriot Act). But this will be another story...

samedi 31 août 2013

Résistance dans les nuages

English: Diagram showing overview of cloud com...
Diagram showing overview of cloud computing including Google, Salesforce, Amazon, Axios Systems, Microsoft, Yahoo & Zoho (Photo credit: Wikipedia)

Résistances au changement rencontrés sur des solutions à base de "cloud computing"

Taxonomie du "cloud computing"

On distingue à ce jour trois principales typologies dans le paradigme "cloud computing" allant de la partie la plus basse d'une architecture (IaaS - Infrastructure as a service) en passant par la notion de plateforme technique (PaaS - Platform as a service) et jusqu'à la partie la plus haute (SaaS - Software as a service). Quelque soit le niveau considéré, j'observe de fortes résistances au changement dans l'adoption de ces nouveaux concepts d'architecture que j'attribue à plusieurs facteurs décrits succinctement ci-dessous.

Confidentialité des données

Parmi les différentes réticences que je rencontre vis-a-vis d'une architecture basée sur du "cloud computing", la question de la confidentialité des données se trouve fréquemment au centre du débat.
Il est bien compréhensible que l'éventualité d'héberger chez un fournisseur externe à l'entreprise les données stratégiques (portefeuille client, documents de toutes sorte - de la présentation en clientèle en passant par les contrats ou les documents juridiques) puisse constituer un sujet de préoccupation majeure des décideurs de l'entreprise auquel les acteurs du "cloud computing" tentent de répondre par différentes certifications toutes plus "ISO" les unes que les autres.

Pour ce qui me concerne, j'observe que de nombreuses entreprises ont hébergé depuis des années leurs données sensibles dans des centres d'hébergement externes sans pour autant s'inquiéter de l'accessibilité à ces données par les équipes de production, par nature externes à l'entreprise cliente.

Dans le cas du modèle SaaS, si la confidentialité s'avère être un pré-requis fort, je suggèrerai alors de traiter ce sujet à l'aide de systèmes de cryptage des données stockées au niveau des applications clientes de manière a assurer l'accès aux informations au seuls utilisateurs ayant les habilitations nécessaires et suffisantes.
Ce modèle peut fonctionner des lors que l'intranet de l'entreprise est à l'origine des données sensibles. Celles-ci sont alors générées, puis cryptées localement puis transmises ensuite a la plateforme "cloud computing".

A l'inverse, à l'extraction des données, celles-ci sont récupérées localement puis décryptées.
On comprend des lors tout l'intérêt d'une solution SaaS proposant une interface de service riche permettant une personnalisation des services d'accès au données et par là-même la mise en oeuvre de cette mécanique de façon transparente pour l'utilisateur.

Dépendance envers le fournisseur

L'utilisation d'un mode "cloud computing" induit par essence une dépendance envers le fournisseur de service.
Cette dépendance n'est en aucun cas un facteur propre au "cloud computing" et à ce titre doit être gouvernée de la même manière que pour tout autre fournisseur de service. En conséquence, celui-ci doit être scrupuleusement sélectionné suivant des critères:
  • Techniques (pertinence de la solution)
  • Économiques (pérennité de l'entreprise)
  • Contractuels (SLA, pénalités, conditions de retrait)
On comprend bien entendu que le troisième point est essentiel dans le cadre d'une architecture utilisant des services "cloud computing", et il convient de prendre en compte dès l'origine l'ensemble du cycle de vie de la solution conçue:
  1. La mise en oeuvre de la solution, en spécifiant les responsabilités de chacun, en particulier en ce qui concerne la qualité de service attendues, qui induira directement le SLA mis en oeuvre dans le cadre de la solution.
  2. Le fonctionnement courant de la solution avec les rapports attendus en regard du SLA établi et les pénalités induites en cas de non respect de la qualité de service contractualisée.
  3. Les conditions de mise en oeuvre du décommissionement de la solution, prenant en compte la reprise des données sous un format utilisable par le client (donc potentiellement plus fonctionnel que technique en terme de normalisation).

Changement d'un modèle "build" en modèle "buy"

Ce troisième point est vraisemblablement l'un des facteurs de résistance majeur que j'ai eu l'occasion de rencontrer.
Face à des équipes constituées incluant des techniciens aguerris ayant produit et maintenu dans le passé des systèmes ayant fait leur preuve, il est délicat de convaincre que la plus-value de ces équipes dans le futur sera mesurée sur la capacité, non plus à construire et à maintenir, mais sélectionner, contractualiser, mesurer et dans une plus large optique gouverner la relation à leur fournisseur.
Pour autant, il ne faut pas y voir à mon sens la mort de la compétence technique mais plutôt sa transformation, celle-ci restant essentielle à l'achèvement des taches cites plus haut.

De la même façon que l'imprimeur n'a pas besoin de connaitre en détail le processus de fabrication du papier pour gérer ses fournisseurs, son métier requiert de lui qu'il connaisse les différents types de papier ainsi que le celui qui convient à son besoin.
La difficulté qui apparait dès lors que l'on essaie de mettre en oeuvre une architecture basée sur des solutions de type "cloud computing" est de pouvoir répondre à des questions du type:
  • Pourquoi acheter chez quelqu'un d'autre ce que l'on peut faire en quelques jours en interne?
  • Pourquoi donner un revenu récurrent à une société externe plutôt que construire une solution interne?
A la première question je répondrai principalement que l'objectif est:
  1. De s'appuyer sur une expérience externe dans des domaines qui ne sont pas le coeur de métier de l'entreprise.
  2. De s'assurer d'une capacité de maintenance et d'évolution des services achetés en dehors des capacités d'investissement de l'entreprise.
A la seconde, qu'il convient de prendre en compte l'ensemble des coûts d'une solution construite en interne, c'est à dire en particulier:
  1. Les coûts de construction;
  2. Les coûts de maintenance;
  3. Les couts d'hébergement;
  4. Les coûts de décommissionnement de la solution.

Conclusion

Je ne sais pas dire à ce jour si le "cloud computing" est la panacée en matière d'architecture de système. J'observe simplement que bon nombre de réticences rencontrées habituellement ne me paraissent pas réellement fondées des lors que l'on accepte les transformations inhérentes à ce modèle.
Pour ma part, j'utilise des services de ce type depuis bien longtemps à titre personnel. Google Doc, Cavus vinifera (pour les oenophiles), Flickr et autres dropbox ne sont finalement que des appendices virtuels de mon ordinateur / réseau personnel.

Related articles

Impact organisationnel du "cloud computing"

De l'architecture à la gouvernance

Alors que l'architecture d'entreprise commence tout juste à s'imposer au sein des directions informatiques des grandes entreprises, celle-ci voit, avec l'arrivée du "cloud computing", ses missions muter de façon fondamentale.
Historiquement fournisseur de services IT au sein de l'entreprise, les directions informatiques ont de plus en plus un rôle de garant du bon usage des ressources budgétaires IT en regard des objectifs stratégiques de l'entreprise. Avec l'arrivée des modèles SaaS, IaaS et autres composants du "cloud computing", il est désormais indispensable de prendre en compte dans les équations de ROI les hypothèses d'achat de prestations de services IT au même titre que ce qui est effectué dans d'autres domaines support (logistique par exemple). Autrement dit, pourquoi construire en interne ce que d'autres font mieux et depuis plus longtemps?

Avec l'arrivée du "cloud computing", le rôle de l'architecte d'entreprise ne se cantonne plus des lors à concevoir des solutions "in-house", mais également de comprendre au plus près le besoin utilisateur afin de sélectionner les meilleures alternatives du marché en termes d'offre de services, de plateforme ou même d'hébergement. Ce choix doit non seulement prendre en compte des besoins fonctionnels, mais également non fonctionnels: (disponibilité, performances, ergonomie, stabilité...) qui devront se traduire par l'établissement d'un SLA dont les termes devront être mesurables et potentiellement soumis à pénalités en cas de non respect.

De fournisseur de service support, l'architecte d'entreprise - tout en restant le garant des services rendus - se place par conséquent en tant que consommateur, voire acheteur et ne peut par conséquent faire l'impasse sur les aspects contractuels qui le lient à ses fournisseurs.

Par ailleurs, en tant que garant de la bonne allocation budgétaire des services IT, ils se doit de se pencher de près sur les ROI des services consommés afin de détecter les sources d'économie potentielles pour l'entreprise par une baisse de niveau de service requis (SLA moins onéreux) voire la remise en cause des fonctionnalités fournies lorsque celles-ci présentent un coût trop élevé vis-à-vis du gain métier escompté.

La notion de cloud computing allant de paire avec un modèle économique à coût récurrent pour l'entreprise, la notion de ROI devient critique. En effet, on considère généralement dans une approche "in-house", le modèle économique est essentiellement constitué des coûts d'acquisition et des couts de maintenance (de l'ordre de 15% du cout d'acquisition en annuel). Le modèle en "cloud computing" est pour sa part bien souvent linéaire dès le départ ce qui amène a un point d'équilibre (entre l'année 3 et 4 sur le diagramme ci- dessous) qu'il convient de connaître au plus tôt afin de négocier au mieux les coûts d'une solution SaaS ainsi que les conditions de sortie.

On le voit, au delà des connaissances techniques essentielles de l'architecte d'entreprise, l'apparition sur le marché d'offres de services à tous les niveaux de l'architecture amène ce dernier à se pencher sur des problématiques qui relevaient jusqu'alors plus de la gouvernance IT que du pur cadre technique.

Related articles