ColdFusion im Enterprise Umfeld 
ColdFusion im Enterprise Umfeld - Deep Dive 
CFCamp, Germering, 20. Oktober 2014 
© Richard Carey, Fotolia.com
Coldfusion 
Configuration 
-Star ter Edition-
Webserver 
Coldfusion Server 
Datenbank 
All-in-one-Ser ver 
Developer
Content 
Management System 
(CMS)
Content 
Management 
• Out-of-the-Box Features 
• Flexibilität (Framework) 
• Skalierbarkeit 
• Personalisierung 
• Web 2.0 
• Staging 
• Usability 
• Zukunftssicherheit 
Ein professioneller 
Auswahlprozeß ist unerläßlich
Web Redaktion / Staging 
Front-und Backend immer auf 
getrennten Servern 
Trennung von Front- und 
Backend
Web Redaktion / Staging 
DB und CF-Server immer trennen 
DB-Server
Web Redaktion / Staging 
Zur Ausfallsicherheit 
Datenbank immer replizieren 
Master-Slave- 
Replikation
Mindestens zwei unabhängige 
Webserver 
Redaktion / Staging 
Web 1 
Web 2 
Webser ver
Redaktion / Staging 
Web 1 
Web 2 
Webser ver 
Mindestens zwei unabhängige 
Webserver
Clustering
Coldfusion 
Cluster 
• Performance 
• Session Replikation aufwändig 
• unzuverlässiges Feature 
• Loadbalancer schon für den Webserver 
vorhanden 
• Vorteil in der Applikationsentwicklung 
begrenzt (Skalierung) 
Aufwand für ein Coldfusion 
Cluster lohnt sich nicht
Loadbalancer mit 
Sticky Sessions 
• skaliert besser 
• schneller 
• geringer Konfigurationsaufwand 
Aber: 
• Sessionverlust bei Ausfall 
• Applikationen müssen angepasst sein 
Loadbalancing über seperaten 
Loadbalancer ist oft einfacher
Redaktion / Staging 
Web 1 
Web 2 
CDN 
Webser ver 
Mindestens zwei unabhängige 
Webserver
Akamai 
• Server über die ganze Welt verteilt 
• Eigene Leitungen 
• Speichert alle statischen Objekte 
• Greift nur auf den Origin zu wenn 
Daten nicht vorhanden oder invalide 
• Sucht zuerst auf anderen EDGE-Servern 
• Webservice zum invalidieren 
CDN übernimmt die Last für 
statische Objekte
Akamai 
• Kann dynamische Objekte in 
statische Seiten einbauen (SSI/ESI) 
• Kann auch dynamische Seiten 
speichern 
• Bietet Sureroutes für dynamischen 
Content 
CDN übernimmt die Last für 
statische Objekte
Dedizierte Suche nimmt Last 
vom Applikationsserver 
Redaktion / Staging 
Web 1 
Web 2 
CDN 
Suche
Externe Suche 
(Google) 
• Passiert sowieso 
• Verbraucht keine eigenen Ressourcen 
• Schlecht steuerbar (Zeit, Umfang, Ziel) 
• Google Layout 
• Indiziert dynamischen Content schlecht 
• Kann hohe Serverlast erzeugen 
Externe Suche ist nur eine 
Notlösung
Interne Suche 
(Lucene) 
• Kostenlos 
• Unabhängig 
• Grosse Community 
• Kein Support 
• Zu wenige Sprachen 
• Schlechtes Stemming 
• Aufwändige Implementierung 
• User sind Google gewöhnt 
Lucene Einsatz verlangt Aufbau 
von Know-How
Interne Suche 
(GSA) 
• Kann alle Sprachen 
• Stemming 
• Reaktion auf spezielle Codewörter 
• Drei Arten der Indizierung: Crawlen, 
Content Pushen, URL Pushen 
• Kann auch Datenbanken durchsuchen 
Google gibts auch für Zuhause
Zeit was zu entwickeln 
Entwicklung 
Web1 
CDN 
Web2 
Redaktion
Zeit was zu entwickeln 
Entwicklung 
Web1 
CDN 
Web2 
Redaktion 
DEV
Zentrale 
Entwicklung 
• Instanzen auf einem Server 
• Vollständiger Content des Livesystems 
• Konfiguration entspricht dem Livesystem 
• Einheitliche Konfiguration !!! 
(komisch, bei mit gings...) 
• Zentrales Update, Backup etc. 
Einheitliche 
Entwicklungsumgebung für alle 
Entwickler schaffen
Zeit was zu entwickeln 
Entwicklung 
Web1 
CDN 
Web2 
Redaktion 
GIT 
DEV 
Red 
Live 
Dev
Versionsverwaltung
Versions-verwaltung 
• Früher SVN / CVS, heute GIT / Mercurial 
• Verteilte Versionskontrolle 
• GIT mag keine Netzlaufwerke 
• GIT vergisst nichts 
• Eigener Server (z.B. Atlassian) oder Github 
Keine Entwicklung ohne 
Versionskontrolle
Versions-verwaltung 
• Kein direkter Zugang der Entwickler zum 
Livesystem 
• Verschiedene kleine Repositories für 
Applikationen, kein grosses 
• Verschiedene Branches für unterschiedliche 
Server (Dev/Red/Web etc.) 
• Automatisches Deployment (Stash vor 
jedem Update) 
Keine Entwicklung ohne 
Versionskontrolle
Kein Update ohne Test 
Testing und Q&A 
Web1 
CDN 
Web2 
Redaktion 
GIT 
DEV 
Red 
Live 
Dev 
Q&A 
Web2 
Q&A 
Redaktion 
Q&A 
Web1 
Test
Testing und Q&A 
• Nichts kommt ohne Test auf das Livesystem 
• Q&A ist kein Test- sondern Kontrollsystem 
• Endabnahme neuer Funktionen durch den 
Kunden 
• Kopie der Live-Architektur 
• Automatisierte Rückspielung der Live-Daten 
• Eigener Branch 
Kein Update ohne Test
Bugtracking
Bugtracker 
Ticketing
Bugtracker 
Ticketing
Bugtracker 
Ticketing
Bereit zum Einsatz 
Fer tig 
Web1 
CDN 
Web2 
Redaktion 
GIT 
DEV 
Red 
Live 
Test 
Dev 
Q&A 
Web2 
Q&A 
Redaktion 
Q&A 
Web1
Applikations-entwicklung
Entwicklung 
• Zukunftssicherheit bei der Produkt / 
Framework- Wahl 
• Nach Möglichkeit Kommunikation über 
Webservices 
• Nie auf das Netz verlassen 
• Coldfusion - Frontend Funktionen 
(<cfmediaplayer> etc.) sind meist zu 
unflexibel 
Komfortfunktionen sind meist zu 
unflexibel
Entwicklung 
• Lokalisierung in CF ist unzureichend 
• Eigene Datumsformatierungen 
• Zeitzonen 
• Alternativfelder vorsehen 
• Andere Sprachen / Darstellungen 
berücksichtigen (RTL) 
Komfortfunktionen sind meist zu 
unflexibel
Multiser ver 
• Trennung von Front- und Backend 
• Nach Aussen nur benötigte Funktionen zur 
Verfügung stellen 
• User können auf unterschiedlichen Servern 
landen 
• Session Verlust berücksichtigen 
Nur das nötigste nach aussen zur 
Verfügung stellen
CDN 
• Von Anfang an mit planen 
• Möglichst viel statischer Content 
• Dynamische Daten nachladen 
• Nur Content laden, kein Layout 
• CDN kann als Cache genutzt werden 
• Content muss bei Änderung zum richtigen 
Zeitpunkt invalidiert werden 
CDN als Entlastung nutzen
Suche 
• Beim Aufbau mit planen 
• Dynamischer Content sollte direkt beim 
erzeugen gepusht werden 
• Dynamischer Content kann unnötige 
Einträge erzeugen (Filterung) 
Suche von Anfang an einplanen
Entwicklung / 
Testing 
• Realistische Datenbasis und Umgebung in 
der Entwicklung 
• Kein root! 
• Abläufe entkoppeln und parallelisieren 
(ActiveMQ etc.) 
• Dimensionen beachten 
• Sprachen beachten 
Eine realistische Testumgebung 
schaffen
Performance 
• Virtuelle Server lassen sich leicht bei RAM 
und CPU skalieren 
• Bottlenecks sind meist DB, Filesystem und 
Netzwerk 
• Nie auf das Netzwerk oder externe Systeme 
verlassen 
Filesystem und DB skalieren oft 
nur mit sehr grossem Aufwand
Club Mate and 
fritz-kola for free 
Come and see us
AND 
Oculus Rift 
Come and see us
Diese Folien und noch 
viel mehr gibt‘s unter 
www.bokowsky.net/de/knowledge-base/
Vielen Dank 
Matthias Proske 
proske@bokowsky.de 
Bokowsky + Laymann GmbH 
www.bokowsky.de 
@BokowskyLaymann 
sowie auf Facebook, Slideshare, YouTube, 
Flickr 
P.S: Bokowsky + Laymann sucht ColdFusion Entwickler 
Fest oder Frei. 
jobs@bokowsky.de oder im Social Network Ihres Vertrauens

ColdFusion im Enterprise Umfeld - Deep Dive

  • 1.
    ColdFusion im EnterpriseUmfeld ColdFusion im Enterprise Umfeld - Deep Dive CFCamp, Germering, 20. Oktober 2014 © Richard Carey, Fotolia.com
  • 2.
  • 3.
    Webserver Coldfusion Server Datenbank All-in-one-Ser ver Developer
  • 5.
  • 6.
    Content Management •Out-of-the-Box Features • Flexibilität (Framework) • Skalierbarkeit • Personalisierung • Web 2.0 • Staging • Usability • Zukunftssicherheit Ein professioneller Auswahlprozeß ist unerläßlich
  • 7.
    Web Redaktion /Staging Front-und Backend immer auf getrennten Servern Trennung von Front- und Backend
  • 8.
    Web Redaktion /Staging DB und CF-Server immer trennen DB-Server
  • 9.
    Web Redaktion /Staging Zur Ausfallsicherheit Datenbank immer replizieren Master-Slave- Replikation
  • 10.
    Mindestens zwei unabhängige Webserver Redaktion / Staging Web 1 Web 2 Webser ver
  • 11.
    Redaktion / Staging Web 1 Web 2 Webser ver Mindestens zwei unabhängige Webserver
  • 12.
  • 13.
    Coldfusion Cluster •Performance • Session Replikation aufwändig • unzuverlässiges Feature • Loadbalancer schon für den Webserver vorhanden • Vorteil in der Applikationsentwicklung begrenzt (Skalierung) Aufwand für ein Coldfusion Cluster lohnt sich nicht
  • 14.
    Loadbalancer mit StickySessions • skaliert besser • schneller • geringer Konfigurationsaufwand Aber: • Sessionverlust bei Ausfall • Applikationen müssen angepasst sein Loadbalancing über seperaten Loadbalancer ist oft einfacher
  • 15.
    Redaktion / Staging Web 1 Web 2 CDN Webser ver Mindestens zwei unabhängige Webserver
  • 16.
    Akamai • Serverüber die ganze Welt verteilt • Eigene Leitungen • Speichert alle statischen Objekte • Greift nur auf den Origin zu wenn Daten nicht vorhanden oder invalide • Sucht zuerst auf anderen EDGE-Servern • Webservice zum invalidieren CDN übernimmt die Last für statische Objekte
  • 17.
    Akamai • Kanndynamische Objekte in statische Seiten einbauen (SSI/ESI) • Kann auch dynamische Seiten speichern • Bietet Sureroutes für dynamischen Content CDN übernimmt die Last für statische Objekte
  • 18.
    Dedizierte Suche nimmtLast vom Applikationsserver Redaktion / Staging Web 1 Web 2 CDN Suche
  • 19.
    Externe Suche (Google) • Passiert sowieso • Verbraucht keine eigenen Ressourcen • Schlecht steuerbar (Zeit, Umfang, Ziel) • Google Layout • Indiziert dynamischen Content schlecht • Kann hohe Serverlast erzeugen Externe Suche ist nur eine Notlösung
  • 20.
    Interne Suche (Lucene) • Kostenlos • Unabhängig • Grosse Community • Kein Support • Zu wenige Sprachen • Schlechtes Stemming • Aufwändige Implementierung • User sind Google gewöhnt Lucene Einsatz verlangt Aufbau von Know-How
  • 21.
    Interne Suche (GSA) • Kann alle Sprachen • Stemming • Reaktion auf spezielle Codewörter • Drei Arten der Indizierung: Crawlen, Content Pushen, URL Pushen • Kann auch Datenbanken durchsuchen Google gibts auch für Zuhause
  • 22.
    Zeit was zuentwickeln Entwicklung Web1 CDN Web2 Redaktion
  • 23.
    Zeit was zuentwickeln Entwicklung Web1 CDN Web2 Redaktion DEV
  • 24.
    Zentrale Entwicklung •Instanzen auf einem Server • Vollständiger Content des Livesystems • Konfiguration entspricht dem Livesystem • Einheitliche Konfiguration !!! (komisch, bei mit gings...) • Zentrales Update, Backup etc. Einheitliche Entwicklungsumgebung für alle Entwickler schaffen
  • 25.
    Zeit was zuentwickeln Entwicklung Web1 CDN Web2 Redaktion GIT DEV Red Live Dev
  • 26.
  • 27.
    Versions-verwaltung • FrüherSVN / CVS, heute GIT / Mercurial • Verteilte Versionskontrolle • GIT mag keine Netzlaufwerke • GIT vergisst nichts • Eigener Server (z.B. Atlassian) oder Github Keine Entwicklung ohne Versionskontrolle
  • 28.
    Versions-verwaltung • Keindirekter Zugang der Entwickler zum Livesystem • Verschiedene kleine Repositories für Applikationen, kein grosses • Verschiedene Branches für unterschiedliche Server (Dev/Red/Web etc.) • Automatisches Deployment (Stash vor jedem Update) Keine Entwicklung ohne Versionskontrolle
  • 29.
    Kein Update ohneTest Testing und Q&A Web1 CDN Web2 Redaktion GIT DEV Red Live Dev Q&A Web2 Q&A Redaktion Q&A Web1 Test
  • 30.
    Testing und Q&A • Nichts kommt ohne Test auf das Livesystem • Q&A ist kein Test- sondern Kontrollsystem • Endabnahme neuer Funktionen durch den Kunden • Kopie der Live-Architektur • Automatisierte Rückspielung der Live-Daten • Eigener Branch Kein Update ohne Test
  • 31.
  • 32.
  • 33.
  • 34.
  • 35.
    Bereit zum Einsatz Fer tig Web1 CDN Web2 Redaktion GIT DEV Red Live Test Dev Q&A Web2 Q&A Redaktion Q&A Web1
  • 36.
  • 37.
    Entwicklung • Zukunftssicherheitbei der Produkt / Framework- Wahl • Nach Möglichkeit Kommunikation über Webservices • Nie auf das Netz verlassen • Coldfusion - Frontend Funktionen (<cfmediaplayer> etc.) sind meist zu unflexibel Komfortfunktionen sind meist zu unflexibel
  • 38.
    Entwicklung • Lokalisierungin CF ist unzureichend • Eigene Datumsformatierungen • Zeitzonen • Alternativfelder vorsehen • Andere Sprachen / Darstellungen berücksichtigen (RTL) Komfortfunktionen sind meist zu unflexibel
  • 39.
    Multiser ver •Trennung von Front- und Backend • Nach Aussen nur benötigte Funktionen zur Verfügung stellen • User können auf unterschiedlichen Servern landen • Session Verlust berücksichtigen Nur das nötigste nach aussen zur Verfügung stellen
  • 40.
    CDN • VonAnfang an mit planen • Möglichst viel statischer Content • Dynamische Daten nachladen • Nur Content laden, kein Layout • CDN kann als Cache genutzt werden • Content muss bei Änderung zum richtigen Zeitpunkt invalidiert werden CDN als Entlastung nutzen
  • 41.
    Suche • BeimAufbau mit planen • Dynamischer Content sollte direkt beim erzeugen gepusht werden • Dynamischer Content kann unnötige Einträge erzeugen (Filterung) Suche von Anfang an einplanen
  • 42.
    Entwicklung / Testing • Realistische Datenbasis und Umgebung in der Entwicklung • Kein root! • Abläufe entkoppeln und parallelisieren (ActiveMQ etc.) • Dimensionen beachten • Sprachen beachten Eine realistische Testumgebung schaffen
  • 43.
    Performance • VirtuelleServer lassen sich leicht bei RAM und CPU skalieren • Bottlenecks sind meist DB, Filesystem und Netzwerk • Nie auf das Netzwerk oder externe Systeme verlassen Filesystem und DB skalieren oft nur mit sehr grossem Aufwand
  • 44.
    Club Mate and fritz-kola for free Come and see us
  • 45.
    AND Oculus Rift Come and see us
  • 46.
    Diese Folien undnoch viel mehr gibt‘s unter www.bokowsky.net/de/knowledge-base/
  • 47.
    Vielen Dank MatthiasProske proske@bokowsky.de Bokowsky + Laymann GmbH www.bokowsky.de @BokowskyLaymann sowie auf Facebook, Slideshare, YouTube, Flickr P.S: Bokowsky + Laymann sucht ColdFusion Entwickler Fest oder Frei. jobs@bokowsky.de oder im Social Network Ihres Vertrauens