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.

5 thoughts on “Think soberly. Is it hard?

  1. AFAIK, EMC’s goal is to sell an easier way to upgrade (and take the chance to improve the cloud-readiness of documentum, or make it look like it has improved) and that is supposing that you have zero customizations (ideal scenario for any vendor), this is, you’re running an OOTB CS, which they think (and they’re right) it’s “the best option”, but everyone that has seen a customer installation knows this is highly unlikely (custom ebs files, dmldap, xml configurations, etc.)

    I would like to know which metrics does EMC have. I’m still quite sure that 80-90% of the time it takes to install a patch/migrate is spent checking every customization would still be working after the patch.

    Still, I think is a nice addition (if it works as intended :P), specially for development/testing purpouses.


  2. Once again, Docker is not a silver bullet, it just simplifies some routine operations (many happy “users” use lxc instead of Docker), if you think that it is nice for development/testing purposes that means you have missed something: nothing stops you to use docker, EMC’s bless is not required.


  3. I have only looked at docker a little and I wonder if it could also be possible to apply patches and updates directly to the containers, instead of the base image. That would simplify the update process considerably.
    Any comments?


  4. It is possible, but what is the point to use docker in that case? Please check vendor’s recommendation:

    What if my containers have been modified after creation?
    For starters, you shouldn’t do that. If you need to upgrade something in a container, you should make a new image and run that image.


  5. Pingback: Docker challenge | Documentum in a (nuts)HELL

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s