fme AG
fme SRL
Compared with cloud computing technologies that are very strong in providing elastic (scalable) services OpenText Documentum products could be regarded as inflexible and monolithic / layered applications. Although they seem to be the exact opposite of the flexible Microservice architecture approach used for cloud native application design, there are ways to combine OpenText Documentum products with cloud computing technologies.
Here are some examples to give you an idea of how to achieve more flexibility by breaking either the OpenText Documentum base installation or business logic into smaller services.
Infrastructure Services
A classic OpenText Documentum Content Server installation could be split into four services / Linux containers:
- The Docbroker
- The repository services
- The Java Method Server (serverapps.ear)
- The Accelerated Content Services (acs.ear)
It is obvious that the Docbroker does not have to deal with much traffic and does not need any load balancing. Thus one or two instances at most could be sufficient (complemented with according health check monitoring) to provide a robust fail over.
For the repository services, the Java Method Server and the Accelerated Content Services, two instances each are sufficient to provide a quite robust service.
However, at some point you might want to perform a data migration into your repository with many documents for example. In this situation, you might think of hiring our highly skilled content migration team. During the migration period, especially with systems utilizing the Java Method Server heavily, exactly this service would become a bottleneck. All other server components would be able to handle all migration tasks.
And here things become interesting: If you had used the service architecture as described earlier and you had been utilizing an orchestration tool, you would have been able to request two additional Java Method Server instances on-demand within minutes. The orchestration tool automatically creates two more instances, which are automatically proxied via a service end point. All upcoming migration requests are then spread over all existing instances, providing a good migration experience. Once the migration is finished, you can scale down the number of instances.
Business Logic Services
If you are using OpenText Documentum D2 e.g. and have potentially “heavyweight” logical services like watermarking, you can create real services (Microservices) and connect them to service discovery tools with load balancing/fail over aware clients (e.g. the Netflix OSS – Eureka, Ribbon, Hystrix). With this option, the watermarking service becomes scalable and flexible for any upcoming future needs and can be placed or moved to dedicated computing resources as needed. If at a certain point this service is identified as a bottleneck, you may instruct your orchestration tool to create additional instances of the same service. If there is a one-time event like a submission to an authority, you may also instruct your orchestration tool to create additional instances of the same service, but you are able to downscale the service after the specific event has finished in order to efficiently use your hardware resources.
Conclusion
Do not fear to use the best of both worlds! We will support you in combining both technologies and providing best results to you!
- Analyze your existing OpenText Documentum infrastructure architecture
- Analyze your existing OpenText Documentum software architecture
- Create a roadmap with you on how to make your OpenText Documentum stack cloud computing-ready
- Create best practices on how to create future components inside your existing OpenText Documentum stack to make them elastic and to comply with the concepts of cloud computing
- Move application logic (where applicable) into elastic Microservices
We are looking forward to sharing our expertise with you!