DevOps Einstieg Microservices

Den Gipfel des Hype-Zyklus lassen sie so langsam hinter sich. Cool, am Markt gefragt, und grundsätzlich relevant sind Microservices aber allemal noch. Sie als Ursache für das Öffnen der Büchse der Pandora auszumachen greift allgemein sicher zu kurz. Im Folgenden sollen sie exemplarisch zu Illustrationszwecken dienen.

Das Streben nach Agilität und Skalierbarkeit sollten wesentliche Motivation für den Einsatz von Microservices sein. Aber warum ist diese Architektur so disruptiv und oft auch so unerwartet teuer?

Ein kleiner Teil der Antwort auf diese Frage ist einfach: Microservices sind eine Software Architektur. Diese zu ändern ist “per Definition” schon aufwendig ?. Vermutlich wird aber auch niemand ernsthaft behaupten das eine Migration hin zu Microservices oder weg zum Monolithen günstig ist.

Microservices bringen ein erhebliches Maß an neuer Komplexität mit sich.

Obacht : Komplexität!

Fools ignore complexity. Pragmatists suffer it. Some can avoid it. Geniuses remove it.

Alan Perls

Komplexität ist allgemein maßgeblicher Treiber für viele Dinge, die wir heute tun. Unter anderem löst sie Kontrollverlust aus – und Angst davor.

Aber was ist Komplexität eigentlich?

Nicht-Linearität ist eine äußerst unangenehme Eigenschaft von komplexen Systemen. Kleine Änderungen können unvorhersehbar große Wirkung bedingen. Oft sind auch kausale Feedback Schleifen im Spiel. Wir beobachten Verhalten welche wir mit Paradigmen wie Reduktion und Analyse nicht erklären können.

Im Kontext von Software Systemen betrachtet Brooks in No Silver Bullet Komplexität. Er unterscheidet zwischen Essentieller (Inhärenter) und Versehentlicher. Moseley und Marks folgen Brooks bei dieser Unterscheidung in Out of the tarpit. Sie widersprechen ihm aber in der Aussage das die meiste Komplexität in heutigen Systemen essentieller Natur ist. Sie definieren den Begriff nicht, sagen aber dass es Komplexität ist was Software Systeme schwer verständlich macht – insbesondere Zustand und Kontroll-Fluss. Ferner stellen sie fest, dass Abhängigkeit vom Code Volumen nicht linear ist. Helfen uns diese Sichtweisen Microservices besser zu verstehen? Betrachtet man das erste Gesetz “Don’t!” von verteilten Objekten, so erscheinen sie als versehentliche Komplexität (weil fachlich in der Regel irrelevant) die wir vermeiden sollten. Sind es lediglich die technischen Prozess Grenzen welche uns Schwierigkeiten bereiten?

Container als Wirt dieser technischen Prozesse sind zweifellos elementarer Baustein von Microservices der sehr viele Konsequenzen mit sich bringt. Container ändern technisch … alles. Es sind flüchtige Entitäten welche über traditioneller Infrastruktur mit einem hochdynamischen Overlay Netzwerk kommunizieren. Der Vergleich mit dem menschlichen Organismus ist durchaus angemessen (Video einmal starten und eine Minute schauen!):

Wie weitreichend die Folgen sind wird deutlich, wenn man einen Blick auf die Cloud Native Landschaft wirft und sich dabei vergegenwärtigt, dass Kubernetes erst vor gut fünf Jahren freigegeben wurde. Und die Entwicklungen im Epizentrum der digitalen Transformation sind ungebremst rasend schnell.

Man sollte reflektieren, ob eine Einführung im konkreten Fall die Organisation ihrem Ziel überhaupt einen Schritt näher bringt, oder ob es womöglich sogar eine Regression werden könnte. Der Artikel Choose Boring Technology bietet viele Denkanstöße aus einer holistischen Perspektive.

Agile zur Rettung!

Warum nochmal tun wir uns Microservices an? Agilität, stimmt ja. Wir wollen schließlich schneller als der Wettbewerb am Markt sein. Helfen Container da wirklich? Für den Moment sieht es so aus, als ob sie vor allem versehentliche Komplexität bringen. Die Antwort auf Komplexität kennen wir inzwischen ja auch – Agile Methoden. Hä? Müssen wir agil sein, um mit komplexen Microservices klar zu kommen? Ja. Mag seltsam klingen aber Geschwindigkeit und Stabilität schließen sich eben nicht aus sondern bedingen einander. Die Schere zwischen Low- und High Performern geht auseinander. Agiles Vorgehen war was nochmal? Im Allgemeinen Probe, Sense, Respond. Konkret im IT-Umfeld manifestiert es sich seit 20 Jahren(!) im Agile Manifesto oder den drei DevOps Prinzipien. Setzen wir diese Werte um? Experimentieren wir? Können wir mit Scheitern umgehen? Praktizieren wir Retrospektiven? Gibt es (ehrliches) Feedback? Gehen wir wertschätzend miteinander um? … Optimieren wir mit Blick auf das große Ganze? Sind unsere Teams … selbstorganisiert? Warum tun wir uns mit diesen Dingen so schwer?

Kultur

Unser ökonomisches und gesellschaftliches Umfeld wird getrieben durch Dinge wie Digitalisierung zunehmend komplexer, Dinge ändern sich immer schneller. Agilität wird folglich existentieller. Agilität und Organisationskultur bedingen einander. Kultur (=Wertesystem) entwickelt sich aber mit der Dynamik einer Wanderdüne.

Welche Werte sollten eine agile Organisation prägen?

In enger Anlehnung an Spiral Dynamics betrachtet Frederic Laloux in Reinventing Organizations die Entwicklung von Organisationen mit ihrem Wertesystemen. Komplexität ist entscheidender Treiber bei diesen Entwicklungen. Die am höchsten entwickelte Stufe (Türkis / Evolutionär) ist gekennzeichnet durch Selbstorganisation, Holismus (in den DevOps Prinzipien reflektiert durch den ersten Weg – Systems Thinking) und verteilter Führung. Laloux nutzt hier die Metapher Organismus. In türkisen Organisationen finden wir Systemverhalten wie beim Atmen oder bei … Microservices. Natürlich ist Spiral Dynamics nur ein Modell. Insofern ist eine Organisation auch nicht genau an einer Stelle. Man versteht die Verortung einer Organisation besser als den Schwerpunkt ihrer Entwicklung.

Fun fact: Kollektive wie Teams und auch ganze Organisationen selbst sind außerordentlich komplexe Systeme. Genau deswegen bieten sich auch hier agile Methoden für die Entwicklung an. Die Spielregeln sind natürlich ein wenig anders, weil man nur eine Instanz hat (In der Regel also z.B. kein Test-System). ?

Besonders bemerkenswert erscheint, dass die stärksten Hebel für Veränderung in System-Thinking sich aus elementaren Eigenschaften von Systemen ableiten lassen. Kultur hat signifikant stärkeren Einfluss als Kommunikation von Menschen und/oder Maschinen (Automatisierung). Außerdem besteht offensichtlich eine enge Beziehung zwischen dem “speziellen” Gesetz von Conway mit dem “allgemeinen” Eisberg Modell aus System Thinking: (Kommunikations-)Strukturen generieren Ereignis-Muster und so auch konkrete von einer Organisation produzierte Software.

Resilience

COVID-19, Klimawandel oder die Ausfälle bei AWS oder Google in den letzten zwei Monaten. Eine Tatsache, der man sich stellen sollte – “Organismen erkranken”. Entscheidend ist ein möglichst milder Verlauf (Resilience).

Manche Krankheiten wie z.B. der Solarwinds-Hack werden mit böswilliger Absicht herbeigeführt. Kubernetes wurde in der Vergangenheit mehrfach mit einem trojanischen Pferd der großen Tech Firmen verglichen. Ob man die Analogie hier bis zur beabsichtigten Infektion und Erkrankung des Wettbewerbs durch einen Virus treiben möchte bleibt der Fantasie des Lesers überlassen ?.

Ist DevOps also eine technische Herausforderung? Zweifellos, aber Einschränkung auf Entwicklung und Betrieb von Software ist sicherlich viel zu kurz gedacht. Und der technische Aspekt ist vermutlich der einfachere Teil.

Update 11.11.2021: Der aktuelle Artikel Complexity is killing software developers ist in diesem Kontext auf jeden Fall lesenswert (“modern software development is a study in entropy, and it is not getting any more simple.” – 2. Hauptsatz der Thermodynamik – Physik ist keine Verhandlungssache ?)

Der Beitrag Microservices, Cloud, Software und DevOps sind Implementierungsdetails erschien zuerst auf CONTENTREICH.

Wir reden von Agile, DevOps, Komplexität. Im Großen sicher nicht, aber haben wir im Kleinen, also innerhalb einer Organisation oder eines Teams ein gemeinsames Verständnis von den Begriffen welche wir täglich nutzen?

Platform: Wir kennen den Begriff aus dem Umfeld von Betriebssystemen (Cross-Plattform) und (Enterprise-)Laufzeitumgebungen (Java Platform, Java Enterprise Edition). Wir verstehen eine Platform als etwas Horizontales “Nicht-Funktionales”. Was ist es im Kontext von Kubernetes?

Eine Kubernetes Application Platform sollte Container basierte Anwendungen/Microservices also unterstützen in den Disziplinen

• Observability
• Authentication / Authorization
• Networking
• Key Management
• Storage (Block, Object, File)
• Databases (Relational, Key-Value, Document, Graph)
• Continuous Integration/-Delivery
• Backup/Recovery
• Messaging

Konzeptionell ist vieles nicht neu. Container bedingen allerdings viele neue Implementierungen:

Die Open Source Upstream Basis Komponenten lassen aus Sicht von Anwendungs-Entwicklern, im Folgenden kurz Entwickler (!= Infrastruktur- / Platform Entwickler) offensichtlich noch sehr zu wünschen übrig. Aus Sicht von Entwicklern ist es schlicht eine zu niedrige Abstraktion. Man merkt es spätestens wenn man versucht mit kubectl zu arbeiten.

• Muss jeder Entwickler wirklich wissen was ein Deployment, StatefulSet, DeamonSet, Pod, Service, ConfigMap, Secret, PersistentVolume(Claim) etc. sind und wie man damit umgeht?
• Muss man wissen was ein Controller, eine CustomResourceDefinition oder ein Operator ist und wie diese Dinge arbeiten?
• Muss man sich den Kopf darüber zerbrechen ob man imperativ oder deklarativ mit kubectl arbeiten sollte?

Ich denke nein. Ich würde sogar soweit gehen zu sagen man sollte Anwendungsentwicklern Kubernetes komplett ersparen können.

Was will ein Anwendungsentwickler eigentlich wirklich von einer Platform? PaaS Anbieter haben sich ausgiebig mit dieser Frage beschäftigt. Zwar nicht Kubernetes, aber schauen wir exemplarisch einfach einmal auf die CLI Hilfe von heroku:

USAGE
  $ heroku [COMMAND]

COMMANDS
  access          manage user access to apps
  addons          tools and services for developing, extending, and operating your app
  apps            manage apps on Heroku
  auth            check 2fa status
  authorizations  OAuth authorizations
  autocomplete    display autocomplete installation instructions
  buildpacks      scripts used to compile apps
  certs           a topic for the ssl plugin
  ci              run an application test suite on Heroku
  clients         OAuth clients on the platform
  config          environment variables of apps
  container       Use containers to build and deploy Heroku apps
  domains         custom domains for apps
  drains          forward logs to syslog or HTTPS
  features        add/remove app features
  git             manage local git repository for app
  help            display help for heroku
  keys            add/remove account ssh keys
  labs            add/remove experimental features
  local           run Heroku app locally
  logs            display recent log output
  maintenance     enable/disable access to app
  members         manage organization members
  notifications   display notifications
  orgs            manage organizations
  pg              manage postgresql databases
  pipelines       manage pipelines
  plugins         list installed plugins
  ps              Client tools for Heroku Exec
  psql            open a psql shell to the database
  redis           manage heroku redis instances
  regions         list available regions for deployment
  releases        display the releases for an app
  reviewapps      manage reviewapps in pipelines
  run             run a one-off process inside a Heroku dyno
  sessions        OAuth sessions
  spaces          manage heroku private spaces
  status          status of the Heroku platform
  teams           manage teams
  update          update the Heroku CLI
  webhooks        list webhooks on an app

Openshift, Garden, Rio, Tilt und Jenkins X sind in diesem Sinne vergleichbare Produkte für Kubernetes. Sie alle sind deutlich näher an den Bedürfnissen von Entwicklern und versuchen Kubernetes mehr oder weniger “verschwinden” zu lassen. Jenkins X gefällt mir persönlich sehr gut weil sehr ausgereifte Kubernetes CI/CD Workflows für nahezu alle Laufzeitumgebungen git gesteuert out of the Box zur Verfügung stehen. Wer nicht mag sollte sich nicht mehr mit Kubernetes rumschlagen müssen. Zugegeben: On-Prem oder in Nischen Clouds ist Jenkins X heute kein Selbstgänger.

Was macht ein Platform Team?

Grundsätzlich wird ein dediziertes Platform Team erst ab einer gewissen Größe einer Organisation und Menge von Anwendungen Sinn machen. Primäre Aufgabe dieses Teams sollte es sein Entwicklern das Arbeiten mit der Platform so einfach wie möglich zu gestalten – sie sollten sich schließlich auf die Umsetzung der Anforderungen ihrer Kunden (der Business-Units) fokussieren.

In einer reifen Cloud-Umgebung “verschwinden” viele Aspekte der Platform-Komplexität (“Fools ignore complexity. Pragmatists suffer it. Some can avoid it. Geniuses remove it.”). Man selbst hat nur noch wenig Arbeit mit diesen Dingen weil der Cloud (Platform) Provider gut genug war sie verschwinden zu lassen ??. Otto beschreibt seinen Weg auf AWS und Erfahrungen im Kontext Platform im Post OTTO goes AWS – Teil 2.

Wie geht man mit einer Situation um wo man es mit einer weniger ausgereiften Umgebung zu tun hat? Wo gewisse essentielle Dienste womöglich fehlen? Sollte man selbst implementieren? (Und betreiben? Und langfristig warten?)

Pauschal kann man diese Fragen natürlich nicht beantworten. Ich denke man sollte vor allem ehrlich mit sich selbst sein und eigene Fähigkeiten nicht überschätzen bzw. Komplexität unterschätzen (Nerds neigen dazu). Ein guter Anwendungs-Entwickler ist noch lange kein guter Infrastruktur- oder Platform-Entwickler (Was ist eigentlich ein DevOps Engineer?)

In jeden Fall sollte man sich Zeit für ein gemeinsames Verständnis der Begriffe und Klarheit in Bezug auf Verantwortung nehmen.

Von autonomen Vertikalen haben wir inzwischen ein relativ gutes Verständnis. Wie in so einem Umfeld horizontale Plattform Dinge langfristig funktionieren scheint deutlich unklarer – insbesondere in Bezug auf die erforderlichen Strukturen in der Organisation und Planung. Make Boring Plans bietet viele wertvolle Anregungen Kontext Plattform.

Der Beitrag Was ist eine Kubernetes Platform? erschien zuerst auf CONTENTREICH.

Es war einmal eine Software Schmiede. Sie hat immer alles selbst gemacht. Eines Tages stellte sich eine neue Herausforderung. Ein Projekt. Umfangreiche Funktionalität war gefordert. Der Rat der Weisen beschloss es dieses mal anders zu machen und sich im Internet nach einem Open Sauce Produkt umzuschauen. Das Gröbste sollte es doch fertig irgendwo zum Download im Internet geben.  Es dauerte nicht lang, da wurde man fündig. Die Würfel waren gefallen. Aber wer kennt sich damit aus? Man schaute sich weiter um. Dieses mal nach einem Dienstleister. Man wurde fündig. Der Plan war einfach. Der Dienstleister gibt Starthilfe, übergibt und verabschiedet sich dann. Dieses Vorgehen hatte sich in der Vergangenheit bewährt. Die Erben aus den Disziplinen Dev und Op wurden auserkoren.

Die Stimmung war sehr gut. Man freute sich auf ein neues Abenteuer. In der Startformation schien es als würde man die wichtigsten Werte Transparenz und Vertrauen teilen. Funktional schien alles überschaubar und klar. Die Herausforderung würde Skalierbarkeit und Verfügbarkeit werden. Das war auch klar. Zum Glück war da dieses Wundermittel am Horizont – Container. Alle machen das so. Die Funktionalität hatte der Dienstleister ruck zuck umgesetzt und man tütete den Code in diese Container ein. Proof of concept … ?.

Die Komponente des Dienstleister offerierte eine API welche auch von den ernannten Erben beim Kunden genutzt werden sollte. Bei der Abstimmung gab es Groll. Unter anderem weil man sich beim Format nicht so richtig entscheiden konnte zwischen XML und JSON. Da das Open Source Produkt und Tools wie Open API REST und JSON präferieren beugte man sich, bestand aber aus Legacy Gründen darauf XML zu nutzen. Wenn man XML Base64 kodiert bekommt man es schließlich auch in JSON verpackt. Eine Diskussion um die Relevanz von Zeichensätzen im Zusammenhang mit der API schließlich erzeugte eine merkliche Abkühlung der Stimmung zwischen Dienstleister und Dev Erben – vielleicht ein Schlüsselmoment.

Akzeptanz

Allen Bemühungen des Projekt Owner zum trotz distanzierten sie die Dev-Erben. Kommunikation war nur noch sehr schwer möglich. Die Anwendung reflektierte dies und belegte das Gesetz von Conway auf eindrucksvolle Art und Weise. State Management und Hochverfügbarkeit wurden in einer Facade Schicht über der vom Dienstleister implementierten Komponente noch einmal implementiert. Richtung Geschäftsführung wurde kommuniziert das es läuft und das die Arbeit des Dienstleisters sich an einem Wochenende erschließen werde. Java programmieren kann ja auch nicht anders sein wie C#, Linux ist wie Windows und dieses Produkt kann ja auch kein Hexenwerk sein. Von nun an betrachteten die Dev-Erben das Treiben des Dienstleisters aus sicherer Entfernung und forderten regelmäßig Dokumentation. Diese Forderung nach Dokumentation sollte zum Running Gag werden. Beim Dienstleister machte sich der Verdacht breit das die Erben nicht so ganz hinter den Grundsatzentscheidungen des Projektes standen…

Unbeirrt implementierte der Dienstleister wie abgestimmt “Standard nach Gebrauchsanweisung aus dem Internet”. Insofern schien es konsequent und angebracht auf die hervorragende Dokumentation der jeweiligen Projekt-Maintainer zu verweisen und im Detail nur auf das einzugehen was man selbst Implementierte. Weil zwischenzeitig von Formaten wie Word die Rede war, und weil das bis dato gelieferte Markdown offensichtlich nicht auf Gegenliebe stieß ergänzte man mit gedruckter Literatur – offensichtlich aber auch vergebens.

Noch eine Kleinigkeit

Funktional war alles im grünen Bereich. Da war nur noch diese Geschichte mit der Skalierbarkeit und der Verfügbarkeit. Der Hersteller des Fundamentes signalisierte volles Commitment zu diesem Kubernetes. Man konnte den Elefanten im Raum nicht ignorieren. Der eine oder andere witterte … Komplexität – und Mangel an Ressourcen dieser Komplexität Herr zu werden. Glücklicherweise signalisierte der Kunde, dass Kubernetes längst beschlossene Unternehmensstrategie ist und das man damit schon rund zehn Projekte am Start hat. Dem Ersuchen von Kooperation und der Gründung eine Selbsthilfegruppe wurde vom Management eine Absage erteilt. Dem Dienstleister stelle man ein paar mit kubeadm bestückte On Prem Linux VMs und den Rest solle er dann alleine machen und dokumentieren. Den Dienstleister beschlich das Gefühl er werde ein Weilchen aus dem Feuerwehrschlauch trinken müssen. Weil er durstig war willigte er ein, beschloss aber auch ein unmissverständliches Signal zu senden was Kubernetes aus seiner Sicht bedeutete: DevOps!

Der Cloud Markt ging durch die Decke. Kubernetes stand als “Fastest moving project in Open Source history” mit DevOps DNA im Epizentrum. Ein gewisses Mindset erschien sachdienlich.  Alle Beteiligten wurden zu einer Präsentation zusammengetrommelt ?. Auf der ersten Folie stand da nun eben dieses Wort: DevOps. Und dessen Essenz von Wikipedia. Eigentlich sollte es ja nicht der Rede wert gewesen sein. Machten ja auch alle – wie Agile. Vielleicht wäre es besser gewesen der Dienstleister hätte es anders illustriert.  Die Erben jedenfalls schienen unbeeindruckt und tiefenentspannt. Das Feedback unmittelbar nach dem Vortrag bestand im Wesentlichen aus Schweigen. Was am Tag drauf schriftlich kam erschien wie eine Lücke. Dem einen erschien sie als Spalt, dem anderen als Schlucht. Der Dienstleister begann sich Sorgen zu machen was an Kommunikation mit den Dev-Erben überhaupt möglich ist solange offensichtlich komplett unterschiedliches Verständnis bei grundlegenden Begriffen besteht.

Mit Projektleitung und Ops immerhin schien man zu einem gemeinsamen Verständnis zu kommen. Man orientierte sich an einschlägiger Literatur wie Projekt Phoenix, Accelerate oder Reinventing Organisations. Dev und Management sahen keine Notwendigkeit zu Begriffsklärung.

Alternative Fakten

Sobald das Wort DevOps in einem gewissen Personenkreis ausgesprochen war wurde versichert das es bereits implementiert ist. Werkzeuge waren ja gekauft. Und dieses Wort war ja auch in Namen eines Produktes! Alle Symptome jedoch deuteten auf das Gegenteil hin. Misstrauen war allgegenwärtig.

Im Bestreben Werte und Kultur des Kunden zu verstehen studierte er was das Unternehmen im Internet publizierte. “Mitarbeiter Zentrum des Erfolges … modernste Technik … stetig fördern … Innovation … Cloud … aktuelle Methoden … agile  … Scrum … familiär …” – das klang alles vernünftig, reflektierte aber in keinster Weise die Beobachtungen. Es fing schon bei Agile an:

Wir erschließen bessere Wege, Software zu entwickeln,indem wir es selbst tun und anderen dabei helfen. Durch diese Tätigkeit haben wir diese Werte zu schätzen gelernt:

• Individuen und Interaktionen mehr als Prozesse und Werkzeuge

• Funktionierende Software mehr als umfassende Dokumentation

• Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung

• Reagieren auf Veränderung mehr als das Befolgen eines Plans

Die Gestalt der Organisation erschien wie Modell Wolfsrudel mit Ambitionen auf Maschine. Was ging hier vor sich? Vor dem Hintergrund das man gewohnt war alles selbst zu machen hatte man vielleicht auch den Begriff DevOps selbst neu definiert, passend zum Unternehmen transformiert, und so alternative Fakten geschaffen? In jeden Fall entstand der Eindruck das die Leute zutiefst überzeugt von dem waren was sie sagten. Der Dienstleister malte sich Szenario Vorstellungsgespräch mit einem Bewerber aus der fragt ob im Unternehmen DevOps praktiziert wird …

Infrastruktur und Plattform

Was soll’s, das Ergebnis würde am Ende hoffentlich überzeugen. Abstimmung mit Op im Kontext Platform und Infrastruktur gestalteten sich glücklicherweise unkomplizierter. Es gab hier sehr viele Aufgaben die zwingend vor Launch angegangen werden mussten: Observability, Logging, Monitoring, Alerting, Storage, CI/CD, Lifecycle/Auditing of all things – und so. Man beschloss die Disziplinen Chaos Engineering und Sec zu vertagen. Es erschien sinnvoll diese Dinge selbst “from Scratch” bottom up zu durchleiden – zumindest wenn man die Absicht hat sie diese Themen selbst langfristig umzuhängen statt eine schlüsselfertige Kubernetes Lösung zu nutzen. Nach etwa einem Jahr hatte der Dienstleister all die Dinge in Abstimmung mit Projekt Owner und Op-Erben in Open Source On Prem umgesetzt.

Dev implementierte Last-Tests. Wenn der Begriff Chaos Engineering noch frei gewesen wäre hätte man die Durchführung dieser Tests durchaus so bezeichnen können …

Dem dringenden Ersuchen des Projekt Owners jemand Erfahrenes aus der Belegschaft im Projekt einzubinden wurde von der Geschäftsführung stattgegeben. Erfahrung ist aber relativ. Auf den einen oder anderen wirkte diese Maßnahme wie ein Placebo. Zumal der neue Kubernetes erfahrene Mann des Kunden sich für Historie und Quellcode der Projektes, Präsentation und auch Kubernetes selbst augenscheinlich nicht die Bohne interessierte.

Plattform Battle

Technisch war nicht alles perfekt aber es gab Fälle die liefen. Wegen “Not invented here” und der nach wie vor schwierigen Kommunikation mit den Dev-Erben entschloss sich das Management für ein Battle. Die eigene Mannschaft sollte selbst auch nochmal ihre Kubernetes Plattform bauen. Entwickler sind ja schließlich Entwickler. Anwendung, Infrastruktur oder Plattform – spielt doch keine Rolle – same same. Die bessere Lösung würde dann produktiv gehen. Management setzte Doomsday. Formal sollte Doomsday “alles” an den Kunden übergeben werden. Abgesehen von der Kubernetes-Plattform Implementierung waren die Gewerke des Dienstleisters zu diesem Zeitpunkt bereits seit etwa einem Jahr dokumentiert, der Quellcode stand stets offen. Infrastruktur und Plattform wurde wie in der Präsentation skizziert umgesetzt.

Team Kunde legte mit der Präsentation seiner Lösung vor. Für die Pipelines wählte man anders als der Dienstleister natürlich das Produkt was man schon seit Jahren lizenziert im Haus hatte. Man demonstrierte einen CI Build und zeigte ein System-Diagramm. Das CI System schien abgesehen von der Erzeugung eines Images nicht besonders auf das Kubernetes Umfeld einzugehen.

Die Präsentation des Dienstleisters zeigte ebenfalls ein System-Diagramm und durch Commits ausgelöste Builds und Deployments mit dem auf Kubernetes spezialisierten System aus der Präsentation. Er bemühte sich abermals auf fundamentale Dinge wie deklarativen Infrastruktur Code einzugehen – Reconciliation, GitOps, Pets und Cattle, Automatisierung und so. Das Szenario Pizza selbst backen bzw. von Kubernetes backen lassen illustrierte den Unterschied zwischen imperativ und deklarativ. Von Bedeutung schienen der Entwicklungsabteilung diese Dinge nicht. Wenn alle mit Admin Rechten und Tool der Wahl imperativ deklarativ arbeiten würde das wohl gut gehen.

Der Projekt Owner wählte das System des Dienstleisters für den Livegang.  Nennenswerte Zwischenfälle gab es in Produktion bis auf weiteres erst einmal keine. Für die Entwicklungsabteilung stand dennoch fest: Die eigene Implementierung muss die des Dienstleisters ablösen weil “Not invented here” und auch eine Frage der Ehre. Befindlichkeiten bestimmten schon lange das Handeln.

Erwachet!

In Bezug auf den Begriff DevOps erhielt der Dienstleister unerwartet eine Mail eines Managers. Im Anhang war ein Zeitungsartikel welcher “Aspekte von DevOps im C# Umfeld” beleuchten sollte mit einem “spannenden Abschnitt zur Reduktion von Komplexität”. Der Dienstleister nahm Stellung. Inbesondere brachte er zum Ausdruck, das es nach seinem Verständnis sehr viel bedeutendere Themen an der Basis gebe über die man sich verständigen sollte – Dinge die auch in dem Artikel angesprochen wurden: “Kultur der Zusammenarbeit” und “Digitale Transformation”.

Der Dienstleister entschied sich einen letzten Versuch zu unternehmen dem Unternehmen die Bedeutung von DevOps näher zu bringen. Er schickte dem Kunden eine handvoll T-Shirts “DevOps – Deploying Services since 2000”. Anschließend verfasste er eine vertrauliche Mail an die Geschäftsführung. Er wies insbesondere darauf hin, dass essentielle Dinge wie Kubernetes und dessen Grundlage DevOps in akuter Gefahr schienen nachhaltig im Unternehmen zu scheitern. Er untermauerte mit Fakten.

Die Reaktion der Geschäftsführung ließ nur den Schluss zu das bis auf weiteres alles bleiben wird wie es ist ???. Das Haus brennt aber man sah keine Notwendigkeit etwas zu unternehmen. Es blieb unklar blieb ob man das Issue nicht sah oder nicht sehen wollte. Immerhin birgt “Raus aus Komfortzone und alles anders” ja auch das eine oder andere Risiko und die Zahlen in Excel waren zu diesem Zeitpunkt vielleicht noch nicht rot genug. Game over?

PS: Im Kontext Kubernetes gibt es eine wundervolle Failure Story Sammlung. Gibt es eine vergleichbare Sammlung im Kontext “Digitale Transformation”? Mit so Geschichten wie Die Lufthansa steckt in der Digitalfalle?

Der Beitrag Eine etwas andere DevOps Transformation erschien zuerst auf CONTENTREICH.

tl;dr: Check yourself before you wreck yourself!

Cloud Computing

Public Cloud Computing war 2018 ein USD 182 Mrd. USD Markt. Gartener erwartet bis 2022 weiter starkes Wachstum. Vor diesem Hintergrund also kein Wunder das man heute beim Wettbewerb der Giganten Amazon, Microsoft Google und IBM von Cloud Wars spricht – aktuelles Schlachtfeld unter anderen On-Premise/Hybrid. Trends der einzelnen Segmente findet man u.a. im Gartner Hype Cycle for Cloud Computing, 2018. Weiterhin prognostiziert Gartner, dass viele Softwarehersteller bis zum Jahr 2020 “Cloud-first”-Strategien durch “Cloud-only“ ersetzen

Konkret heißt das für Anwender:

Organizations that do not have a high-level cloud strategy driven by their business strategy will significantly increase their risk of failure and wasted investment. (David W. Cearley, Vice President and Gartner Fellow, Gartner Research)

Traditionell dient Datenschutz in Europa oft als Totschlag-Argument gegen die Public Cloud. Ich bin kein europäischer Datenschützer und ich möchte hier auch nicht auf das Thema eingehen. Denjenigen welchen das Thema am Herz liegt finden vielleicht Antworten in den Success Stories OTTO goes AWS – Teil 1 , OTTO goes AWS – Teil 2 oder der Keynote “From COBOL to Kubernetes: A 250 Year Old Bank’s Cloud-Native Journey”.

Um schnell ein grobes Gefühl für das aktuelle High-End im Cloud Computing zu bekommen kann man einen Blick auf das obere Ende der Skala – also auf die Produkte des Marktführers Amazon Cloud werfen.

Cloud Native

Cloud Native ein essentieller Begriff im Kubernetes Kontext:

Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach.

These techniques enable loosely coupled systems that are resilient, manageable, and observable. Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil.

The Cloud Native Computing Foundation seeks to drive adoption of this paradigm by fostering and sustaining an ecosystem of open source, vendor-neutral projects. We democratize state-of-the-art patterns to make these innovations accessible for everyone. (Definition 1.0)

In diesem wenigen Worten steckt so unglaublich viel, dass an dieser Stelle nur ganz kurz darauf eingegangen werden soll. Es ändert alles. Wirklich ALLES. Durch und durch. Das jedenfalls ist mein Empfinden als jemand der Linux seit 1995 nutzt.

Die neuen Building Blocks sind Container die “überall” laufen können und die hochdynamisch vernetzt werden. Technisch hilft die CNCF Cloud Native Interactive Landscape hilft bei der Orientierung aus der Vogelperspektive. Datenbanken, Storage, Security, Networking, Workload Scheduling, Observability, Packaging, Automation – alles ist anders. Ganz anders. Microservices Pattern reflektieren das auf Architektur-Ebene. Neue Richtlinien wie Twelve-Factor App oder das Reactive Manifesto sind entstanden. Techniker die bisher nur mit klassischen Monolithen und SOA gearbeitet haben sind gut beraten sich frühzeitig mit diesen Dingen vertraut zu machen. In Kubernetes begegnen sie einem ununterbrochen und es hilft ungemein wenn man die DNA der Dinge versteht.

Dinge die man bis dato gut verstanden zu haben schien werden plötzlich Neuland –  z.B. Storage. Die größten Erdbeben scheinen aktuell im Netzwerk Umfeld zu liegen. Auf der KubeCon / Cloud Native Con 2019 in Barcelona schien es mir so als ob die Hälfte der Talks im Umfeld Service Mesh, API Gateway und Service Proxy waren.  Man traut sich da kaum über den Tellerrand zu blicken und sich zu fragen wann und wie Änderungen an den Building Blocks des Networking wie EBPF durchschlagen. Die Tatsache, dass man inzwischen oft schon von DevSecOps spricht lässt erahnen wie gigantisch das Thema Sicherheit ist. Und wie es darum steht. ?

Stichwort DNA:  Die Cloud Native Definition signalisiert bereits die DevOps DNA der Dinge (s. DevOps or die!). Ich würde behaupten, wertschöpfende Nutzung von Kubernetes ist ohne DevOps Kultur nicht möglich und man sollte es besser sein lassen wenn man nicht bereit ist DevOps zu leben.

Kubernetes

Das mit der Dynamik trifft im Übrigen auch auf die Entwicklung von Kubernetes zu. Es ist zusammen mit Linux “fastest moving project in Open Source history” (Dan Kohn, CNCF executive director).

Aber was genau ist eigentlich Kubernetes und warum genau geht es so durch die Decke?

Kubernetes ist ein Open-Source-System zur Automatisierung der Bereitstellung, Skalierung und Verwaltung von containerisierten Anwendungen.

Es ist entstanden aus “Borg” – einem Google internen Projekt zur Verwaltung von Containern. Es wurde 2014 von Google als Open Source freigegeben. In diesem Zuge wurde die Cloud Native Computing Foundation unter dem Dach der Linux Foundation gegründet. Zu diesem Zeitpunkt gab es bereits viele verschiedene Lösungen für vergleichbare Probleme. Die Ursache für den kometenhaften Aufstieg liegen in Open Source und der Demokratisierung – Niemand macht sich gerne abhängig von einem Anbieter (Vendor Lock-In), alle lieben Open Source.

Wo anfangen? Was gibt es zu tun?

Um das zu beantworten sollte man sich Zeit nehmen ein paar Fragen beantworten:

• Welche Kubernetes-/DevOps-/Linux-/Go Skills habe ich im Unternehmen?
• Welche Dinge möchte ich bis wann erledigen und welche Kapazitäten habe ich?
• Welche Themen (Infrastruktur, Plattform, Entwicklung, Betrieb) möchte ich langfristig in House behalten? Bin ich damit wettbewerbsfähig?
• Überblicke ich den Blast-Radius der Dinge und habe ich Backup & Recovery im Griff?
• Wie sieht der Markt für Produkte und Dienstleitungen aus?
• Wo gehe ich Top Down, wo Bottom Up vor?
• Was erwarte ich an Total Cost of Ownership?

Man sollte unbedingt wissen wo man steht, was die erste Station der Reise sein soll, wie weit der zur ersten Station und wie der initiale Kurs ist. “Kubernetes is a Journey, not a destination”.

Auch hier schadet der eine oder andere Blick an das obere Ende der Skala nicht. In Sachen Betrieb ist das aktuell zum Beispiel Site Reliability Engineering :

Wie viel Infrastruktur und Betrieb kann ich mir selbst zumuten?

Management Protip: Man macht den Bock nicht über Nacht zum Gärtner. Anwendungs-Entwickler sind in der Regel keine guten Infrastruktur Entwickler. Im Gegenteil: Anwendungs-Entwickler sollten möglichst wenig von Infrastruktur sehen. Dieser Anspruch ist insbesondere auch Gegenstand von Serverless … das gerade auch deswegen (und wegen der Kosten) ebenfalls durch die Decke geht – und zwar so, dass die CNCF diesem Segment eine dedizierte Karte spendiert hat.

Fazit: Kubernetes erobert die Cloud im Sturm. Widerstand ist zwecklos. Man sollte sich frühzeitig Zeit nehmen ein wenig Verständnis für die  Dinge im Großen und Ganzen zu bekommen und eine Cloud Strategie zu erarbeiten. Dienstleister können helfen. ?

Der Beitrag Kubernetes: Widerstand ist zwecklos erschien zuerst auf CONTENTREICH.

Zur Erinnerung aus DevOps – Wikipedia:

DevOps is agile IT (operations) delivery, required to match the cadence of agile IT development. DevOps is a philosophy, not a method, or framework, or body of knowledge, or *shudder* vendor’s tool. DevOps is the philosophy of unifying Development and Operations at the culture, practice, and tool levels, to achieve accelerated and more frequent deployment of changes to Production.

Im State of DevOps Report 2014 schrieb Jez Humble:

We can now assert with confidence that high IT performance correlates with strong business performance, helping to boost productivity, profitability and market share.

Es geht also im Kern drum dem Kunden so schnell wie möglich Mehrwert zu liefern.

Martin Fowler schreibt dazu im Vorwort von Accelerate: The Science of Lean Software and Devops: Building and Scaling High Performing Technology Organizations

Their evidence refutes the Bimodal IT notion that you have to choose between speed and stability, instead speed depends on stability, so good IT practices give you both.

Geschwindigkeit und Stabilität gehen also Hand in Hand! ? Er spricht von “Beweis” weil das in diesem Buch präsentierte Ergebnis auf vier Jahren wissenschaftlicher Forschung über alle Größen von Unternehmen und alle Branchen basiert.

Die ultimative Zusammenfassung der Ergebnisse ist dieses Diagramm zum Buch Accelerate:

Overlapping arrows! Here's a cleaner version. pic.twitter.com/PYu08Y3rN4

— nicole forsgren PHD IN COMPUTERING THINGS (@nicolefv) October 29, 2018

Und weil der Ausdruck “Performance” so omnipräsent ist auch nochmal zur Erinnerung: Software Delivery Performance wird gemessen in Lead Time, Deployment Frequency, Meant Time to Restore und Change Fail Percentage.

Weil man es gar nicht deutlich genug sagen kann:  DevOps startet mit Kultur! Und diese Kultur ist essentiell. DevOps ist sehr viel mehr als ein paar CI Pipelines. Genau diese Tatsache kann Implementierung sehr schwierig machen, denn Kulturwandel ist nicht jedes Mitarbeiters Sache:

Auf vielfachen Wunsch Bild mit CC Lizenz: „ALLE mitnehmen wollen in Veränderungsprozessen?“ pic.twitter.com/8wn6565ZwW

— Tanja Föhr (@tanjafoehr) September 14, 2018

Ganz besonders schwierig gestalten sich Versuche kopfloser DevOps Transformationen von pathologischen (power-orientierten) Organisationen. In Bezug auf Kultur schadet es da sicher nicht die Führung einer Organisation zu reflektieren. Der Post What Does a Modern CTO Look Like? aus 2014 scheint mir heute so aktuell wie damals.

Hat man eine Wahl?

Die Lücke zwischen High- und Low-Performern jedenfalls wird größer (aus Gap between DevOps-savvy and non-savvy companies is huge, survey finds)

The survey shows that high-performing organizations are widening their lead against lower-performing organizations. Compared to low performers, high-performing organizations deploy 200 times more frequently, have 2,555 times faster lead times, and recover 24 times faster from failed changes, with three times lower change fail rates.

Der größere Kontext zu DevOps ist natürlich ? New Work und Digitale Transformation ?. Ich persönlich war hier schwer beeindruckt von den Aussagen des Otto Group CEO Alexander Birken:

Interessierten denen wissenschaftliche Lektüre nicht liegt empfehle ich Project Phoenix. Ein wirklich fesselnder Roman der leicht verdaulich einleuchtend vermittelt wie die einzelnen Dinge in DevOps zusammenspielen.

Der Beitrag DevOps … or die! ? erschien zuerst auf CONTENTREICH.

A young developer wrote me an email asking for career advice. This was my response: pic.twitter.com/HQ58A1I8ht

— Henrik Joreteg (@HenrikJoreteg) February 18, 2019

Der Beitrag Pure Gold of Advice for Developers erschien zuerst auf CONTENTREICH.

Der Beitrag Deploy to Production erschien zuerst auf CONTENTREICH.

Ihr kennt das :)

Auf vielfachen Wunsch Bild mit CC Lizenz: „ALLE mitnehmen wollen in Veränderungsprozessen?“ pic.twitter.com/8wn6565ZwW

— Tanja Föhr (@tanjafoehr) September 14, 2018

Nicht das “Gleiche”, aber mir kam das Muster grundsätzlich auch irgendwie vertraut vor : Technology adoption life cycle

Der Beitrag Innovation, Spätzünder und Verweigerer erschien zuerst auf CONTENTREICH.

I am currently assisting on a greenfield project which just switched to Alfresco 6. At this time, the project only uses core functionality of the repository so we considered the choice reasonable even though the new major release is not quite GA yet. Things showing up on the horizon were just too tempting. More on Kubernetes likely to follow soon. We expected to be faced with regressions but at the same time expected them not to be red flags holding us back. Those expectations haven been proven true so far. Our application required very little changing – mostly due to library updates. Getting SDK 3 to play was a slightly “bigger” issue.

Current State of Affairs

Long story short: The primary motivation was getting Alfresco Bulk Import to play with Alfresco 6. Hence, I implemented that bare bones and opened up an issue Alfresco 6 Support on Peters repo. Had to drop the old SDK 2 dependency to get proper deps in. I never liked amp to I switched it to build a plain jar instead. It seemed desirable to have one artifact supporting all versions of Alfresco so I changed a few Jackson calls to use reflection. I did not yet try it on Alfresco 4 or 5 but I am pretty confident it will be working as well. Furthermore, we found it was lacking a feature we needed – cm:contentproperty type support. Time is always tight and getting things to play is always highest priority. I tried my best keeping all those existing abstractions clean while adding the new functionality.

With the filesystem based implementation and XML metadata reader, cm:content properties appear just as all other other metadata in foo.metadata.properties.xml:

<entry key="yns:contentProp">../../path/to/file.xml</entry>

We reference a file and distinguish by checking the dictionary with the type. If we find it to be cm:content and if the referenced file exists, we deal with it accordingly.

That’s what we got today. My fork is on Github. For convenience, there is also a download below in case you just want to give it a spin. Please let me know if you encounter a regression.

Future Directions

Personally, I’d like to see more automated testing – specifically integration testing. Testing is covered by SDK 3 which – you name it – does not work as is with Alfresco 6. In fact, I tweaked the SDK 3 as well. It is just a few lines which already make it usable for me. However, at this time, I don’t want the bulk import to depend on it. Actually, I’d like to see that or a similar quick fix applied to the SDK soon. I may be wrong, but it seems to me that the SDK will change direction driving towards Docker in one regard or another. That’s why I hesitated offering a PR.

I am not aiming to take maintainance for a fork of the bulk import or the SDK. I’d like to see things converge.  Motivation is still stemming from requirements of a real project. I’d be interested to get feedback in case you consider the issues mentioned valuable in order to push things into the proper direction.

Download Alfresco Bulk Import

Der Beitrag Alfresco Bulk Import : Version 6, cm:content support and beyond erschien zuerst auf CONTENTREICH.

How we used to look for a Theme

From time to time, we build a WordPress website. We start digging for a ready to use theme visually and functionally appealing. The reason we usually buy(!) a theme is that we want something more unique and polished. We have not yet taken the time to invest in a framework or starter kit because that only pays off when you are using it frequently. Besides, getting the site out quickly is common high priority.

Once we find a candidate, we take a closer look at the technical side of things. We inspect code exposed by demo sites using tools such as Webpagetest, Lighthouse and PageSpeed Insights. With regards to covering our requirements, we prefer themes as minimal as possible, because code has issues and we don’t want issues with things we don’t even care about. Large code bases scare the hell out of us ?.

Implementing Theme Customizations – Theory and Practice

Once you start working with your theme of choice, sooner or later you may find yourself having to make tweaks. Assuming theme authors take care of their product by providing long term support, it is considered best practice to put your customizations in a child. The idea is that updates to the parent apply cleanly without breaking your code.

So far, we have always put our tweaks in a child. However, we learned from experience that you should be careful relying on theme updates – no matter whether the theme is for free or a paid premium product.  We understand there are many scenarios where vendor support is critical. If this is applying to your project, you should be double checking whether you are willing to trust.

Following best practices is more effort than doing changes directly in place – effort which only pays off if you actually benefit from parent updates. Hence, in cases where we feel theme code is maintainable, we started assuming that we will end up doing it. Other than that, starting with a blank child theme directory is not what we consider state of the art development experience.

Our holy Grail: Production ready Theme with modern Dev Experience

Recently, we considered revamping contentreich.de. This time, we chose not to go with the traditional empty child theme based approach and instead look for a modern Node based tooling (npm, webpack, browser-sync, etc.) environment to start from. Sage appears to be targeting these developer requirements pretty nicely, but there is still quite a bit work ahead of you before arriving at a unique truly production ready site.

We were wondering:

Premium theme vendors surely use the kind of tooling and enjoy the kind of development experience we were after. Are people willing to sell production ready themes along with full source code and modern dev experience? They won’t be offering support if you fork from their code base, but this time we don’t care about it anyways. And sure, they won’t appreciate you selling products based on the code you bought unless you get an explicit license. Should not be too hard to get it straight that our case is just about one site. After all, even Microsoft has an Enterprise Source Licensing Program, although aimed at a slightly different audience.

I wrote a post in a Facebook group asking about what I was looking for, and we were surprised this seems to be very unusual. Most people were either pointing to starter kits or telling “developer friendly and premade don’t go well together”. I am sorry, but I strongly disagree with that statement.

I ended up asking the guy from whom we bought the theme serving our current site as a parent. He was kind enough sending me the source of one of his current premium themes – for free. We are now looking into it and we promised getting back to him. I’d happily send him a few Euros in case things go well and we build the revamped site on top of it.

Finally, we think there is nothing wrong with what we were asking for and given the sheer size of the WordPress ecosystem, we am sure there are other people who would be comfortable selling their themes with full source  and modern workflow included.

Next time faced with a similar situation and considering to buy a theme, we won’t hesitate to ask the vendor about it. Maybe one day vendors would directly advertise this option on market places like theme forest.

Der Beitrag So Nobody is selling WordPress Themes with Sources? erschien zuerst auf CONTENTREICH.

Uneasiness X as a Service

Software-/Function-/Platform-/Infrastructure as a Service providers have to get operations right to stay in the business and you can be sure Amazon, Google and Microsoft do. Scaling up high enables tempting price tags – price tags giving those less focused a hard time competing. Still, many CEOs bite the bullet and pay the extra fee to keep sensitive operations in house – due to a basic lack of trust. Even if overall, they get way less out of it. Much of the justification stems from the Snowden revelations. It may not be much of an issue in the US, but it surely is in the EU and Germany.

In Open Source Contentland (Alfresco/Nuxeo), there is a strong current towards the Content Services Platforms and hence the Cloud these days. Don’t know much about the feelings of Nuxeo users operating on premise, but I know for sure Alfresco users do feel uneasy in the light of recent announcements, the aquisition and insights. It almost reads like AWS will be forced on us. Does that matter to you? Do you care about it? With regards to Alfresco, lets see whether we will see successor of Alfresco in the Cloud successor being announced.

Software as a Service usually comes with strong restrictions and this is not surprising: The provider is responsible for the application. Hence, they don’t want your buggy code executing in their house. Keep it where it is now and use their REST API endpoints.

Uneasiness Extensibility and Apps

Focusing on Contentland, Alfresco understands some aspects of extensibily should be living in their house – likely things that can be expressed declaratively (e.g. models) so the dangerous bits in terms of operations remain in their hands.  Beyond, they discourage  (platform-) in-process extensibility and do not seem to care about it. The runtime modules system has issues which may never be addressed, and they are slicing and dicing all things microservices. Nuxeo is way ahead in terms of runtime modules providing a clean OSGI based implementation. At the end of the day, there is no way around modularity. You can discourage 3rd parties from using it, but vendors need it themselves.

Alfresco still ships its Share collaboration app which already gets the job done for many people. It also features a lot of runtime extension capabilities so what you need may only be a few lines of code away – with no build step required. Unfortunately it is/will be deprecated soon. ?

Today, Alfresco and Nuxeo are both offering JavaScript component UI libraries and tooling designed to build browser based applications using their platforms. There are also basic example apps buiding on top of those libraries, but that is pretty much it. There is no “modern” browser based application providing runtime extensibility. However, Alfresco is currently revisiting (client) runtime extensibility (in process!;).

There is also tooling and libraries aimed exclusively at mobile, but I doubt many people care about that.

If you don’t already have a UI, where are you supposed to start and how far do you have to go to get something actually useable in production?

Now what?

Assuming you have content-driven itches that a Content Service Platform can scratch/already scratches and Open Source matters: Is it still possible to ?-pick what you need?

Vendors are raving more than ever about Open Source. And in fact they are getting more serious about it. Alfresco recently dropped a lot of code on github. Nuxeo code has been there for years. They want your eyes on it. If you build an application for one of those platforms, you should make use of it. It helps a lot with understanding how things work and get support-tickets issues out of the way. Contributing changes is a whole different story, though. :) Try to stay close to the vendor path, use things as designed and it will be a smooth ride.

If you want to remain on premise, you should make sure to be comfortable with containers at your scale. If you are typically operating at more than one instance per application, you may already be fine and should likely be good to go. Either way, you might not want to deal with the complexity Kubernetes or other tools at Google scale. Scalabily introduces complexity and you surely don’t want more than the minimum. Still, containers will rule the foreseeable future of software deployment and using them on premise does not require a ?-science degree.

I also recommend to “Take the minimum” to get the job done when it comes to the UI. Alfresco Share will remain around for a while. Use it by all means if it works today. Be careful with regards to bigger investments and keep an eye on the the UI libraries evolution. It is JavaScript, but Enterprise at the same time. Things won’t change on a daily basis. ?

What’s next?

People are getting sick and tired of Silicon Valley essentially capturing and selling each and every move we make. Blockchain, decentralization- and  cryptonetwork technology is here to disrupt centralization (and hence the Cloud as we know it today) bringing us Web 3.0 along with decentralization – and without single organizations in control. We prefer trust in math instead of people. Dispite issues like performance,  solutions such as Bitcoin can already be considered mature. IPFS or Storj may prove to be storage pieces of the puzzle in Contentland. But again, it will take trust – and time. Other than that, I think it is very remarkable that given the current excitement around Blockchain, traditional Cloud giants such as Amazon, Google and Facebook usually innovating early don’t seem to care about it all. ? (Oh wait! Microsoft just started looking at decentralized identity!) However, until then, you may want to keep you stuff on premise.

References

• Alfresco for SMBs: Fresh Challenges
• Why the Web 3.0 Matters and you should know about it
• Alfresco Acquired by a Private Equity Firm THL

Der Beitrag Cloud first Uneasiness in Contentland erschien zuerst auf CONTENTREICH.

Focusing back on Alfresco, I appreciate the majority of changes approaching. Cloud aside, it is for sure time to revisit things and clean up the house as well. 

The ACS installers will be replaced with Docker containers

The current executable binary based installation is very convenient if you want to get started really fast. I am sure a lot of SMB production installations have been using it, a lot of people are happy with the results and don’t care about the database and whether or not it is PostgreSQL. The sheer simplicity can be a blessing. The flipside of the coin is that it does not scale and Alfresco has to serve the upper end of the spectrum up to the .  After all, that’s where they make a living. And containers are the way. Containers also work fine at small scale, but many businesses (big and small) are just not ready to operate them. In Alfrescoland, things are still a bit rough around the edges at this time.

Hence, the new continous-delivery-pipeline guideline building on top of containers is likely not a good fit for SMBs either – even if you forget about the parts involving containers.

I have seen no mention of Windows here. They may have chosen to go “all in Linux” and drop support for native Windows installations. ?

REST APIs all the way

REST APIs are mainstream nowadays. This is what all the microservices are using, right? Most people feel RPC is old-fashioned and outdated even though that’s not the case at all. GraphQL is too bleeding edge. Everybody builds upon REST no matter whether its model makes sense or not. Please note that I am not at all saying that Alfresco REST APIs are bad. In fact I think the new REST endpoints are pretty good. And you are still free to build upon the RPC based ones they are shipping or embed your own.

I understand Alfresco does not want our buggy code executing in their process. However, I feel they are pushing REST a bit too far. They already recommend making process-engine calls over the network. Given that these calls usually run within transactional context, I have doubts it’s generally a good rule to follow unless you really understand what you are doing. No, the good old monolith is not quite dead yet. It will remain the perfect simple solution for “small” applications.

If you choose to put your bit of logic in its own process, you will at least have to start thinking more carefully about transactions and whether the things you need are actually covered by the REST API.  Your-own-process approaches provide their own set of benefits, but I don’t think those are the ones most SMBs are after.

I am building REST services at this time and the repo proves to be the perfect host. I was curious about implementation details with regards to their new REST API. Ironically, Alfresco uses package names org.alfresco.rest.framework, which made me feel invited, so I started using these packages in custom code. Asking about them on twitter, I learned they are not really meant to be used for others so usage is not supported. Again, this also underpins them prefering us to stay outside.

How is Alfresco actually suggesting to implement REST services in-process today?

Building on raw AbstractWebscript/DeclarativeWebScript?

Come on, it’s 2018! (“How to hijack org.alfresco.rest.framework” may be another post).

Abandoning Share

Some consider its future foggy. I think it’s finally time to realize that Share will not be saved (long term). I consider it  “abandoned” and I am confident it will likely only see very basic maintainance. It’s a shame, because it is a highly flexible production grade application which could be tweaked in various ways. Share/Surf/Aikau were built with all kinds of extensibility in mind early on. Runtime extension points are pretty much in all places you could hope for. The “Wordpress way” of just dropping a few lines of code often gets the problem at hand solved – without a build step and within mintues. Those days seem to be fading away.

Unfortunately, web technology used in Share is exotic and outdated today and the pool of skilled people is small.  The time where it might have been possible to migrate to a modern Java Web-Stack such as JHipster are over. JHipster? Oh, wait … ?

The overall situation is very different with the new Application Development Framework/Alfresco Content App. Today, Alfresco recommends to build on top of the ADF. This may be feasible if effort does not matter. For SMBs, it often does. And the difference may very well be critical. There is virtually no runtime exensibility on ADF/ACA ground. But the pool of skilled people (read Angular Devs) is huge.

Looks like the people unhappy with the fact that there is no general purpose replacement application with runtime extension cababilities on the horizon got noticed and Alfresco starts thinking about possible solutions to this problem. Bindu kicked it off and summarized most of the shortcomings on Github and on the Community Platform.

Personally, I consider implementing runtime extension capabilities very challenging. And retrofitting them even more so. I am sure it won’t happen in the ADF/ACA unless Alfresco is willing to assign significant resources. Way more than what the community of volunteers has to offer.

Finally, I don’t think the SDK plays well in an “out of process preferred”-/Cloud strategy as it is pretty much all about in-process extension. I guess it will remain being a second class citizen.

The deprecation of “Alfresco in the Cloud” seems very strange. I am curios what we will see following up. A reincarnation?

So to wrap up: Alfresco is still a great platform. Maybe it is at its best ever. It is just got a little more complicated – thank you Cloud! But that’s also fine because that is where we make a living. ?

Got something to add? Feel free to drop your two cents in the comments.

References

• Alfresco announces major changes coming in the 6.0 release (Jeff Potts)
• Future of Alfresco Share Remains Foggy After DevCon
• Alfresco Share needs Love: Let’s save it!

Der Beitrag Alfresco for SMBs: Fresh Challenges erschien zuerst auf CONTENTREICH.

? Nailed! ?

I made a comic introducing clojure :D

was this a good way to spend my time? debatable.
did I draw mushrooms? yes.https://t.co/wicR9kgjKd pic.twitter.com/GFAjJhcGh6

— daiyi! (chris) (@daiyitastic) July 18, 2017

Der Beitrag Clojure nailed in Sketchnotes erschien zuerst auf CONTENTREICH.

I have been working with Alfresco (mostly Community) since 2007 and that is where the bulk of my experience in stems from. The recent post Whither Open Source ECM? got me rethinking.

• Does Enterprise Open Source actually work?
• What do I want from it?

As a developer, I would like to participate in a vibrant community using latest bleeding edge technology.

This is most likely not what you will get. Especially when it is about code. Enterprise tends to be very conservative and leaping behind the rest of the world. Besides, there is a reputation issue ?

When you say "I write enterprise software", all I hear is "I write bad software".

— Hipster Hacker (@hipsterhacker) June 6, 2011

So don’t expect alpha nerds to be around.

However, you might still find a product capable of making people happy. And that still matters a lot.

Alfresco

The issues mentioned are just here for the sake of example. I really don’t want to pick on Alfresco.

Spoiler: Alfresco Community is still a nice product which may serve you well.

So what’s wrong?

It depends. There is absolutely nothing wrong if you just use it as is and get around the rough edges.

Which rough edges I am talking about? Well, there are quite a few unresolved issues with CIFS and IMAP (those don’t even include the ones which got batch-closed) to get started. Ironically, I usually warn prospects right upfront about those and others. Still, people frequently want to pray and hope for the best. Sometimes we are lucky, sometimes not.

So yeah, it is Open Source, so what about contributing fixes?

There is no maintained git repo so you may have to deal with svn which does not feel very inviting. Other than that, the JIRA process is not working for me. I think the filed issues are speaking for themselves.

Looking at IMAP and CIFS specifically, it also seems Alfresco simply does not care. Things are really swamped. But that’s actually ok. After all, they wrote the code and give it away for free! And it comes with no warranty and support and that’s clearly stated – for the Community Edition at least.

Now even if you manage to get one of those issues fixed: Will it get into core and ship with future updates? I guess that depends on the component affected and whether the issue hurts enterprise customers. It surely is hard to get contributions into core. In case you fail, you licked it and it is all yours. :)

There are other components which are going south. The Share application is another example. Be very careful what you are building upon. You won’t be able to maintain a fork of core components.

Some components are in fact are no longer Open Source. You still get AOS “for free”, but issues may get worse to deal with.

On the contrary, Cloud, the REST-API, Search, Activiti and the ADF are getting a lot of attention these days. If this happens to be your area of interest, you are in good company. Again, that’s all fair. They can do whatever they want and they likely have good reason.

Beyond Alfresco

Recently, I started looking more and more into Nuxeo. To be honest, parts of its foundation feel better. Other people went further and even Dump Alfresco for Nuxeo as their preferred Document Management System. Furthermore, looks like I will get in touch with Odoo in the near future.

From what I have seen so far, there simply are no raving communities contributing code anywhere (Projects with less than a week lifecycle don’t count ;). Not in Alfrescoland and not on entire Planet Enterprise.

If Open Sourcing is not about code contributions, what is it that drives companies giving away their code for “free”?

Things that come to mind:

• Dispite the fact that a lot of managers have no clue about it, management won’t even look at products which are not Open Source.
• It trims support and documenting efforts because people can help themselves.
• They want people to get their feet wet and build a community spreading good vibes.

To wrap up: Look close and make sure to get what you expect before diving in.

Der Beitrag How I became sceptical about Enterprise Open Source erschien zuerst auf CONTENTREICH.

Applies somewhat similar to IT-Services : Design Services Price List

Der Beitrag IT-Services Price List erschien zuerst auf CONTENTREICH.

Besides, Node native tooling such as create-react-app generally delivers a pretty pleasant experience which could be considered “mainstream” these days. And as a developer you should make sure to not be significantly less productive than mainstream. You might run into trouble finding a job otherwise. :)

In this post I am looking at Webpack, but the story is really about the JVM and Node (and not just plain JavaScript) in one process. Webpack just happened to be the detail itching me.

Briding the Gap to Webpack

People approaching from the JavaScript side of things might be wondering: Why bother bridging a gap from the JVM to Node and not rewrite all the things for Node? I assume this will be happening, but it takes time even though we already have tooling like lumo – a Node based environment leveraging bootstrapped ClojureScript. The other way (bringing all the things to the JVM natively) may never happen.

Why bother with ClojureScript anyways? Derek Slanger has some answers.

Ways to leverage Webpack

Basic Webpack usage starts by introducing a package.json with dependencies sufficient to generate a bundle and launching the compilation from the command line. Automatically rebuilding things on change is not a big deal either. Aspects such as hot reloading get tricky in case you already have something alien to Node (such as Figwheel) dealing with it.

In ClojureScript land, there are tools trying to bridge the JVM to Node gap already. ClojureScript starter tool and shadow-cljs are two examples. Today, they are both based on separate (Node/JVM) processes. A multi-process setup can already be helpful, but it gets hairy once you need a lot of fine-grained interaction between Node and the JVM.

I was sure it is not possible to use the JVM as a library in Node, but I was aware of solutions going the other way. Oracle has abandoned  Avatar, but Ian Bull stepped in and came up with J2V8. I decided to give it a spin.

A Proof of Concept

First I was wondering about the system boundary. Should cljsbuild call into Node or vice versa?

Since there already are Webpack loaders for various other languages, I chose to try implementing a skeleton of a cljs-loader. The code for my experiment webpack-jvm is on Github. At the time of  writing, it consists of a loader implemented in Clojure (just a function consuming the source and emitting static JavaScript code) along with a demo. Feel free to try it out.

I have not tried it on Mac or Windows, but I think it should be working on those OSs as well. At least the artifacts are on maven central. That’s also the reason I went down to 4.6.0 of j2v8. I was surprised to see Node 5.9 running under the hood. I don’t consider it an issue for now as it is good enough to run current Webpack 2.6, 4.7.0 on Linux comes with Node 7, the project is alive and from what I can tell so far, Node 8 does not introduce serious issues either. However, compiling the native code is still painful – especially if you want to support all those platforms – including even Android.

Where to go next

The loader should be able to kick off a ClojureScript compiler –  JVM native or bootstrapped and there are still various details to worry about and sacrifices (Closure/tree-shaking) to expect.

Entering Node land from the ClojureScript compiler (JVM Version) – :npm-deps or the ns-form may be an alternative. Especially if we allow strings instead of symbols as suggested by Thomas Heller CLJS-2061 .

Thats all I got for now. Feel free to comment or jump in.

Der Beitrag Webpack meets the JVM erschien zuerst auf CONTENTREICH.

Die “Fix und fertig sorglos Kollaboration mit voller Hoheit über die eigenen Daten” klang schlüssig. Insbesondere auch vor dem Hintergrund der Snowden-Enthüllungen muss das laufen. Das habe ich wie wohl viele andere auch gedacht und beim Crowdfunding damals beherzt zugegriffen. Nun kam die Hiobsbotschaft: Protonet ist insolvent.

Die Boxen funktionieren grundsätzlich autark. Allerdings bietet Protonet auch Dienste in Zusammenhang mit Namensauflösung (DNS) und Nachrichtenversand die wohl in sehr naher Zukunft eingestellt werden. Protonet hat Anleitungen bereit gestellt wie man diese Funktionalität selbst aufrecht erhält. Dennoch – die Sorgen die man ja eigentlich nicht haben wollte fangen an. In Bezuf auf die Zukunft ist vieles unklar:

• Wer supported Hard- und Software?
• Wie steht es mit der Weiterentwicklung von SOUL?

Protonet selbst hat es nicht geschafft das Geschäft profitabel zu machen. Ich persönlich bezweifle, dass andere es mit dem Erbe hinbekommen werden.

Wenn ich abhängig von einer Protonet Box wäre würde ich mich nach einer Alternative mit besseren Zukunftsaussichten umschauen. In Betracht könnten kommen…

SaaS Collaboration Lösungen

Google Drive/-Apps, Slack, Wrike, Basecamp, Office 365 uvm. sind günstige, schlüsselfertige und mehr oder weniger anpassbare Anwendungen(!) mit Sorglosfaktor in Bezug auf den Betrieb und Entwicklung. Die Herausforderung besteht hier vor allem darin in der großen Menge der Angebote die Anwendung zu finden welche die eigenen Anforderungen möglichst gut abdeckt. Änderungswünsche umzusetzen ist schwierig. Außerdem lehnen viele Kunden Public Cloud kategorisch mit dem Argument der Datenhoheit-/sicherheit ab. Das mag im einen oder anderen Fall gerechtfertigt sein, die Entscheidung dagegen, sich also selbst zu kümmern, hat aber eben auch einen Aufpreis.

NAS Server

Systeme wie die von Nextcloud, Synology oder Qnap bedienen das Bedürfnis nach Datenhoheit, kommen aber in der Regel nicht schlüsselfertig sorglos daher. Man ist selbst verantwortlich für Hardware und Software – Installation, Updates, Konfiguration. Nextcloud ist in diesem Segment sehr beliebt. Die Software ist kostenlos und kann wahweise auch “fix und fertig” mit Hardware gekauft werden. Bei NAS Software handelt es sich zum Großteil um Open Source. Man sollte sich unbedingt vorher umschauen und klären, wie weit der Weg ist eine wirklich nutzbare Anwendung(!) langfristig stabil zum Laufen zu bringen. Meiner Einschätzung nach waren es vor allem Lösungen wie Owncloud/Nextcloud, welche Protonet das Leben schwer gemacht haben.

ECM Plattformen

Der eine oder andere SOUL Anwender wird im Laufe der Zeit festgestellt haben, dass gewisse Anforderungen nur sehr schwer mit dem System zu realisieren sind. Dokument-Metadaten, Transformationen, Zugriffsrechte, Auditing, Suche, Workflow, MS Office (Sharepoint) / Active Directory Integration,  Interoperabilität, Transaktionen: Diese Aspekte gewinnen in der Regel mit der Größe des Unternehmens an Bedeutung. Sie können aber auch in kleinen Unternehmen schon von Bedeutung sein. In jedem Fall sollte klar sein, dass auch diese Dinge einen Preis haben – selbst wenn die Software wie Nuxeo oder Alfresco erst einmal als Open Source zur Verfügung steht. Wer sich mit solchen Anforderungen überfordert sieht kann sich bei Bedarf beraten lassen – zum Beispiel hier. ;)

Referenzen

• Protonet
• Protonet ist insolvent
• Insolvenzantrag: Serverhersteller Protonet ist zahlungsunfähig
• Protonet: Das Startup mit dem Crowdfunding-Rekord ist insolvent
• Nextcloud Box

Der Beitrag Protonet insolvent: Was wird mit Box und Daten? erschien zuerst auf CONTENTREICH.

About runtime modules

Extensible runtime environments provide you with various interfaces to plug in third party code. Those interfaces usually come at different scale and nature. You have REST-API for interactions beyond process boundaries and a programming language based API for in-process communication. Runtime discovery and wiring of lifecycle management is the bare minimum required by in-process extensions (frequently called modules or plugins).

As a platform vendor, you’ll likely prefer people staying out of your house (process), because misbehaving guests cause all sorts of issues. In practice, this is hardly possible.

Depending on quantity and volatility of modules and their respective environments, you might want a bit more. Take WordPress as an example. You could likely update themes and plugins interactively once a day – and even core, and even automatically. Surely, you want to try things out every once in a while. At scale you want to be provided with mechanisms to easily install, uninstall, upgrade, start, stop, enable and disable modules.

Module functionality provided by the Alfresco runtime

In Javaland, amongst other things, there is OSGI, Spring and (soon) Jigsaw at our disposal. In Alfrescoland, they decided to build upon Spring. Today, we have two types of modules to choose from, and there has been a heated debate about pros and cons of the proprietary AMP file type promoted by Alfresco Inc. Personally I stopped using them years ago (went with plain jar) and have not missed them since. Seems Alfresco just recently changed its mind and now also favors jar modules (The great value of Alfresco Jar Modules). Some might argue it is great to have somewhat alternative approaches “addressing different use cases”. I disagree because that very fact makes matters complex.

With regards to lifecycle, we are supposed to hook our components into application events fired by the Spring context. Other than that, we have base module components dealing with applicability and dependencies (Module Components) and support for conditional import of bootstrap content  (Importing Module Data). There are restartable child context based units called subsystems which do not directly relate to module extensions.

Module infrastructure missing in Alfresco runtime

At the end of the day, whether something is missing or not depends on demand. Assuming that we are aiming at a healthy ecosystem built to scale, I’d like to see:

• One single promoted module extension solution
• Uninstall reliably working
• Downgrade working
• Dead easy/fool proof install/uninstall/upgrade/start/stop (interactive like what we have in WordPress would be awesome)

Some might argue module code isolation (as in OSGI) is a must. Personally I disagree (again due to complexity), and I’d argue that if this is really what you need, a microservice might do as well.

Some of the items listed may not be critical. But still I think we are missing essential functionality and this is pretty remarkable given that the platform has been around for a while.

Conclusions

The current state of the module eco-system stems from what we are given. I’d love to see a flourishing extension market (as in ?), but I feel we are far far away and we are not even driving towards. In fact, I’d be interested to know whether there is a single profitable extension out there.

I would volunteer helping to move things forward, but again (as with Share), this is not reasonably possible without support from Alfresco. I have asked them about their opinion on modules in general. I am still waiting for a response. Please note that I am not complaining.

Finally, you might want to look at how things are handled over at Nuxeo. I think they got this right – early on.

Der Beitrag Alfresco Extension Module Fundamentals erschien zuerst auf CONTENTREICH.

TL;DR: I love the REPL experience. I wanted a ClojureScript ? project. I picked Gorilla REPL. Scope increased all the time. You may find the result useful now.

History & Motivation

I spent a lot of time working with the Alfresco ECM platform. Many solutions require just a few lines of code. The fast feedback provided by a REPL is invaluable. In Alfresco land, the Javascript Console has been a helpful companion over all the years. But it also has limitations it will most likely never overcome. My quest for an alternative brought up Gorilla REPL and I played around with it a while ago. Although embedding of Gorilla was working at that time, I felt things were still too messy and uneasy about releasing something.

A few weeks ago, the desire to play with React came up. Gorilla was my victim of choice. I started writing reagent replacements of the existing JavaScript code. The ClojureScript codebase grew, and I decided to add re-frame to the mix. As time went by, more and more ideas came up and I started experimenting around.

Current State of all the Things

Fast forward to today. At this time, I consider mostly working/ok:

• ClojureScript migration of application client code
• Recent versions of dependency libraries
• Parinfer (optional)
• Separate, dedicated nREPL middleware stack
• Figwheel/Devcards/Testing (latter bare bones)
• Componentized (incl. Tesla-Microservice)
• Standalone uberjar / Docker image
• Drop in uberjar capabilities (dropping the uberjar into some WEB-INF/lib should work … sometimes)
• Standalone uberwar
• Roll in jar (use as a library)
• Proxy based loading of remote worksheets (in case CORS is not in place)
• Pomegranate dependencies for non leiningen based deployments

Work in progress/experimental stage:

• Remote nREPL delegation
• Client/Browser REPL (replumb)
• Heroku
• Clojail execution
• Mobile/PWA capabilities
• Clean up messy places (e.g. nREPL code /Ring handlers)
• Error handling
• Node.js backend

On the radar:

• Implementing tests
• Better extensibility
• Interruptable eval
• Improve composabitly of (ring) handlers
• Code sharing UI/services
• Revisit (Clo)Jupyter
• Peridically save to localStorage
• Introduce garden

Other than that, some of the open issues have been addressed.

I tried really hard to remain backwards compatible and preserve existing functionality. Given the nature of reagent, this did not seem reasonably possible with regards to persisted html in worksheets. I ended up introducing version 2 persistence (transit based) while still supporting version 1 persistence (shamelessly discarding output).

Given my limited resources and the sheer amount of changes, I am sure I introduced a bunch of new issues.

Quick Demos

Here are a few “new” sample use cases I have been playing around with. The standard Leiningen based usage (which is hopefully still working) is not covered.

Docker

There are two Docker images. A 200MB 0.3.6-alpine version which should be fine for pretty much anything other than Spark (… all in one process that is due to native library loading issue), and a full blown 400MB 0.3.6 version.

Run

docker run --name gorilla-repl -p 9000:9000 deas/gorilla-repl:0.3.6-alpine

and open a fresh worksheet.  Shift+Enter evaluates the active code segment, Alt+Shift+Enter the whole sheet. Alternatively, if you are into Big Data, you might want to try the sparkling  example instead. Be patient with that one – downloading and launching Spark(ling) takes a moment

Standalone Uberjar

Download the standalone.jar, run

java -jar target/gorilla-repl-ng-standalone.jar

and open a fresh worksheet.  The sparkling link above should work just as well.

This file may also work as an “all-in drop in” for webapps (try putting it in WEB-INF/lib).

Alfresco

For convenience, I rolled gorilla REPL into lambdalf. Download the repo extension, put it in /opt/alfresco/modules/platform, restart the server and you should find a fresh worksheet here. The MIME type example should work as well.

JEE War File

Download the war file and drop it into the webapps folder of your application server. Assuming the server is running on port 8080, you should be able to find the application here.

I don’t have a lot of sample worksheets to offer. You might want to look at Jony’s test repository over at github for some inspiration.

Future Directions

I had a chat with the Jony Hudson (the original author) and Ben Bailey. At this time, Jony seems fairly busy with other things and I don’t expect him to put a lot of effort into Gorilla REPL in the near future.

Nothing is set in stone. Experiments will be reverted if it turns out they do more harm than good. Using a Node as a backend (working) appears awesome –  just as using Spark on top of Alfresco. Still, I personally don’t have a meaningful use case … yet. :)

For now, the long term goals are to expand use cases while keeping the software stable/compatible and development fun. Short term goal is cleaning things up and adding tests.

If you feel like jumping in, you are welcome! Source along with instructions to get started hacking on it are on Github. Don’t expect things to be perfect. There surely are traces of migration and experimentation.

Finally, I want to thank all the people who built the stuff my work is based on. ?

Der Beitrag Pimping Gorilla REPL with React and ClojureScript. And Beyond. erschien zuerst auf CONTENTREICH.

The following screenshot (click to enlarge) shows a filtered and sorted query.

Yes, the edit action dialog works as well.

Axel pointed out that he implemented task-/workflow indexing and search “abusing” Solr. Just as with the datalists UI, we consider uniformity something to generally aim at. I think I understand where to hook in in order to enable this. Still, not quite sure whether it is not better to use raw Activiti instead.

If somebody reading this has experience pushing BPM in Alfresco (CE or EE) to scale: I’d love to hear about it! I’d also appreciate to learn about BPM improvements which may be underway (The new REST endpoints don’t seem helpful).

As a sidenote, I have resumed work on the extended datalists and I think things are coming along nicely on that front.

By the way: I wonder where (if anywhere at all) forms are headed. They need some ? too. ;)

References

• Alfresco Extended Datalists @ Github
• Alfresco Activiti REST API

Der Beitrag Alfresco Workflow meets Extended Datalists erschien zuerst auf CONTENTREICH.

The Community Edition uses the OODirect subsystem which also manages the lifecycle of the process. However, there is nothing in place to recover from a screwed/terminated process. The drop-in extension below provides this functionality. I have only tried it with Alfresco 5.1, but I think it should also work starting at 4.2.

To use it, drop it in webapps/alfresco/WEB-INF/lib or modules/platform. It won’t do anything unless you set a cron expression in alfresco-global.properties like shown below.

contentreich.officeWatchDog.kill=true
contentreich.officeWatchDog.cronExpression=0 */10 * * * ?
contentreich.officeWatchDog.timeoutSeconds=60

The timeoutSeconds parameter says how long you are willing to wait before you consider the process screwed, kill will only work on a Unix system for now. The extension keeps track of the process, so it won’t work if you start/restart the Office process manually.

Enjoy! ;)

Download Alfresco Office Watchdog

Der Beitrag Alfresco: Handling “LibreOffice not responding” erschien zuerst auf CONTENTREICH.

There are Google Vision “modules” available for Alfresco and Nuxeo and most likely a bunch of other systems as well. These modules execute Google API Java code in process. They need to ensure the API along with its tree of dependencies is right there. Dependency trees can be huge – especially as we are heading into machine learning and artificial intelligence domains. The Alfresco repository comes with almost 300 Java libraries. The Google Vision API also has a few dependencies. Some of those are already in the Alfresco repository. Care should be taken if you want to put it there.

There are various approaches how to introduce a module along with its dependencies into a server process (Alfresco or Nuxeo). Alfresco suggests to use its proprietary AMP format, Nuxeo uses an OSGI “light” approach (without lifecycle and/or isolation if I remember correctly). I don’t like either of them. Introducing more dependencies messes things up even further. And has great potential for all sorts of nasty issues.

I wanted to try the microservice route. It surely complicates matters as it introduces another process and network communication. On the other hand, it also has great advantages:

• It does not mess with ECM server dependencies
• The microservice can potentially be used from all your systems
• The process lifecycle is independant of the client (which happens to be the ECM server)
• Development turnaround is super quick – at least it was with tesla

I grabbed code which was there and quickly bent it towards microservices. One might consider it a hack. You have been warned. :)

The Microservice

I am always looking for Clojure adventures. That’s why I picked Otto’s tesla-microservice as a basis for the microservice (The Otto folks have base implementations for Java/Spring Boot, Node.js and maybe even other stacks on github). Naturally, I decided to wrap the microservice into a docker container.

If you want to try this out, make sure you have a Google API json key. If you don’t have one already, get yourself one. Playing around is free. And 1000 API calls/month are also free – if I remember correctly.

To spin up the docker container, do the following:

$ mkdir conf
$ echo 'vision-credentials-json=file:///conf/google-api-key.json' > conf/ecm-google.properties
$ cp /tmp/your-key.json conf/google-api-key.json
$ docker run -v `pwd`/conf:/conf \
   -e CONFIG_FILE=/conf/ecm-google.properties --rm \
   -p 9090:9090 deas/contentreich-ecm-google-ms:0.1.0

Alternatively, if you want to run the jar directly, download the ECM Google Microservice archive, extract it and exeute

$ cd contentreich-ecm-google-ms/
$ cp /tmp/your-key.json conf/google-api-key.json
$ CONFIG_FILE=./conf/ecm-google.properties java \
   -jar contentreich-ecm-google-ms-0.1.0-standalone.jar

The properties file supports way more values (generic microservice stuff and Google things I have introduced).

Either way, the service should be up and a demo form is available at http://localhost:9090/vision-form. Submitting an image should display the data returned by Google:

The Alfresco “Connector”

My Alfresco pieces are derived from the work of Angel Borroy. Links to sources and binaries can be found below.

To deploy the Alfresco extension, copy the repo-/share jar file to {alfresco,share}/WEB-INF/lib or modules/{platform,share} and (re)start the server.

There is a doclib action “Google Vision” which is available for images. Try it out. It should set tags on the image. It should also set landmark, logo and text values when received from Google. At least I hope I preserved this functionality. :)

Putting this together was an awesome experience. I am fairly sure this will continue to evolve over time. And maybe it can also serve to bring ECM nerd communities together. ;)

Download ECM Google Microservice
Download Alfresco ECM Google Service

References

• My fork of alfresco-google-vision @ Github
• Clojurified, Dockerized ECM Google Microservice @ Github
• Tesla Microservice @ Github

Der Beitrag Docker, Clojure, Microservices, Google (and Alfresco): Introducing ECM Google Services erschien zuerst auf CONTENTREICH.

ECM vendors are pitching pure JavaScript libraries these days, and it seems they no longer care about CMIS either. I have not seen one of them pitching or recommending it for a while. However, would be fair to drop a few lines and guide the people who jumped on the bandwagon. I think it may be time to discourage CMIS usage.

Personally, I’d like to know what actually killed CMIS it. Maybe it was just what I found as a developer – the cumbersome usage and the fact that implementations where not as interchangeable as one might have expected.

References

• CMIS on Wikipedia

Der Beitrag Who killed CMIS? erschien zuerst auf CONTENTREICH.

We should be sure to understand the nature of the foundation we build upon. Otherwise, we might end up in a zombie apocalypse.

Der Beitrag What’s that fuss about Alfresco Angular2 components? erschien zuerst auf CONTENTREICH.

Soon! @Alfresco #angular2 pic.twitter.com/jqH5HFPWVN

— Ole Hejlskov (@OleHejlskov) June 29, 2016

The New Way to Bootstrap Your Application with Nuxeo Generator https://t.co/uExnxYtm0m pic.twitter.com/ZCbgE86edJ

— Nuxeo (@nuxeo) July 8, 2016

Almost looks like they are copying from each other, but I don’t think that is the case. :) I guess it is most likely because we can be sure now that Angular will be around for a while. A lot of developers love it and appreciate the move:

To be honest, I think a fair share of developers see this as an opportunity to get rid of problematic legacy which they have built over the years. :) Other than that, personally I am way less excited until we see an extensible, well maintained base application built on top of this stuff.

Der Beitrag Angular is the new ECM UI Hype erschien zuerst auf CONTENTREICH.