Posts Tagged: ‘migration’

Migrating OSGi Plugins to standalone applications

13. Januar 2020 Posted by Sven Hasselbach

I have created an example project for migrating an OSGI-based Spring Boot application into an standalone application:

https://github.com/hasselbach/domino-springboot/blob/maven/domino-springboot.plugin

The application runs in the JVM of the Notes Client, only a user id is required, not a complete server installation (and ID). The benefit is that you can run as much JVM instances you want (which allows a better resource management and deployment) and it is easier to integrate the applications into existing CD environments. Also, Non-Domino developers can use their preferred IDE and are able to use existing / standard knowledge when developing Java applications.

When using the Java NAPI, you need to remove the spring-boot-devtools dependency because of problems with the class loader and DLLs.

DNUG Konferenz Berlin : Mein Vortrag – Stolperfallen in Koexistenzen mit Notes Domino

30. Mai 2017 Posted by Noteshexe

Der Fokus des Vortrages liegt in den Fragen zur Koexistenz von Notes/Domino mit anderer Mailsystemen. Migration und Koexistenz, diese beide Themen gehören eng zusammen, da bei einer Migration sehr oft beide Systeme längere Zeit parallel betrieben werden und daher auch eine Koexistenz im Vorfeld geklärt werden muss. Wie kann ich Systeme mit einander koppeln, so

Be social in Chicago!

15. Mai 2017 Posted by Henning Schmidt

Was für eine Stadt! Was für ein Event! Unter diesem Motto könnte die Social Connections 11 in Chicago stehen. Am 01. und 02. Juni trifft sich die Social Collaboration Gemeinde in der windigen Stadt und hedersoft ist wieder Teil des Events. Wir sind stolz darauf, der erste Sponsor des Events zu sein! Die Registrierung läuft […]

Nicht wegwerfen, sondern recyceln: IBM Notes Applikationen im Lego-Prinzip modernisieren

11. Januar 2017 Posted by Stephan Kopp

Viele Nutzer von IBM Notes stehen vor der Frage, wie sie veraltete Applikationen fit für die Zukunft machen. Eine „R.I.P. and Replace“-Strategie macht meist wenig Sinn und wird viel zu teuer. Das Beispiel eines Energiemarktdienstleisters zeigt, wie die Software sinnvoll recycelt werden kann.

weiter lesen…


Filed under: IBM Notes/Domino

Es war einmal ein Lotus Notes Entwickler – Alles hat irgendwann ein Ende

21. Dezember 2016 Posted by Stephan Kopp

Ok, etwas überspitzt, aber dennoch wahr. Notes wird mich und Andere noch lange begleiten, aber bis zu meiner Rente schaffe ich es damit sicherlich nicht.

IBM hat meiner Meinung nach leider kein wirkliches Interesse die Plattform weiter zu entwickeln. So lange es geht, werden die bestehenden Kunden mit „Feature Packs“ noch bei der Stange gehalten, aber mehr nicht. Auch IBM Verse on premise wird daran nichts ändern. Deshalb sollte sich jeder über die Zeit danach Gedanken zu machen.

Wohin mit den ganzen Applikationen? Wirklich alles neu entwickeln? Alles nach Sharepoint oder sonst wohin „migrieren“? Ein solches Projekt ist ein Monster, das kaum jemand angehen und schon garnicht bezahlen möchte.

Ich bin kein Fan des „R.I.P. and Replace“ Ansatzes, den viele bevorzugen. Bei einfachen Applikationen und irgendwelchen Standard Anwendungsfällen mag soetwas machbar und sinnvoll sein. Wir sollten uns aber bei komplexen Applikationen eher ganz gezielt diese zwei Fragen stellen:

  1. Was können wir neu entwickeln um einen Mehrwert für die jeweilige Anwendung zu bieten?
  2. Wie können wir das mit „nicht Notes” Technologien machen und es an die bestehende Applikation anbinden?

In letzter Zeit habe ich mich sehr viel mit REST Schnittstellen und Webservices beschäftigt und auch ein wenig mit Vaadin und Spring Boot. Diese Technologien bieten im Grunde alles, was wir benötigen um beide Fragen zu beantworten.

Nachfolgend ein kleines Szenario, bei dem wir diesen Ansatz konkret umsetzen konnten. Es ging um eine bestehende Notes Applikation, die verwendet wird um andere Applikationen in ein Langzeit Archiv zu verschieben sobald sie nichtmehr verwendet werden. Hierfür sollte ein Webinterface entwickelt werden.

  • Wir benötigen ein Browser Interface, aber der Entwickler (ich) hat kein Händchen für HTML und CSS:  Vaadin
  • Ein Application Server jenseits von Domino ist nicht vorhanden und auch nicht erwünscht: Spring Boot
  • Bestehende Daten und Funktionen aus Notes Applikationen sollen eingebunden werden: REST API oder Webservices

Entstanden ist ein recht ansehnliches Webinterface, das Daten aus einer Notes Applikation darstellt und auch Funktionalitäten aus dieser Applikation ansteuern kann. Hierzu wurden einige bestehende Funktionen als Webservices zur Verfügung gestellt und eingebunden.

archiving-selfservice-01 archiving-selfservice-02

Dieser Ansatz gefällt mir persönlich am besten und zwar aus folgenden Gründen:

  1. Der Aufwand und damit die Kosten sind überschaubar.
  2. Die Anwender haben sofort etwas davon, da wir uns zunächst auf neue Funktionen konzentrieren und nicht erst langwierig das nachbauen müssen, was eh schon vorhanden ist.
  3. Langfristig wird sicher auch irgendwann die Notes Applikation abgelöst, aber vorerst kann man seine Investition schützen und muss nicht bei Null anfangen.
  4. Sind nach und nach immer mehr Funktionen aus Notes hinaus gewandert, kann irgendwann auch der Data Store z.B. auf eine Mongo DB, Couch DB oder was auch immer umgestellt werden.
  5. Das Knowhow der eigenen Entwickler, Admins oder Partner entwickelt sich weiter.

Ich will damit nicht sagen, dass wir alle Notes Applikation in diesem Stil migrieren sollten. Es ist nur ein Beispiel, das in unserem Fall gut funktioniert hat. In anderen Fällen machen andere Technologien vielleicht mehr Sinn. Falls eine Application Server Infrastruktur vorhanden ist, kann diese auch mit verwendet werden und man kann auf Spring Boot verzichten.

Was ich sagen will ist, dass ich jedem Notes Entwickler sehr empfehle sich aktiv in den Entscheidungsprozess einzubringen, was zukünftig mit den Notes Applikationen geschehen soll. Ansonsten wird diese Entscheidung woanders getroffen und oft landen dann mit dem Produkt auch die zugehörigen Personen auf dem Abstellgleis und das wollen wir ja alle nicht.


Filed under: Development, IBM Notes/Domino, Vaadin

Ein Plädoyer für Lotus Notes (Teil 1)

19. Januar 2016 Posted by Stephan Kopp

Ich entwickle jetzt schon seit vielen Jahren im Lotus Notes Umfeld und ja, ich sage weiterhin Lotus Notes!

Man macht sich so seine Gedanken, ob das alles noch Zukunft hat und schaut sich immer mal wieder in fremden Gefilden um. Ich habe auch schon C#, iOS und Java Applikationen entwickelt, muss aber sagen dass mir Lotus Notes immer noch am meisten Spaß macht. Ich meine damit nicht die Programmiersprache LotusScript und schon gar nicht den Eclipse Designer Client. Da gefallen mir Xcode und sogar Visual Studio um Welten besser. Was mich überzeugt ist die Plattform Lotus Notes.

Ich benutze längst nicht alle neuen Features wie OSGI Plugins, Ajax, Dojo, etc. XPages gehen mir auch nicht wirklich leicht von der Hand und ich kann noch nichtmal alles aufzählen was man noch so alles an “modernem Kram” mittlerweile verwenden kann. Aber es ist immer wieder das Gesamtpaket das mich überzeugt und vor allem die schnellen Ergebnisse die man erzielen kann.

Ein konkretes Beispiel ist einer meiner Kunden, der letztes Jahr weg von Notes migriert ist. Bzw. jetzt zwar ein anderes Mail System hat, aber weiterhin die Domino Server für die Applikationen betreiben muss (so wie es eben bei den meisten Migrationen läuft, aber das ist eine andere Geschichte…).

Wir haben zur Unterstützung, Planung und Vorbereitung ein Tool entwickelt. Das war natürlich eine Lotus Notes Applikation. Soweit hat das ja Sinn gemacht, die meisten Vorbereitungen und Tasks liefen auf Domino ab, also nimmt man diese Plattform. Im Verlauf des Projektes sind die Anforderungen aber immer weiter abgedriftet. Von einfachen “schau vorher mal ins AD, ob die SMTP Adresse dort doppelt vorhanden ist” bis hin zu komplexeren Überprüfungen und sogar Änderungen die wir im AD gemacht haben. Bei einigen Anforderungen habe ich sogar mehrfach in den Raum gestellt, ob man dafür nicht lieber eine Applikation auf den zukünftigen Systemen entwickeln sollte, immerhin soll Notes ja abgelöst werden! Aber immer wieder wurde die Lösung auf der Notes Plattform implementiert.

Das kann natürlich mehrere Gründe haben, mir fallen für dieses konkrete Beispiel drei ein:

  1. Die Plattform ist ja schon da
  2. Die Entwickler mit den richtigen Ideen sind auch da
  3. Die Implementierung geht schnell und verzögert das Projekt nicht

Wenn wir von einer Lösung mit anderen Mitteln gesprochen haben, hörten wir meistens von PowerShell oder irgendwelchen Sync Scripten. Aber von einer richtigen Applikation war nie die Rede und schon gar nicht mit vertretbarem Aufwand und Zeitrahmen. Das Ganze musste natürlich auch irgendwie verwendbar sein und einfach zu handhaben. PowerShell ist sehr mächtig, aber an sich nur eine Kommandozeile und man muss sehr genau wissen was man tut. Eine Oberfläche von der aus ich die einzelnen Funktionen (egal welche Systeme dahinter stecken) bedienen kann ist in einem solchen Projekt Gold wert. Also sind immer weitere Funktionen in unser Tool implementiert worden. Sogar die PowerShell Scripte wurden in unser Tool integriert um sie einfacher managen zu können.

Es zeigt sich also, dass selbst bei einer Migration weg von Lotus Notes weiterhin die Vorteile der Plattform zum tragen kommen:

  • Die Server sind vorhanden und skalierbar
  • Security ist gewährleistet
  • Backup ist vorhanden
  • Usermanagement ist vorhanden
  • Man ist nicht auf Domino beschränkt, sondern kann schnell und einfach auf alles möglich zugreifen

Was mich nur sehr traurig stimmt ist die Tatsache, dass solche Argumente meistens nie gehört werden wenn es um die Entscheidung für oder gegen Lotus Notes geht…


Filed under: IBM Notes/Domino

42. DNUG Konferenz: Infrastrukturanalyse und – optimierung mit Sponsor panagenda

16. März 2015 Posted by Solveig Schwennicke

Im Vortrag und in der Ausstellung zur kommenden DNUG Konferenz zeigt Ihnen panagenda, wie Sie Ihr IT-Leben vereinfachen.

Der IBM Business Partner bietet Infrastrukturanalyse und – optimierung, um die Gesamtbetriebskosten von Lotus Notes- und Domino-Umgebungen zu verringern. panagenda verfügt über jahrelange Erfahrung in den Bereichen Upgrade, Audit, Migration und Konsolidierung rund um IBM Notes Clients, Applikationen und Domino Server.

www.panagenda.com

 

Informationen zur Konferenz:

Domino-Migration: Der frühe Vogel fängt den Wurm

17. Dezember 2014 Posted by Sven Hasselbach

Wenn die Entscheidung erst einmal gefallen ist, dass mittel- oder langfristig die Domino-Infrastruktur aus dem Unternehmen verschwinden wird, lässt die Investitionsbereitschaft der einzelnen Fachabteilungen in Domino-basierte Applikationen verständlicher Weise spürbar nach. Aber auch aufkommende Gerüchte oder durchgeführte Studien (auch wenn diese zu einem gegenteiligen Ergebnis kommen) können den Willen der IT- oder Geschäftsleitung nach einem Systemwechsel zu entsprechender Aussage verhelfen, und durch die aufkommende Ungewissheit zu dem gleichen Ergebniss führen.

Um dennoch zukunftssichere Applikationen zu entwickeln, bieten sich verschiedene Wege an, die sich (in Abhängigkeit zu der bestehenden und der zukünftigen Infrastruktur sowie der gewünschten strategischen Ausrichtung) jedoch stark unterscheiden können. Für jedes Unternehmen sind bestimmte Faktoren unterschiedlich zu bewerten, daher gibt es keinen “Königsweg”: Der zu beschreitende Weg ist immer individuell, und es müssen höchstwahrscheinlich ein paar Kompromisse eingegangen werden, um einen Übergang so geräuschlos wie nur möglich über die Bühne zu bringen.

Der mit Abstand wichtigste Punkt ist, sich möglichst früh vom liebgewonnenen Domino zu verabschieden, ohne eine falsch angebrachte Sentimentalität. Weitere wichtige Punkte, die es meiner Erfahrung zu beleuchten gilt, sind

  1. die gewünschte Form der Migration
  2. mögliche Ziel-Plattformen
  3. zunkünftige Datenhaltung
  4. die Authentifizierung der Anwender

Formen der Migration

Ist eine harte Migration gewünscht, sind praktisch alle Entscheidungen bereits getroffen, und eine weiteres Auseinandersetzen mit anderen Szenarien erübrigt sich: Sowohl Zielplatform als auch (Wunsch-)Termin stehen fest. Das Budget spielt dann wahrscheinlich auch keine Rolle, und ich wünsche viel Glück und gutes gelingen.

Wählt man hingegen eine weiche oder integrative Migrationen, erhöht sich der nötige Spielraum deutlich, und die Chance einer erfolgreichen Umstellung steigt, denn der Zeitdruck und das damit einhergebrachte Risiko eines Fehlschlages wird durch die Politik der kleinen (aber feinen) Schritte drastisch verringert.

Mögliche Zielplattformen

In einem Microsoft-lastigen Unternehmen bietet sich natürlich der IIS als Webserver an, um Applikationen darauf zu hosten. Der IIS unterstüzt neben den “Microsoft-eigenen” Sprachen wie .NET auch weitere wie z.B. Java und PHP. Selbst Node.js wird unterstüzt.

Hier wäre also ein Ansatzpunkt, neue Applikationen direkt auf dem IIS zu betreiben. Falls momentan noch kein IIS im Einsatz ist, bietet es sich an, eine PHP-Applikationen auf dem Domino zu hosten, und diese dann später auf den IIS zu verschieben. Als Alternative kann auch ein Apache HTTP Server oder ein Tomcat dienen, wenn IT diesen betreiben kann (und will). Gleiches gilt natürlich auch für Node.js. Letztlich muss dieser Punkt mit der Administration abgeklärt werden.

Zieht man Client-basierte Applikationen (Stichwort “Angular JS”) in Betracht, kann die Applikation sogar in die Cloud verlagert werden, denn die Daten bleiben im Unternehmen: Zwar lädt der Browser die statischen Ressourcen aus der Cloud, doch werden die Daten vom Browser nur per REST-Schnittstelle im Unternehmensnetzwerk hin- und hergeschoben. Dadurch entfiele ein entsprechender administrativer Aufwand, die Applikation könnte auch von einem externen Anbieter problemlos betrieben werden (z.B. Bluemix).

Zukünftige Datenhaltung

Die Datenhaltung stellt wohl in bestimmten Stitautionen die größte Herausforderung dar, insbesondere wenn auch alte Daten migriert werden müssen. Gerade das Thema “Rich Text-Felder” kann Probleme bereiten, denn je nach Verwendung wird es schwierig, bestehende Daten/Funktionalitäten 1:1 zu übernehmen. Auch einige eher selten genutzte Features auf Feldebene können eventuell nicht ohne erheblichen Aufwand abgebildet werden, doch muss man hier derweilen auch hinterfragen.

In den meisten Fällen sollte eine Umstellung allerdings Reibungslos möglich sein. Moderene Dokumentenbasierte Datenbanksysteme bieten einen ebenbürtigen Funktionsumfang, meist sogar noch deutlich mehr. Dennoch sollte meiner Erfahrung nach dieser Part nicht unterschätzt werden.

Authentifizierung

Eine wichtige Rolle stellt die Authentifizierung im Unternehmen dar: Wurde dies bisher vom Domino Server gehandelt, fällt diese Option zukünftig weg. Aber auch hierfür gibt es unterschiedliche Ansätze, je nachdem, woher die Applikation Ihre Daten erhält und wohin diese Daten abgelegt werden.

Wird der Domino Server nur zur Authenifizierung und nur einige Daten über den User benötigt, existiert mit LDAP eine relativ simple Lösung des Problems, die auch einfach migriert werden kann.

Sollen existierende Datenbanken angezapft werden, kann dieser Zugriff im Usercontext durch eine Proxy-Funktionalität geschehen (durch das Abgreifen/Durchschleifen des Domino Cookies). Eine spätere Umstellung kann dann für die Endapplikation transparent erfolgen, in dem letztlich der Code im Backend geändert wird, ohne das es hier zu Einschräkungen kommt.

Nutzer der Applikation

Ach, ein Thema habe ich bewusst aussen vor gelassen, dass aber ebenfalls eine große Rolle spielt: Die Nutzer der Applikation. Man darf Sie nie vergessen, und man muss versuchen, auf sie einzugehen, aber leider ist das die große Unbekannte, die praktisch unberechenbar ist: Es gibt Mitarbeiter, die sehr interessiert sind, und bei der Umstellung mitarbeiten. Gerade wenn die Möglichkeit dafür genutzt wird, das eine odere andere hilfreiche Zusatzfeature zu implementieren, und so den Mitarbeitern eine entsprechende Motivation zu bieten, wird verläuft eine Zusammenarbeit meist harmonisch und ertragreich. Letztlich sollte die Chance auf ein Redesign einer alten Applikation so gut wie möglich genutzt werden.

Aber man wird eventuell auch auf eine generelle Ablehnung stoßen, denn es war für die Mitarbeiter bisher möglich, viele Probleme im Arbeitsalltag auf “das Sch..ss Notes” zu schieben. Diese Option entfällt zukünftig – was manchem Mitarbeiter in Erklärungsnot bringen könnte, und daher wird gemauert ohne Ende. Auch könnte es vorkommen, das vorhandene Features, die noch nie funktioniert haben, über Nacht zu Keyfeatures mutieren und deren “mangelnde Funktionalität” die ganze Migration ad absurdum führen würden.

Da der “menschliche Faktor” unberechenbar und damit unplanbar ist, kann (und sollte) er in der anfänglichen Planun nicht näher beachtet werden.

Fazit

Alles in allem lösbare Punkte, auf die ich im Einzelnen in den nächsten Tagen näher eingehen möchte. Es stehen noch Themen auf der Agenda, wie beispielsweise die Suche nach relevanten Applikationen, die migriert werden müssen. Und natürlich sollte die eine oder andere Anekdote, die ich in den letzten Jahren gesammelt habe, nicht fehlen.

Isolation and multi-tenancy in the IBM PureApplication System – Cloud Groups are the NEW Virtual Systems

9. April 2014 Posted by Yathish Kumar

(This is a guest entry posted on behalf of Georg Ember)

Almost any application running in the cloud is designed to share resources. Virtualization is the key enabler for cloud computing in integrated or converged systems. Applications run in the cloud as workloads that share system resources, such as CPU, memory and networking.  However, there are legal or organizational requirements where workloads must be isolated from each other and the key question is: What type of isolation is the right way to protect the application environments from each other?

Isolation (also as know as multi-tenancy) is a key requirement for cloud computing. An application deployed into a cloud environment must be able to run independently and separately from other applications in the cloud. Each application requires it to move traffic along the network and protect its data as well.

Isolation of applications and data, by physical separation or by virtualization within an integrated system, may satisfy security requirements and ensure that a failure of one application will not cause the failure of other applications. While the data has to be kept isolated, in many cases, other departments within a company are not allowed to see deployed resources (Virtual Machines) of other environments.

An ideal solution to implement such an application and virtual systems isolation is to exploit the multi-tenancy features of the IBM PureApplication System.

A comfortable and easy way to isolate LAN, SAN and Server resources, on a physical as well as a logical level in PureApplication System, is to use the concept of Cloud Groups and environment profiles.

Using the isolation techniques that are incorporated within the IBM PureApplication System can help minimize business risks and increase the availability. By selecting nodes to Cloud Groups which are placed in separate chassis modules, the performance and availability of a Cloud Group can be greatly increased.

image

If you are required to isolate applications and data not only on a logical level, the concept of Cloud Groups in the PureApplication Systems is the right choice for you. You do not need to acquire multiple physical systems, except for high availability or disaster recovery reasons, when you need to separate multiple application environments in a multi-tenant infrastructure. PureApplication System offers the concept of dedicated Cloud Groups.

IBM PureApplication System Cloud Groups physically separate:

  • Compute Nodes (server nodes), across IBM Flex Chassis,
  • LANs by defining VLANs (on dedicated LAN ports) and IP groups (IP address ranges),
  • Services running on the System (so called shared services), each Cloud Group can have “private” services running, without affecting other Cloud Groups. Examples of shared services are monitoring, OS updates, Load Balancers and clustered file systems services, just to name a few.
  • Workload (deployment) users, where each user belongs to one or more environment profiles, can deploy an application to the designated Cloud Group, without seeing other deployed resources from other users or being seen by other users on the Cloud Groups.

image

Companies normally separate environments according to application development lifecycle. The typical divisions are:

  • Development (DEV): An environment used for developing applications.
  • Testing (TEST): Used for testing applications.
  • Production (PROD): Used for running applications; this is the realm of business or end users.

Each of these environments typically runs on totally independent sets of hardware and networks to avoid cross-environment issues. But, when using Cloud Groups in the PureApplication System, application environments are totally isolated from each other, if required, even by the users and shared services they use. Consecutively, you do not need to acquire multiple physical systems – one PureApplication System does it all for isolation of application environments. There is full isolation and protection in any layer of the stack.

Microsoft Migration: Directory Integration als Schwerpunkt im DNUG AK Enterprise Integration, Migration & Koexistenz am 11.11.2013 in Frankfurt

28. Oktober 2013 Posted by Roswitha Boldt

Im Vorprogramm der "Social Collaboration 39" am 11. November 2013 bieten die DNUG Arbeitskreise Veranstaltungen an.

Schwerpunkt im AK Enterprise Integration, Migration & Koexistenz ab 13 Uhr ist das Thema Microsoft Migration: Directory Integration.

Im Laufe des Nachmittags werden diese Themen angesprochen:

  • Einführung in die Directory Integration inkl. Gemeinsamkeiten, Unterschiede, ... der beiden Verzeichnisse IBM Domino Directory und Microsoft Active Directory (AD)
  • Vorbereitung durch Datenbereinigung im Quellsystem
  • Herausforderungen durch die Mail-Migration
  • Anwendungsbeispiele ohne Migration
  • Typische Szenarien der Directory Integration   
  • Möglichkeiten und Grenzen mit den existierenden Tools (Microsoft, Quest, ThirdParty, ...)
  • Programmatische Lösungen einer Directory Integration

Alle Teilnehmer sind herzlich eingeladen, eigene Erfahrungen aus der Unternehmenspraxis und Fragen beizusteuern. Auch die Abschlussdiskussion und die beiden folgenden Konferenztage bieten Gelegenheit zum Austausch.

 

Weitere Informationen zum Arbeitskreis

 

Überblick über die weiteren Arbeitskreise und Workshops des Vorprogramms

Überblick über die Social Collaboration 39

 

 

Schlange oder Frosch – Auf dem Weg in die Cloud

1. Oktober 2013 Posted by Philipp Boltze

 

Der aufmerksame CloudBlog Leser wird sich langsam fragen, was denn nun als nächstes kommt. 

Ich konnte Sie hoffentlich von den Vorzügen der Cloud überzeugen, Ihnen klar machen, wie wichtig Standardisierung ist und Ihnen sogar noch den Fachbegriff DevOps grob erläutern. Aber was nun? 

 

Dazu passt einen gerade geführte Diskussion mit einem großen, internationalem Kunden, mit dem wir nun schon mehre Workshops hatten und genau dieses Thema sehr intensiv diskutieren: Wie bekommen wir seinen 1.000 in ganz Europa verstreuten Server in die Cloud?

 

Lassen Sie mich dazu nochmals ganz kurz ausholen: Er möchte ja nicht wirklich seine Rechner in die Cloud stellen, sondern seine Anwendungen

Bei Anwendungen unterscheidet man erstmal in zwei Kategorien:

 

BildBild1. Born on the Enterprise - also Anwendungen die in einem traditionellen Umfeld mit lokalen Servern, vielleicht bereits virtualisiert, im eigenen Unternehmen entstanden sind und dort auch heute betrieben werden. Diese Anwendungen skalieren typischerweise vertikal, also wer mehr will, braucht einen größeren Server. Sie bauen auf existierenden Middleware (z.B. Datenbank) auf und sind kompatibel mit bestehenden Systemen. Sie werden dann Cloud Enabled.

 

2. Born on the Web - also Anwendungen, die speziell für die Cloud geschrieben und dort "geboren" sind. Sie sind typischerweise hoch elastisch und skalieren horizontal, wer also mehr will, nimmt einfach mehr Server. Sie basieren auf standardisiertern Servern und nutzen somit das neue Umfeld voll aus. Diese Anwendungen sind also Cloud Centric.

 

Kommen wir aber wieder zu den 1.000 Servern zurück. Im Zweifelsfall weiß der Kunde bereits, was das für Server sind, wie groß sie sind und welche Ausstattung drin ist. Falls nicht, gibt es dazu auch einfache Sniffer Tools. Aber das sagt einem halt noch wenig über die Anwendungen, die darauf laufen und im Zweifelsfall nur einen Bruchteil der vorhandenen Ressourcen wirklich nutzen. Würde man  also eine Cloud bauend, die genau so groß ist, wie die Summe der 1.000 Server wäre sie viel zu groß - und im Zweifelsfall auch viel zu teuer!

Also muss der Kunden wissen, was das für Anwendungen sind: Wer sind die User, wie sehr schwanken die Ressourcenanforderungen der Anwendung (Volaität), benötigt die Anwendungen spezielle Hardware, Betriebssysteme  oder Middleware?

 

Ich habe hierzu mal eine MindMap erstellt, was man denn alles über seine Anwendungen wissen sollte - die Betonung liegt auf sollte. Denn die Realität ist meist doch ganz anders. Der Eigentümer einer Anwendung hat vor 3 Jahren das Unternehmen verlassen. Mit ihm auch alles Wissen zur Anwendung selbst. Keiner traut sich sie einfach zu beenden, da man natürlich nicht weiß, wer oder welche anderen Systeme alles darauf zugreifen. 

Der Frust-Faktor dieses Arbeitsschrittes ist also beliebig groß!

Bild

 

Nehmen wir aber mal an, dass wir einigermaßen die Daten zu den Anwendungen bekommen haben. Jetzt kann man, z.B. mit Hilfe des IBM eCumulus Tools erkennen, welche Anwendungen die berühmten "low hanging fruits" sind, also die Systeme, die man mit relativ geringen Aufwand migrieren kann und die dann relativ viel Nutzen bringen. Reif also für die erste Welle in die Cloud

 

Es ergeben sich damit mehrere Wellen, in denen die Anwendungen Schritt für Schritt in die Cloud transferiert werden. Und es bleiben sicher noch eine ganze Menge übrig, die sich nicht lohnen oder aus technischen Gründen gar nicht in die Cloud transferiert werden können.

 

Soviel also zu den bestehenden Anwendungen, die ja typischerweise zur ersten Kategorie - Born on the Enterprise - gehören

 

Aber, so fragte sich der CIO, was ist, wenn ich einen "leapfrog" (übersetzt: Bocksprung) mache. Ich also wie ein Frosch von der alten Welt gleich in die Neue springe? 

 

Klar, eine gute Idee! Warum sich wie eine Schlange durch das Tal der Migrationstränen schlängeln, wenn ich auch gleich auf eine neue Cloud-Anwendung springen kann. Entweder selbst geschrieben oder gleich fertig, vielleicht sogar als Software as a Service (SaaS) eingekauft. Um dies zu beurteilen muss ich in einem Business Case die Kosten der Neuanschaffung und Einführung dem Aufwand der Migration gegenüberstellen. Also doch wieder alle Informationen zu den Anwendungen. Und zusätzlich natürlich noch "Was macht sie eigentlich?" und "Gibt es eine vergleichbare Anwendung für die Cloud auf dem Markt?".

 

Dies mag der Grund sein, warum so viele Unternehmen sich anfänglich dazu entschließen mit ganz neuen Projekten und Anwendungen in die Cloud zu gehen und erst im zweiten Schritt sich über die bestehenden Anwendungen Gedanken machen. 

Die Frage lautet also: Will ich schnell, punktuelle Erfolge oder mittelfristig mein Unternehmen auf ein neues, agiles Bereitstellungsmodell umstellen?

 

Wie ist das bei Ihnen?

 

Kurzzeitige Störungen wegen Migration

5. August 2011 Posted by Claus Böhmer

Es kann heute im Laufe des Tages zu kurzfristigen Störungen bei einigen Diensten von EULUC kommen, da ich verschiedene Sametime / LDAP Komponenten in einen Clusterverbund überführen werden.

Ich versuche diese Zeiten nach Möglichkeit so kurz wie es geht zu halten.

Kurzzeitige Störungen wegen Migration

5. August 2011 Posted by Claus Böhmer

Es kann heute im Laufe des Tages zu kurzfristigen Störungen bei einigen Diensten von EULUC kommen, da ich verschiedene Sametime / LDAP Komponenten in einen Clusterverbund überführen werden.

Ich versuche diese Zeiten nach Möglichkeit so kurz wie es geht zu halten.

Kurzzeitige Störungen wegen Migration

5. August 2011 Posted by Claus Böhmer

Es kann heute im Laufe des Tages zu kurzfristigen Störungen bei einigen Diensten von EULUC kommen, da ich verschiedene Sametime / LDAP Komponenten in einen Clusterverbund überführen werden.

Ich versuche diese Zeiten nach Möglichkeit so kurz wie es geht zu halten.

Aktivierung von NSL kann fehlschlagen

22. Juli 2011 Posted by Manfred Meise

Mit Notes Shared Login (NSL) können Windows Benutzer Lotus Notes 8.5.x starten, ohne ein Kennwort einzugeben. Die Aktivierung dieser Funktion kann durch den Administrator über eine Sicherheitsrichtlinie erfolgen. Leider funktioniert dieses nur unter folgenden Rahmenbedingungen problemlos:
1.        Der aus frühereren Versionen bekannte Single-Logon Dienst darf nicht installiert sein (einfaches deaktivieren reicht nicht aus...)
2.        Roaming User dürfen keine roaming Notes.ID in der Kontakte Anwendung verwalten

Im Rahmen von Clientmigrationen können Administratoren nicht die aktivierbare NSL-Funktion bei fehlerhaften Roaming-Konfigurationen ("mit Bordmitteln") nur beheben, indem sie Roaming Funktion des Benutzers löschen und erneut aktivieren (ohne die ID Datei in der Kontakte Anwendung zu roamen)
Image:Aktivierung von NSL kann fehlschlagen

oder dank unseres Datenbankpflege-Werkzeuges "just:NSF" indem man die Roaming-IDs aus den serverseitigen Replik der replizierenden Kontakte-Anwendung löscht:

Image:Aktivierung von NSL kann fehlschlagen