Author: Rene Buest

Rene Buest is Gartner Analyst covering Infrastructure Services & Digital Operations. Prior to that he was Director of Technology Research at Arago, Senior Analyst and Cloud Practice Lead at Crisp Research, Principal Analyst at New Age Disruption and member of the worldwide Gigaom Research Analyst Network. Rene is considered as top cloud computing analyst in Germany and one of the worldwide top analysts in this area. In addition, he is one of the world’s top cloud computing influencers and belongs to the top 100 cloud computing experts on Twitter and Google+. Since the mid-90s he is focused on the strategic use of information technology in businesses and the IT impact on our society as well as disruptive technologies.

Rene Buest is the author of numerous professional technology articles. He regularly writes for well-known IT publications like Computerwoche, CIO Magazin, LANline as well as Silicon.de and is cited in German and international media – including New York Times, Forbes Magazin, Handelsblatt, Frankfurter Allgemeine Zeitung, Wirtschaftswoche, Computerwoche, CIO, Manager Magazin and Harvard Business Manager. Furthermore Rene Buest is speaker and participant of experts rounds. He is founder of CloudUser.de and writes about cloud computing, IT infrastructure, technologies, management and strategies. He holds a diploma in computer engineering from the Hochschule Bremen (Dipl.-Informatiker (FH)) as well as a M.Sc. in IT-Management and Information Systems from the FHDW Paderborn.

Categories
Services @de

Open-Xchange: Die gehostete Alternative zu Google Apps und Microsoft Office 365

Open-Xchange hat heute seine erste eigene Cloud-basierte Office-Suite vorgestellt. Die erste App “OX Text” aus der Office Productivity Suite soll planmäßig Anfang April bereitstehen. Damit lassen sich künftig Microsoft Word .docx- und OpenOffice/LibreOffice .odt-Dateien direkt im Browser bearbeiten. Die gemeinsame Arbeit an einem Dokument wird über ein Token gelöst, das herumgereicht wird. Das bedeutet, dass nicht parallel an einem Dokument gearbeitet werden kann, alle Änderungen bei allen Teilnehmern aber in Echtzeit angezeigt werden.

Sehr gut gelöst: Formatierungen bleiben erhalten

Hat man ein Dokument mit Microsoft Office erstellt und will es später mit OpenOffice oder auch Google Docs weiter bearbeiten steht man vor einem nicht zu unterschätzenden Problem. Meistens ist die vollständige Formatierung der DOC-Datei hinüber, sobald man sie in einem MS Office fremden Produkt öffnet. OX Text geht hier einen prinzipiell einfachen aber dennoch innovativen Weg. Es lassen sich .docx- und .odt-Dateien im Browser lesen und editieren, ohne das diese konvertiert werden. OX Text speichert nur die Änderungen und nicht das gesamte Dokument. Dadurch bleiben Formatierungen und Layout des ursprünglichen Dokumentes vollständig erhalten.

Alle Formatierungen des ursprünglichen Dokumentes bleiben während der Bearbeitung unangetastet. Auch Elemente, die OX Text nicht kennt und bearbeiten kann, wie z.B. WordArt-Effekte, werden nicht verändert. Der OX Text Editor bietet nur die Funktionen zur Bearbeitung an, die das Layout des Ausgangsdokumentes nicht kompromittieren. Dadurch stellt OX Text sicher, dass das Layout des ursprünglichen Dokumentes erhalten bleibt.

Parallel wird der OX Document Viewer veröffentlicht. Damit können Anwender Text- und .pdf-Dateien, Tabellenkalkulationen und Präsentationen im Browser lesen, ohne dass sie die entsprechenden Dateien dafür auf ihr Endgerät herunterladen müssen. Abgerundet wird der Funktionsumfang von OX Documents durch Online-Werkzeuge zur Bearbeitung von Tabellenkalkulationen und Präsentationen, OX Spreadsheet und OX Presentation, die noch in diesem Jahr fertig werden sollen.

OX Documents = OpenOffice in der Cloud

Ich warte schon lange auf ein OpenOffice aus der Cloud. Nun ist es im Prinzip soweit. Open-Xchange selbst bezeichnet OX Documents als Web-Nachfolger von OpenOffice, da es von Mitgliedern des ehemaligen OpenOffice-Teams in Hamburg entwickelt wird und die seit einem Jahr Bestandteil der OX-Entwicklungsmannschaft sind.

Eigenständig oder in der Suite

OX Documents ist als eigenständiges Produkt oder als Erweiterung von OX App Suite erhältlich. Der von Open-Xchange im Februar veröffentlichente browser-basierte Desktop OX App Suite umfasst Apps zur Bearbeitung von E-Mails, Terminen, und Kontakten, die um Nachrichten und Informationen aus sozialen Netzwerken wie Facebook, LinkedIn, XING und Twitter ergänzt werden können. Komplettiert wird der Funktionsumfang von OX App Suite mit einer Dateiverwaltung für Bilder-, Audio-, Video- und Office-Dateien.

Für OX App Suite hat Open-Xchange eine komplett neue, web-basierte Benutzeroberfläche entwickelt. Anwender können OX App Suite sofort und mit jedem Endgerät nutzen, das einen Browser hat – ohne dass sie dazu Lizenzen kaufen oder Software installieren müssen. Bei Verlust oder Defekt eines Gerätes sind alle Dateien zentral gesichert.

Unterschiedliche Endgeräte eine Lösung

Auf Basis des “Responsive Design” passt sich OX App Suite automatisch an die unterschiedlichen Display-Größen von PC, Laptop, Tablet und Smartphone an, was auf jedem Gerät eine bestmögliche Benutzbarkeit ermöglicht. Und durch
konsequente Nutzung des “Local Storage” aktueller Browser mittels HTML5 und Javascript steht OX App Suite der Performance traditioneller Client-Server-Software in nichts nach.

Cloud und Lokal

OX App Suite und OX Documents sind Online- und Offline-fähig. Das heißt, dass angefangene E-Mails und Dokumente auch dann nicht verloren gehen, wenn die Internetverbindung – beispielsweise im Zug – abbricht. Bei der nächsten Verbindung werden die Änderungen automatisch übertragen.

Kommentar: Google Apps und Microsoft Office 365 sollten sich warm anziehen

Ich hatte auf der CeBIT die Gelegenheit ausführlich, inkl. Showcase der neuen Funktionen, mit Open-Xchange CEO Rafael Laguna zu sprechen. Daher kann ich alle oben genannten Möglichkeiten bestätigen.

Besonders überzeugt hat mich der Umgang mit der Formatierung importierter Dokumente und die Möglichkeiten des Workflows sämtlicher Dokumente. Im ersten Moment klingt diese neue Funktion sehr simple. Wenn man jedoch überlegt, dass alle Lösungen am Markt Probleme damit haben, Microsoft Office Dateien sauber zu verarbeiten, ist das keine Magie. Das hängt grundsätzlich damit zusammen, dass Microsoft Office x Funktionen und Formatierungen abbildet. Um ein Dokumente 1:1 zu laden, bearbeiten und wieder speichern zu können, müssen also exakt diese Funktionen nachprogrammiert werden. Das rentiert sich im Normalfall jedoch nicht. Open-Xchange hat sich dafür entschieden, ausgewählte Standard-Funktionen zu unterstützen und alles was nicht bekannt ist, wie z.B. WordArt oder spezielle Formatierungen durch einen Platzhalter zu ersetzen, der nicht verändert werden kann.

Was Google Docs von anderen Cloud Kollaborationslösungen abhebt, ist die Möglichkeit, mit mehreren Leuten parallel an einem Dokument zu bearbeiten. Open-Xchange hat sich hier gegen das parallele Bearbeiten und für die Token-Methode entschieden, da eine Umfrage innerhalb der Zielgruppe zu dem Ergebnis gekommen ist, dass daran kein Interesse besteht. Ich finde das ein wenig schade, da ich mit der parallelen Bearbeitung von Dokumenten in Projekten bisher sehr gute Erfahrungen gemacht habe. Das Dokument ist sehr viel schneller fertiggestellt.

Gut gelöst ist auch der Workflow mit Dokumenten. Bekommt man z.B. eine Datei per E-Mail, lässt sich diese von dort direkt öffnen, bearbeiten und nach dem Speichern wieder direkt verändert an den ursprünglichen Absender zurückschicken. Open-Xchange erlaubt dazu das Verschicken der physischen Datei als auch nur einen Link zu dieser Datei.

Lagunas Argumentation, dass proprietäre Dateiformate der falsche Weg sind, weil sie eine Zusammenarbeit erschweren und die Anwender zudem wieder an die Nutzung einer bestimmten Applikationen ketten, kann ich nur bedingt zustimmen. Richtig ist, dass proprietäre Dateiformate den Nutzer dazu zwingen, eine bestimmte Anwendung zu nutzen. Jedoch werden wir das noch eine ganze Weile benötigen. Denn aktuell sind wir noch weit davon entfernt, dass der Browser das Betriebssystem wird und wir darüber alle unsere Daten bearbeiten und speichern. Es wird immer eine hybride Form geben müssen, wodurch auch Daten auf ein lokales System heruntergeladen werden. Das geht in der Regel nur mit einem bestimmten Dateiformat, dass in irgendeiner Form proprietär ist. Sei es nun aus der Open-Source Welt oder von Anbietern wie Microsoft. Schließlich muss Open-Xchange seine Daten auch in einem Datenformat freigeben, wenn der Anwender wechseln möchte.

Open-Xchange ist eine ernsthafte Alternative

Nicht nur an der Integration zwischen E-Mail und Docs App sieht man, dass sich Open-Xchange von einer E-Mail Lösung zu einer ernsthaften Kollaborationslösung und Alternative zu Platzhirschen wie Google Apps und Microsoft Office 365 entwickeln wird. Neben dem stetig wachsenden Funktionsumfang bietet Open-Xchange zudem mittlerweile ein sehr schickes Look and Feel, was man für die tägliche Arbeit nicht unterschätzen sollte.

Open-Xchange ist für alle interessant, die Google Apps oder Microsoft Office 365 nicht trauen, lieber einen Anbieter mit einem Rechenzentrum in Deutschland haben möchten oder doch lieber alles selbst machen. Eine hohe Verbreitung hat bzw. bekommt Open-Xchange durch eine kommerzielle White-Label Lizenz an Hosting- und Telekommunikationsanbieter, die ihren Kunden OX App Suite damit als Software-as-a-Service (SaaS) anbieten können. Weiterhin richtet sich die Lösung an Systemintegratoren und VARs, die OX App Suite als Managed Service oder für Inhouse-Installationen nutzen wollen.

Welche Verfügbarkeit ist erwünscht

Um Open-Xchange einzusetzen stehen drei Varianten zur Verfügung.

Als Software-as-a-Service (SaaS) von einem Webhoster

Dabei handelt sich um die eleganteste und einfachste Möglichkeit. Die meisten großen deutschen Webhoster setzen als White-Label im Hintergrund auf Open-Xchange. Hat man dort bereits einen Tarif inkl. Webmail, stehen die Chancen gut, dass man derzeit schon eine ältere Version von Open-Xchange nutzt. Der grundsätzliche Vorteil, Open-Xchange über einen Webhoster zu nutzen ist der Umstand, sich nicht selbst um den Betrieb, die Wartung und Aktualisierung der Software und der dafür benötigten Infrastruktur zu kümmern. Außerdem stehen die Server bereits im Internet, was den überall Zugriff auf die Daten erleichtert.

Selbst bei einem Webhoster betreiben

Natürlich kann man Open-Xchange auch selbst bei einem Webhoster auf einem Server betreiben. Aber Vorsicht, um die Verfügbarkeit von Google Apps oder Microsoft Office 365 zu erhalten, reicht es bei weitem nicht aus, sich einfach nur einen virtuellen Server aufzusetzen. Da sollte man sich eher Gedanken über die Hochverfügbarkeit machen, die Open-Xchange selbst nicht mitliefert. OX ist an dieser Stelle einfach nur ein Stück Software. Für Hochverfügbarkeit sorgen dann wiederum Infrastructure-as-a-Service (IaaS) Lösungen wie openQRM oder auch OpenStack. Aber bitte nicht vergessen: IaaS bedeutet Infrastruktur = u.a. Hardware die für die entsprechende Virtualisierung. Zudem reicht ein Server bei weitem nicht, um die Verfügbarkeit und Eigenschaften einer Cloud zu erreichen.

Privat auf eigenen Servern

Auch die Installation im eigenen Rechenzentrum ist eine Variante. Dabei gilt jedoch dasselbe wie bei dem Betrieb beim Webhoster. Ein Server reicht für die Ansprüche an ein Hochverfügbarkeits- oder gar Cloud-Szenario nicht aus. Auch hier sollte man sich dann darauf konzentrieren, zunächst eine Cloud Infrastruktur auf Basis von openQRM oder OpenStack aufzubauen, auf der dann Open-Xchange betrieben wird. Vernachlässigen sollte man aber auch nicht, dass Open-Xchange eine Kollaborationsumgebung ist. Das bedeutet der überall Zugriff auf die OX Installation ist zwingend erforderlich, was auch Auswirkungen auf die Bandbreite der jeweiligen Internetanbindung, bevorzugt den Upload, hat.

Categories
Comment

Stop talking about cloud vendor lock-in, because actually we all love him

A popular cloud computing discussion is the vendor lock-in. The dependence on one vendor which is so large that the change in the current situation is too uneconomical due to high switching costs. I had such a discussion recently during a panel and would like to describe my general attitude about vendor lock-in. Because I think that a lock-in is necessarily not a bad thing. Actually, we love him. But, we mostly do not realize it. Moreover, we live for decades with him and each of us even every day. A lock-in is unavoidable, it is always there!

The daily lock-in

A good example is IKEA. Our apartment is made up of furniture from IKEA – up to the kitchen. Why? Because it looks good, fits perfectly together AND combining with furniture from other vendors is tough. And? We think it’s great because it does it’s job, but above all it fulfills our requirements. Analogous to IT it means that companies engage consciously on a supposed lock-in with SAP, Microsoft, Oracle and other vendors, because they need it and the vendors meet the requirements as far as possible. One only considers how many companies have adapted to SAP and not the other way around. Because initially there were no alternatives and because SAP met the required functions for the daily business.

The paragon of a lock-in is the iPhone/ iPad. And? Right, all love him! Because the iPhone “raises” the own coolness factor and also brings the functions so many need, even if they do not even know it before. Except for the coolness factor it’s the same for Android. One may argue that Android is open source and thus the freedom is finally greater. On the one hand this is true. And for the individual it’s possible to keep the change in check. From the perspective of a company it looks very different. Here the lock-in is comparable with an iPhone/ iPad, just in the Google universe.

No vendor lock-in is a pure marketing promise

It’s similarly in the cloud and here specifically with OpenStack. Rackspace is the loudhailer of the OpenStack community. The provider argued that it’s easier to go back into the own private cloud infrastructure if an enterprise depends on a public cloud provider who relies on OpenStack. And of course Rackspace delivers an own OpenStack private cloud distribution. At the end Rackspace earns with consulting and other services. Rackspace’s argument is correct, but rather to understand at the marketing level. Because even a vendor like Microsoft, with its Windows Server 2012, gives the ability to leave Azure and go back into the own infrastructure. And you can also free yourself from the Amazon Web Services (AWS) if you own your own Eucalyptus cloud. Although, Eucalyptus is still far away from providing all the services of AWS, but that will happen over time. I also continue to believe that Amazon will buy Eucalyptus sooner or later.

So, even with OpenStack you enter a lock-in. Although they talk about open standards and APIs. But in the end you will also be caught in the OpenStack ecosystem. This means that you can easily switch to another provider who supports OpenStack. But the topic Openness is here rather used as a marketing tool. After all, OpenStack and other commercial open source associations are no fun events. It’s about tough business. At the end OpenStack makes it only easier to change between the various providers that also rely on OpenStack. But, since all the vendors set up virtually on the same technology and distinguish themselves only through value-added services, you have the OpenStack technology lock-in. (Yes, of course it is possible to build your own OpenStack cloud regardless of a provider. But the (financial) burden is out of proportion to the later benefit.)

A lock-in offers more advantages than you think

A lock-in offers several advantages. He creates innovations that one as an alleged “slave” participates from. The vendors constantly roll out improvements from which we benefit. And, the lock-in is good, as long as he just does the job that is expected. If the solution meets the requirements everything is great! As a company, after the decision for a provider, you admit to the lock-in deliberately. On-premise one has engaged for years in a lock-in. Certainly one does not quite agree with one or the other function, but on the whole, one is happy, because the problems are solved and the needs are met. And, as a company in the cloud you take a not insignificant sum of funds in your hand. These investments have to pay first before you think about switching back. One should not be forgotten. If another provider wants to break a company free from an existing provider, it will do everything possible, to enable this path. So, before you get too worried about a lock-in, it’s advisable to look first how future proof are the services and the cloud provider itself and include it in a possible exit strategy.

Conclusion: We live constantly with a lock-in. This can never be completely avoided, and just keep up to very low. A lock-in is somewhat more flexible than the other, but the decision for one remains. Indisputable, we love him, the lock-in!

Categories
Kommentar

Die Cloud Vendor Lock-in Diskussion ist überflüssig, denn eigentlich lieben wir ihn alle

Eine beliebte Cloud Computing Diskussion ist der Vendor Lock-in. Die Abhängigkeit von einem Anbieter die so groß ist, dass sich die Änderung der aktuellen Situation aufgrund zu hoher Wechselkosten als unwirtschaftlich gestaltet. Ich hatte so eine Diskussion erst kürzlich wieder während eines Panels und möchte hier mal meine grundsätzliche Einstellung zum Thema Vendor Lock-in schildern. Denn meiner Ansicht nach ist ein Lock-in zwangsläufig nichts Schlechtes. Eigentlich lieben wir ihn. Uns ist es meistens nur nicht bewusst. Darüber hinaus leben wir seit Jahrzehnten und jeder von uns sogar tagtäglich damit. Ein Lock-in ist nicht zu umgehen, er ist immer vorhanden!

Der tagtägliche Lock-in

Ein gutes Beispiel ist IKEA. Unsere Wohnung besteht bis auf die Küche aus Möbeln von IKEA. Warum? Weil es gut aussieht, perfekt zusammenpasst UND Möbel anderer Anbieter sich damit schwer kombinieren lassen. Es ist der perfekte Lock-in. Und? Wir finden es toll, weil es den Zweck, aber vor allem unsere Anforderungen erfüllt. Analog zur IT bedeutet es, dass sich Unternehmen bewusst auf einen vermeintlichen Lock-in mit SAP, Microsoft, Oracle und anderen Anbietern einlassen, weil sie ihn benötigen und weil die genannten Anbieter die Anforderungen weitestgehend erfüllen. Man überlege sich nur mal, wie viele Unternehmen sich SAP angepasst haben und nicht anders herum. Weil es zunächst möglicherweise keine Alternativen gab und weil SAP die gewünschten Funktionen für das tagtägliche Geschäft erfüllte.

Das Paradebeispiel für einen Lock-in ist das iPhone/ iPad. Und? Richtig, alle lieben ihn! Weil das iPhone den eigenen Coolnessfaktor “anhebt” und auch noch die Funktionen mitbringt die so viele benötigen, auch wenn sie es vorher nicht einmal wussten. Bis auf den Coolnessfaktor gilt dasselbe für Android. Man möge nun argumentieren, dass Android Open-Source sei und die Freiheit damit schließlich größer ist. Das stimmt auf der einen Seite. Und für die Einzelperson mag sich der Aufwand für einen Wechsel relativ in Grenzen halten. Aus der Sicht eines Unternehmens sieht es aber schon wieder ganz anders aus. Hier ist der Lock-in vergleichbar mit einem iPhone/ iPad, nur im Google Universum.

Kein Vendor Lock-in ist reines Marketing-Versprechen

Ähnlich verhält es sich in der Cloud und hier speziell bei OpenStack. Rackspace ist der Lautsprecher der OpenStack Gemeinde. Der Anbieter argumentiert, dass man von einem Public Cloud Anbieter der auf OpenStack setzt, besser in die eigene Private Cloud Infrastruktur zurückkommt. Und liefert natürlich gleich eine eigene OpenStack Private Cloud Distribution mit. Am Ende verdient Rackspace durch Beratung und weitere Dienstleistungen daran. Rackspace Argument ist richtig, aber eher auf der Marketingebene zu verstehen. Denn auch ein Anbieter wie Microsoft bietet mit seinem Windows Server 2012 die Möglichkeit von Azure zurück in die eigene Infrastruktur. Und auch von den Amazon Web Services (AWS) kann man sich befreien, wenn man eine eigene Eucalyptus Cloud besitzt. Zwar bildet Eucalyptus bei weitem noch nicht alle Services von AWS ab, aber das wird im Laufe der Zeit passieren. Ich bin darüber hinaus weiterhin davon überzeugt, dass Amazon Eucalyptus früher oder später kaufen wird.

Also, auch bei OpenStack begibt man sich in einen Lock-in. Zwar wird hier von offenen Standards und APIs gesprochen. Aber im Endeffekt bleibt man damit auch nur im OpenStack Ökosystem gefangen. Das bedeutet, dass man bequem zu einem anderen Anbieter wechseln kann der OpenStack unterstützt. Das Thema Openness wird hier aber eher als Marketingmittel genutzt. Schließlich handelt es sich bei OpenStack und allen anderen kommerziellen Open-Source Vereinigungen um keine Spaßveranstaltungen. Da geht es um knallhartes Business. OpenStack vereinfacht es am Ende nur, zwischen den verschiedenen Anbietern zu wechseln die ebenfalls auf OpenStack setzen. Da aber alle Anbieter quasi auf dieselbe Technologie aufsetzen und sich nur durch Mehrwert-Dienstleistungen abheben, hat man auch hier den OpenStack Technologie Lock-in. (Ja natürlich ist es möglich, sich unabhängig von einem Anbieter eine eigene OpenStack Cloud aufzubauen. Aber der (finanzielle) Aufwand steht in keinem Verhältnis zum späteren Nutzen.)

Ein Lock-in bietet mehr Vorteile als man denkt

Ein Lock-in bietet zudem einige Vorteile. Er schafft Innovationen, von denen man als vermeintlicher “Sklave” partizipiert. Die Anbieter rollen ständig Verbesserungen aus, von denen wir profitieren. Und, der Lock-in ist gut, solange er genau den Zweck erfüllt, der erwartet wird. Wenn die Lösung die Anforderungen erfüllt ist alles super! Als Unternehmen lässt man sich nach der Entscheidung für einen Anbieter zudem bewusst darauf ein. On-Premise hat man sich seit Jahren auf einen Lock-in eingelassen. Sicherlich ist man mit der einen oder anderen Funktion nicht ganz einverstanden, aber im Großen und Ganzen ist man glücklich, weil die Probleme gelöst und Anforderungen erfüllt werden. Und, als Unternehmen nimmt man auch in der Cloud eine nicht unbedeutende Summe finanzieller Mittel in die Hand. Diese Investitionen müssen sich erst einmal rentieren, bevor man wieder über einen Wechsel nachdenkt. Eines sollte man darüber hinaus nicht vergessen. Hat ein anderer Anbieter großes Interesse daran, ein Unternehmen von einem bestehenden Anbieter loszureißen, wird er alles mögliche in Bewegung setzen, um diesen Weg zu ermöglichen. Bevor man sich also zu viele Gedanken über einen Lock-in macht, sollte man lieber zunächst schauen, wie zukunftssicher die Services und der Cloud-Anbieter selbst sind und das in eine mögliche Exit-Strategie mit einbeziehen.

Fazit: Wir leben ständig mit einem Lock-in, der sich niemals vollständig umgehen und maximal sehr gering halten lässt. Der eine Lock-in ist etwas flexibler als der andere, aber die Entscheidung dafür bleibt. Nicht abzustreiten bleibt, wir lieben ihn, den Lock-in!

Categories
Analysis

Cloud-Desktop: The browser becomes the operating system

The variety of software-as-a-service applications and other cloud services is growing steadily. Next to a difficult overview this leads to a higher complexity. One trend are cloud marketplaces that categorize a catalog of different services and thus giving an overall portfolio. What these marketplaces currently still missing is the integration of existing services and applications. This means that working on a common database is not possible, which is known from many on-premise infrastructures, and results in data and application silos.

State of play

The problem of cloud data silos is not just in cloud marketplaces. There are also advertisements for ways of integrating e.g. a CRM SaaS solution applied with an Office suite. In practice, the implementation is achieved modest. Somehow, the systems are indeed connected. In the end one works on different systems, with separate data and must also register separately for both.

Today, the cloud lacks with the integration of disparate services to work on a common data base.

Integration is imperative

Speaking about integration we mean interfaces and data. Some time ago I had suggested that cloud computing for business can give a chance to clean up their historically grown silos. Using the cloud, for companies with isolated solutions it is now easier to replace a single system from that island solution against a cloud service to successively obtain a fully integrated (total) system of multiple cloud services. The practice at this point is not yet so far, but there are initial efforts to change this. And this is essential in order to exploit the variety of different cloud services. A crucial point is the access of the respective cloud services on a common database. This means that every application saves their data continuously in a quasi central store and also call it from there again.

The integration layer inevitably need not a central and persistent data base. One another possibility is to load the data in real time from the integrated systems. These are then processed and displayed on a single interface. Thus, for example, an arbitrary cloud storage is involved, on which the data (pictures, videos, etc.) is stored. However, this means that all cloud services that want to be part of this ecosystem need to open their APIs to the outside in order to save the data and load it back.

The browser becomes the operating system

Irrespective of how the integration is achieved in detail. The browser becomes the “one face to the customer“, the central interface, when the user accesses the Internet. I recently described Desktop-as-a-Service (DaaS). But they are only an intermediate step to the actual final state. Indeed DaaS provide full-fledged working environments including classic applications in the cloud. However, the DaaS normally runs in the browser. That means, one first starts his computer, then the browser to start another operating system again. Would an enterprise thus rely on software-as-a-service solutions and DaaS, it again incurs the data and application silos.

The aim is therefore to develop a sort of “uber-cloud”, which is accessed via single sign-on to all services in the cloud into a single interface, who want to be the part of the whole. This is not a new concept and has already been applied. But only on a very proprietary basis with services from a single company. By integrating external services, this approach has failed so far.

These “uber-cloud” can be either a public cloud service or stand by as a private solution. The private solution would have the advantage that IT departments use them as a service broker or as a service portal including application firewall for the employees and get a little control over business applications.

That scenario would mean that an employee logs in at the “uber-cloud” and sees the for him relevant business applications. Based on the application at the “uber-cloud” he is directly signed in to other applications.

The “uber-cloud” should be built like a plugin system, with that each company can put a personal productivity cloud together for their purposes. With the plug-in system different apps/ services can be integrated if the API allows it. Either the data is presented in a single interface. So the data is loaded at runtime and restored after changes or the respective services are organized into “tabs”. It is only important that the data are in a kind of centralized access. Thus, for example, everyone could use any cloud storage as this will only be docked. Where the data is determined the company decide itself.

The browser becomes the operating system. However, it still needs the proper and independent platforms to be implemented.

Categories
Analyst Cast @de

Cloud – Big Data – … oder wie finde ich einen Use Case

Categories
Comment

How future-proof is the Google cloud portfolio?

Google is known for “just” throw a new service on the market. That’s their corporate culture. It promotes creativity within the company and ensures innovation. But at the end of the day also Google must be clean up the playground. This resulted in numerous closures of famous and lesser-known services in the recent past. Latest victim is the popular Google Reader. It will be shut down at 1th of July 2013. This naturally raises the question of how vulnerable Google’s cloud services are for a portfolio adjustment. At least the finger on the close button seems to fit very loosely.

Longevity vs. popularity

Google scrubs its Google Reader as its popularity has fallen sharply in the past, Google said. That Google is apparently not quite right here, shows a recent petition against its closure. After all, 20,000+ subscribed against its closing.

Google sometimes gives me the impression that it is like a big kid. They find many things at once exciting (20 percent rule), play with it, investing time and then loses interest and pleasure, when the playmates apparently no longer want to play with it. The concentration phase is only with a few products really high. (From a entrepreneurial point of view correct.)

Companies do not like that

Google is currently making great efforts to broadly make it in the business environment. Regarding current providers such as Microsoft and IBM no easy task. Google’s trump card is that they are born in the cloud and know the rules inside out. Finally, they almost self-developed them.

Nevertheless, the question is permissible. Why should a business use Google cloud services, such as Google Apps or the Google Cloud Platform, if services that are apparently not used sufficiently well, to be suddenly closed? Even if Google has monetized above named cloud solutions now, this question retains its place. Because by the monetization of individual service suddenly gets a new KPI, the revenue!

Google may assume that enterprises will not be thrilled if they suddenly get an e-mail that the service they are using will be closed due to lower attractiveness and revenue figures in three months.

For enterprises, this type of product management is not attractive and Google must learn that enterprises need to be treated differently from private users. Even if the consumerization progresses.

Clean up the portfolio is good, but…

No question, it makes sense to clean up the portfolio steadily. It is also recommended for many other providers. However, these seem to act in the interests of their customers and offer their products and services on a long-term roadmap. However, it seems that the finger at the “service close button” at Google sits relatively loose.

I do not think companies will come together for a petition against the closure of Google services. Indeed, you always hear about “too big to fail”, but Google is not as big as all that.

Categories
Kommentar

Wie zukunftssicher ist das Google Cloud Portfolio?

Google ist bekannt dafür, “mal eben” einen neuen Service auf den Markt zu schmeißen. Dafür steht die Unternehmenskultur. Sie fördert die Kreativität innerhalb des Unternehmens und sorgt für Innovationen. Am Ende des Tages muss aber auch bei Google der Spielplatz aufgeräumt werden. Das führte in der jüngsten Vergangenheit zu unzähligen Schließungen bekannter und weniger bekannter Services. Neuestes populäres Opfer ist der Google Reader. Dieser soll nun zum 01. Juli 2013 eingestellt werden. Da stellt sich natürlich die Frage, wie anfällig Googles Cloud Services für eine Portfolio Bereinigung sind. Der Finger auf dem Schließen-Button scheint zumindest sehr locker zu sitzen.

Langfristigkeit vs. Popularität

Google stampft den Google Reader ein, da dessen Popularität, nach eigenen Angaben, in der Vergangenheit stark eingebrochen ist. Das Google hier scheinbar nicht ganz richtig liegt, zeigt eine aktuelle Petition gegen dessen Schließung. Immerhin haben sich hier in kürzester Zeit 20.000+ dagegen ausgesprochen.

Manchmal erweckt Google bei mir den Eindruck, ein großes Kind zu sein. Es findet viele Dinge auf einmal spannend (20 Prozent Regel), spielt damit, investiert Zeit und verliert dann das Interesse und die Lust, wenn die Spielkameraden scheinbar auch nicht mehr damit spielen möchten. Die Konzentrationsphase ist nur bei einigen wenigen Produkten wirklich hoch. (Unternehmerisch natürlich richtig.)

Unternehmen sehen das nicht gerne

Google unternimmt derzeit große Anstrengungen sich im Unternehmensumfeld breit zu machen. Hinsichtlich bestehender Anbieter wie Microsoft oder IBM keine leichte Aufgabe. Googles Trumpfkarte ist, dass sie in der Cloud geboren sind und die Regeln aus dem Effeff kennen. Schließlich haben sie diese quasi selbst mit entwickelt.

Dennoch sei die Frage gestattet. Warum soll ein Unternehmen auf Google Cloud Services, wie Google Apps oder die Google Cloud Platform setzen, wenn Services, die scheinbar nicht ausreichend gut genutzt werden, plötzlich geschlossen werden? Auch wenn Google die genannten Cloud Lösungen mittlerweile monetarisiert hat, diese Frage behält ihre Berechtigung. Denn durch die Monetarisierung bekommt der einzelne Service plötzlich eine neue KPI, den Umsatz!

Google darf davon ausgehen, dass Unternehmen nicht davon begeistert sein werden, wenn sie plötzlich eine E-Mail bekommen, dass der von ihnen genutzte Service auf Grund sinkender Attraktivität und Umsatzzahlen in drei Monaten geschlossen wird.

Für Unternehmen ist diese Art des Produktmanagements nicht attraktiv und Google muss lernen, dass Unternehmen anders behandelt werden müssen als Privatnutzer. Auch wenn die Consumerization weiter fortschreitet.

Das Portfolio bereinigen ist gut, aber…

Keine Frage, es ist sinnvoll sein Portfolio stetig zu säubern. Das ist auch vielen anderen Anbietern zu empfehlen. Allerdings scheinen diese im Sinne ihrer Kunden zu handeln und bieten für ihre Produkte und Services eine langfristige Roadmap an. Hingegen scheint der Finger auf dem “Service Schließen-Button” bei Google relativ locker zu sitzen.

Ich glaube kaum, dass Unternehmen zu einer Petition gegen die Schließung eines Google Services zusammenkommen werden. Zwar hört man immer wieder gerne von “Too big to fail”, aber so groß ist Google dann auch wieder nicht.

Categories
Analysen

Cloud-Desktop: Der Browser wird das Betriebssystem

Die Vielzahl unterschiedlicher Software-as-a-Service Applikationen und weiterer Cloud-Services nimmt stetig zu. Das führt neben einem schwierigen Überblick ebenfalls zu einer höheren Komplexität. Ein Trend sind Cloud Marketplaces, die einen Katalog verschiedener Services kategorisieren und damit ein Gesamtportfolio ergeben. Was diesen Marketplaces derzeit jedoch noch fehlt, ist die Integration der vorhanden Services und Applikationen. Das führt dazu, dass nicht auf einer gemeinsamen Datenbasis gearbeitet wird und wie aus vielen on-Premise Infrastrukturen bekannt, Daten- und Applikationssilos entstehen.

Stand der Dinge

Die Problematik der Cloud Datensilos besteht nicht nur in den Cloud Marketplaces. So werden auch Integrationsmöglichkeiten von z.B. einer CRM SaaS Lösung mit einer Office Suite beworben. In der Praxis ist die Umsetzung jedoch eher bescheiden gelöst. Irgendwie sind die Systeme zwar verbunden. Im Endeffekt arbeitet man aber auf unterschiedlichen Systemen, auf getrennten Daten und muss sich auch bei beiden separat anmelden.

Es fehlt der Cloud derzeit also die Integration unterschiedlicher und voneinander unabhängiger Services für die Arbeit auf einer gemeinsamen Datenbasis.

Integration ist zwingend erforderlich

Spricht man von Integration meint man Schnittstellen und Daten. Ich hatte vor längerer Zeit mal angedeutet, dass Cloud Computing für Unternehmen die Chance bedeuten kann, mit ihren historisch gewachsenen Insellösungen aufzuräumen. Unternehmen mit Insellösungen haben es durch die Cloud nun einfacher ein Einzelsystem dieser Insellösung gegen einen Cloud Service auszutauschen, um darüber sukzessive ein vollständig integriertes (Gesamt)-System von mehreren Cloud Services zu erhalten. Die Praxis ist an dieser Stelle zwar noch nicht so weit, es gibt aber erste Bestrebungen dieses zu ändern. Und das ist unumgänglich, um die Vielfalt unterschiedlicher Cloud Services zu nutzen. Ein entscheidender Punkt hierbei ist der Zugriff der jeweiligen Cloud Services auf einen gemeinsamen Datenbestand. Das bedeutet, dass jede Anwendung in einen quasi zentralen Speicher ihre Daten ständig ablegt und von dort auch wieder aufrufen muss.

Für den Integrationslayer ist zwangsläufig aber keine zentrale und persistente Datenbasis erforderlich. Eine Möglichkeit besteht auch darin, die Daten in Echtzeit aus den integrierten Systemen zu laden. Diese werden anschließend aufbereitet und auf einer einheitlichen Oberfläche dargestellt. So kann zum Beispiel auch ein beliebiger Cloud-Storage eingebunden werden, auf dem Daten (Bilder, Videos, usw.) abgelegt sind. Das bedeutet jedoch, dass alle Cloud Services, die Teil dieses Ökosystems werden wollen ihre APIs nach Außen öffnen müssen, um die Daten laden und zurückspeichern zu können.

Der Browser wird das Betriebssystem

Unabhängig davon wie die Integration im Einzelnen gelöst wird. Der Browser wird das “one face to the customer“, also zum zentralen Interface, wenn der Benutzer auf das Internet zugreift. Die von mir vor kurzem beschriebenen Desktop-as-a-Services (DaaS) sind dabei nur ein Zwischenschritt zum eigentlichen Endzustand. Zwar stellen DaaS vollwertige Arbeitsumgebungen inkl. klassischen Applikationen über die Cloud bereit. Jedoch läuft der DaaS normalerweise im Browser. Das bedeutet, man startet zunächst seinen Rechner, dann den Browser um erneut ein Betriebssystem zu starten. Würde ein Unternehmen somit auf Software-as-a-Service Lösungen als auch DaaS setzen, enstehen wieder die Daten- und Applikationssilos.

Das Ziel besteht daher in der Entwicklung einer Art “Über Cloud”, über die per Single Sign-On auf sämtliche Services in der Cloud – die Teil des Ganzen sein möchten – unter einer einheitlichen Oberfläche zugegriffen wird. Das ist wohlgemerkt kein neues Konzept und wird bereits erfolgreich umgesetzt. Jedoch nur auf einer sehr proprietären Basis mit Services von einem einzelnen Unternehmen. Sollen hier externe Services eingebunden werden, scheitert dieser Ansatz bisher.

Diese “Über Cloud” kann entweder als Public Cloud Service oder als private Lösung bereitstehen. Die private Lösung hätte den Vorteil, dass die IT-Abteilungen sie wie einen Service-Broker bzw. wie ein Serviceportal inkl. Applikationsfirewall für die Mitarbeiter nutzen können und darüber ein wenig Kontrolle über Business-Applikationen erhalten.

Das Szenario würde bedeuten, dass ein Mitarbeiter sich an der “Über Cloud” anmeldet und alle für ihn relevanten Business-Anwendungen sieht. Anhand der Anmeldung an der “Über Cloud” ist er direkt an alle anderen Anwendungen angemeldet.

Die “Über Cloud” sollte dabei wie ein Plugin-System aufgebaut werden, mit der sich jedes Unternehmen für seine Zwecke eine ganz persönliche Productivity Cloud zusammenstellen kann. Durch das Plugin-System lassen sich unterschiedliche Apps/ Services einbinden, wenn deren API dies zulässt. Entweder werden die Daten innerhalb einer gemeinsamen Oberfläche dargestellt. Die Daten also zur Laufzeit geladen und nach Veränderungen zurückgespeichert oder die jeweiligen Services in “Tabs” organisiert. Wichtig ist nur, dass die Daten in einer Art zentralen Zugriff stehen. So würde sich bspw. auch jeder beliebige Cloud Storage nutzen, da dieser nur angedockt wird. Wo die Daten liegen bestimmt damit das Unternehmen selbst.

Der Browser wird das Betriebssystem werden, jedoch müssen dafür noch die richtigen und unabhängigen Plattformen geschaffen werden.

Categories
StepFwd @en

Enterprise App Store – In the cloud: Virtual Private Enterprise App Store

Enterprise App Stores are in line with the trend. The increasing popularity of mobile devices and applications combined with cloud services mean that companies will introduce their own app stores in order to regain some control over the applications used by their employees and the costs.

Enterprise App Store

Apps from public apps stores lead to problems with IT security. Besides bring your own device (BYOD), it is also necessary to find solutions for bring your own application (BYOA), to have an overview and scrutiny which app is used by employees for business purposes to keep the famous barn closed.

A solution to get back the control are so-called “Enterprise App Stores”, enterprise-wide catalogs of applications, which provide a centralized store with mobile, desktop and web applications administered by the company. In particular, mobile applications are rolled out faster and more comfortable, and a standardized support for many devices is offered. But other applications as specific business applications need to be managed as well, so stores are needed that combine everything under one roof.

But, and this is a crucial point, especially the staff must be happy with the app store. With that concepts like BYOD and BYOA come along with. It must offer the apps that the employee would also use private (BYOA) and are supported by the device that he has been in use (BYOD). In addition, the app store must be accessible at any time and from any location, and the employee must not be in the enterprise network for that.

Disadvantages of a local Enterprise App Store

Let’s be honest, which company has the time, desire and above all the capital for the construction and maintenance of an Enterprise App Store’s infrastructure? Moreover, no safe cost effective, convenient and anywhere-access to this app store can’t be ensure. And who wants to ask his staff constantly go to the office to install a new app or download an update? So we are talking about costs and expenses that are disproportionate to the actual benefit. Moreover, the whole issue is much more complex than it first appears.

A local Enterprise App Store makes no sense

Not only the above reasons show that a local Enterprise Apps Store does not make any sense. An app store may therefore minimal be used in a hosted form. This means that an app store provider is responsible for operation and maintenance of a dedicated platform, providing a central access point at any time and from any the place to the apps. Where we arrived at the next challenge, the apps.

Apps, Apps, Apps

The success of an apps store stands and falls with the amount of (quality) apps. If these are not sufficiently prepared, the store is no longer used by the users and alternatives are sought. The app store has to invite, so that users use this actively and regularly browse, discover new applications and make them point out to colleagues. The challenge is therefore to make the Enterprise App Store attractive and especially keep attractive and this is the linchpin to the existing apps. This raises the question of whether a local or a hosted enterprise app store are be able to fulfill that. Normally not, since both are dependent on the input from the client and do not have access to public app stores.

Virtual Private Enterprise App Store

Model: Virtual Private Enterprise App Store

Virtual Private Enterprise App Store

All these reasons lead to an Enterprise App Store version which is hosted and features a maximum of available apps that are attractive enough for people to use the app store. Beyond that own corporate applications should be deployed over it as well.

The widest range of applications are offered by public app stores of known providers that are provided through cloud infrastructures. Disadvantage of these stores is, as the name suggests, that they are in public access and anyone can offer what he wants, if it’s good or bad. There are vendors who follow a very hard process until the app finally lands in the store. Others leave the quality assurance still fully in the community.

However, one should not underestimate the potential of this public app stores and be borne in mind, what does it mean in terms of cost for the entire app store infrastructure and mobile anywhere access to this store and what complexity is overcome to build and operate the store.

A possible variant is the “Virtual Private Enterprise App Store (VPEAS)*“. It is a virtual separate area (see chart) within a public app store in which businesses can operate their own private app store, without having to invest in advance in a separate infrastructure for the app store itself, and in the network infrastructure. All public apps may include as a subset of a VPEAS. Specific enterprise applications can be marked as private and so provided only to the own employees. To ensure that only public apps can be used through the VPEAS, which are considered as safe, appropriate policies needs to be established with the app store providers. The authentication is done by a corporate account / profile for the employee on the local device. Based on that, regulations can be made which apps an employee can use or not. However, it should first be worked with the app power users, to understand which apps have a value for the employee.

* Name chosen by renebuest research.

Categories
IT-Infrastructure

Enterprise App Store – In the cloud: Virtual Private Enterprise App Store

Enterprise App Stores are in line with the trend. The increasing popularity of mobile devices and applications combined with cloud services mean that companies will introduce their own app stores in order to regain some control over the applications used by their employees and the costs.

Enterprise App Store

Apps from public apps stores lead to problems with IT security. Besides bring your own device (BYOD), it is also necessary to find solutions for bring your own application (BYOA), to have an overview and scrutiny which app is used by employees for business purposes to keep the famous barn closed.

A solution to get back the control are so-called “Enterprise App Stores”, enterprise-wide catalogs of applications, which provide a centralized store with mobile, desktop and web applications administered by the company. In particular, mobile applications are rolled out faster and more comfortable, and a standardized support for many devices is offered. But other applications as specific business applications need to be managed as well, so stores are needed that combine everything under one roof.

But, and this is a crucial point, especially the staff must be happy with the app store. With that concepts like BYOD and BYOA come along with. It must offer the apps that the employee would also use private (BYOA) and are supported by the device that he has been in use (BYOD). In addition, the app store must be accessible at any time and from any location, and the employee must not be in the enterprise network for that.

Disadvantages of a local Enterprise App Store

Let’s be honest, which company has the time, desire and above all the capital for the construction and maintenance of an Enterprise App Store’s infrastructure? Moreover, no safe cost effective, convenient and anywhere-access to this app store can’t be ensure. And who wants to ask his staff constantly go to the office to install a new app or download an update? So we are talking about costs and expenses that are disproportionate to the actual benefit. Moreover, the whole issue is much more complex than it first appears.

A local Enterprise App Store makes no sense

Not only the above reasons show that a local Enterprise Apps Store does not make any sense. An app store may therefore minimal be used in a hosted form. This means that an app store provider is responsible for operation and maintenance of a dedicated platform, providing a central access point at any time and from any the place to the apps. Where we arrived at the next challenge, the apps.

Apps, Apps, Apps

The success of an apps store stands and falls with the amount of (quality) apps. If these are not sufficiently prepared, the store is no longer used by the users and alternatives are sought. The app store has to invite, so that users use this actively and regularly browse, discover new applications and make them point out to colleagues. The challenge is therefore to make the Enterprise App Store attractive and especially keep attractive and this is the linchpin to the existing apps. This raises the question of whether a local or a hosted enterprise app store are be able to fulfill that. Normally not, since both are dependent on the input from the client and do not have access to public app stores.

Virtual Private Enterprise App Store

Model: Virtual Private Enterprise App Store

Virtual Private Enterprise App Store

All these reasons lead to an Enterprise App Store version which is hosted and features a maximum of available apps that are attractive enough for people to use the app store. Beyond that own corporate applications should be deployed over it as well.

The widest range of applications are offered by public app stores of known providers that are provided through cloud infrastructures. Disadvantage of these stores is, as the name suggests, that they are in public access and anyone can offer what he wants, if it’s good or bad. There are vendors who follow a very hard process until the app finally lands in the store. Others leave the quality assurance still fully in the community.

However, one should not underestimate the potential of this public app stores and be borne in mind, what does it mean in terms of cost for the entire app store infrastructure and mobile anywhere access to this store and what complexity is overcome to build and operate the store.

A possible variant is the “Virtual Private Enterprise App Store (VPEAS)*“. It is a virtual separate area (see chart) within a public app store in which businesses can operate their own private app store, without having to invest in advance in a separate infrastructure for the app store itself, and in the network infrastructure. All public apps may include as a subset of a VPEAS. Specific enterprise applications can be marked as private and so provided only to the own employees. To ensure that only public apps can be used through the VPEAS, which are considered as safe, appropriate policies needs to be established with the app store providers. The authentication is done by a corporate account / profile for the employee on the local device. Based on that, regulations can be made which apps an employee can use or not. However, it should first be worked with the app power users, to understand which apps have a value for the employee.

* Name chosen by renebuest research.