Think soberly. Maturity myth

Original could be found there and there:

Documentum in Maintenance Mode

One thing that was apparent throughout the event was Documentum and existing interfaces (Webtop, D2, xCP) moving into more of a maintenance mode. Some examples included:

  • Rohit’s quote that Documentum was “feature complete” during the keynote.
  • Subsequent article in CMSWire that “No one is asking for more features or functions”
  • Documentum Roadmap that focused on releases that will make Documentum easier to upgrade.

Other expectations – moving beyond

Documentum is feature rich – not clamoring for more capability. As we pointed out from the morning Documentum 7 session, ECD is treating Documentum as complete and has focused on making it simpler to run Documentum.

Actually, the statement about “feature complete” is totally weird. If my memory serves me right, today is 2016 but Documentum still suffers from childhood diseases like:

  • Partial support of unicode
  • Extremely limited SOAP/REST API (please check my thoughts on ECN, actually, in my last project, I’m trying to map CRUD operations on DFC calls and got some progress on that)
  • Poor integration capabilities
  • Java-only API
  • non J2EE compliant DFC library
  • Poor java-api
  • Poor documentation
  • Poor performance
  • Poor security
  • Poor support

This is how “mature application” does look from EMC perspective. Actually, my opinion about maturity of Documentum is following:

  • in 2007 EMC acquired XHive and after that they implemented XHive storage support in Documentum (I have never used it)
  • further EMC implemented xPlore (also based on XHive), technically xPlore have no search capabilities at all: it grabs all data from database and storage, puts it into another big database and tries to performs XML queries against xml database
  • further EMC implemented xCP2 which relies on xMS which in turn based on XHive
  • further EMC implemented InfoArchive that is based on XHive
  • now EMC is trying to implement Horizon/LEAP which is also based on XHive
  • the co-founder of XHive was Jeroen van Rotterdam, who is ECD CTO in EMC now

From my perspective it is obvious that ECD/IGG/etc development vector had switched to XHive long time ago.

Think soberly. Is it hard?

Well, Momentum ended, TSGRP guys posted theirs thoughts about conference, now it is a time to ruin the myths.

It is worth to say that I have never attended such eventsMomentum (and most probably will never do, no matter what company will held it in the future), because from my perspective such events should look like:

EMC thinks that Momentum looks like:

but in real life it looks like:

Docker myth

Issue #1 to address – Forced re-indexing and database changes are time consuming

Patrick offered a stateless Documentum –

  • Point and run Content Server
  • Binary upgrades
  • No forced changes to database
  • Eliminates downtime from reindexing

Able to bring in Bedrock server without any changes to database or repository.

Makes upgrades easier (and faster). Has the ability to just run “Bedrock” against existing database and content repository due to everything due to Documentum in a Docker Container.

  • Portable Production Ready Images
  • Continuous delivery of upgrades and patches to production
  • Faster Rollback

Documentum Application Containers

  • Developer – All in One container for Functional Investigation
  • Service Images – Individual services containers for Agile Expansion and Load balancing
  • Stateless Documentum – External Content, Database & Isolated Configuration for Fast Patching and Upgrades

Different Containers for Content Store could be more containers for xCP or other customizations.
Docker is Linux based (no support for Microsoft right now).

How to migrate to Docker environment.

  • Add content server – Docker container – can operate alongside existing Documentum
  • Deploy extra Docker containers to manage high volumes
  • Migrate to Docker by turning off original non-Docker instances

How many people are looking at Docker (only 1 out of 60 in room)
Hot upgrades to D7.3+ (Bedrock – Feldspar…)

  • Can run Bedrock on Docbase 7.2 and also have it work on a Docbase Bedrock.
  • Run new version along side old version in Production

Actually, everything that was “written” about Docker sounds ridiculous… The main problem is: Docker complicates everything. Why? Let’s elaborate. First of all, what is a Docker image? It is just a tar archive where maintainer put service’s binaries among with dependencies and bootstrap procedures: take a look at my shell scenario which creates document image – there is nothing related to Docker except the command which uploads archive into the Docker repository, there is no rocket science: I may unpack my archive into specific directory and run my services inside chroot take a look at chroot usecases – they are pretty the same as Docker’s:

  • Testing and development
  • Dependency control
  • Compatibility
  • Recovery
  • Privilege separation

If chroot is so cool, what are the Docker’s advantages over chroot? I do believe that the answer for this question is obvious:

But if you have chosen to use Docker you must understand that your deployment/maintenance workflow changes dramatically, for example, imagine that you decided to install a patch/update in Dockerized environment (no matter Documentum (i.e. application) or operating system (i.e. platform) patch), what steps do you need to perform to achieve your goal? These steps are:

  • update base image
  • test new base image
  • stop existing container
  • remove existing container
  • deploy new container

This procedure, obviously, is less straightforward than installing patches/updates using puppet, ansible or something else or even manually, however, this is how Docker workflow designed and supposed to work. Now ask yourself how many typical Documentum installation do you need to have to start taking advantage of using Docker? In my opinion dozen is not enough, if you have more you are either a large enterprise or a big consulting company, and it is not a EMC business to lecture you how to manage your environments.