Dank vieler praktischer Funktionen können Entwickler unter ColdFusion relativ schnell und einfach Applikationen entwickeln und produktiv einsetzen. Doch wie sieht es aus wenn diese Applikationen dann intensiv genutzt werden? Von hunderttausenden Usern in unzähligen Ländern, Sprachen und Zeitzonen? Wenn Inhalte laufend generiert und abgefragt werden? Dieser Talk zeigt, wie ColdFusion in einem Enterprise Projekt eingesetzt werden kann. Welche Architektur für einen sicheren Betrieb rund um die Uhr und die Welt benötigt wird. Welche ColdFusion Enterprise-Funktionen gebraucht werden und welche nicht, welche überhaupt funktionieren, welche Lektionen wir im praktischen Einsatz gelernt haben und warum Optimierungen im Milisekunden-Bereich tatsächlich Tage sparen können.

1. ColdFusion im Enterprise Umfeld
ColdFusion im Enterprise Umfeld - Deep Dive
CFCamp, Germering, 20. Oktober 2014
© Richard Carey, Fotolia.com

2. Coldfusion
Configuration
-Star ter Edition-

3. Webserver
Coldfusion Server
Datenbank
All-in-one-Ser ver
Developer

5. Content
Management System
(CMS)

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. Clustering

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
Sticky Sessions
• 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
• 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

18. Dedizierte Suche nimmt Last
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 zu entwickeln
Entwicklung
Web1
CDN
Web2
Redaktion

23. Zeit was zu entwickeln
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 zu entwickeln
Entwicklung
Web1
CDN
Web2
Redaktion
GIT
DEV
Red
Live
Dev

26. Versionsverwaltung

27. 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

28. 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

29. 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

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. Bugtracking

32. Bugtracker
Ticketing

33. Bugtracker
Ticketing

34. Bugtracker
Ticketing

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. Applikations-entwicklung

37. 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

38. Entwicklung
• Lokalisierung in 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
• 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

41. 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

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
• 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

44. Club Mate and
fritz-kola for free
Come and see us

45. AND
Oculus Rift
Come and see us

46. Diese Folien und noch
viel mehr gibt‘s unter
www.bokowsky.net/de/knowledge-base/

47. 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