Select Page

 Learn the barriers, advantages, and strategies for choosing your upgrade path and partner

Recent releases of Alfresco Content Services have been less about features and more about evolving platform management, extensibility, scalability, and security. There have been hundreds of mostly incremental changes in ACS 6.x and 7.x. 

Why Upgrade to Alfresco Content Services 7.x

There are a few fundamental reasons to upgrade to Alfresco Content Services 7.x. At the top of the list is the fact that the support period for Alfresco 5.2, 6.0 and 6.1 has recently expired. That makes it difficult for our customers to get help if they run into issues. Patches or fixes, including security issues, will not be provided either. That said, some of the biggest reasons to upgrade are the advances in security. While Alfresco has always been concerned with security, there seems to be an even greater focus starting with version 6.0. Newer versions come with updated libraries, patches for things in the base product, and greater extensibility and scalability. A few features have also been added along the way.

Barriers to Upgrading

Customers are now able to use more than Kubrenetes for deployment, but all options take a lot of time and effort the first time through the process. Assets for Kubernetes, Ansible, Docker Compose, and documentation of the manual process are all provided. Each of these options still require significant effort to stand up a production system. This creates challenges for teams that may not have the time or skills to do the work. Further, starting with Alfresco 6.1, the software is broken into smaller pieces that have to be run separately. This will likely require increased investment because of the additional resources required. Once the initial upgrade is made with Ansible, Docker, or Kubernetes, it is relatively easy to update versions in your configuration files and get the new version of the software. At least for minor updates.

Read more about Alfresco Content Services Production Deployment Methods | Part 2: Deployment with Docker Compose here.

Changes Seen With Alfresco Upgrades

One of the biggest changes to Alfresco 6.0 was that they reorganized the code base to make it easier to maintain. Improvements were also made in the way software was deployed, packaged, tested, and security scanned. Version 6.1 included a new single page Angular UI called Digital Workspace that is extensible in a cleaner way than previous user interfaces. Some Share features have not been ported to Digital Workspace yet. For example, very little is available for administration or records management in Digital Workspace. Share is still required for some use cases including parts of records management and most administration tasks that were previously performed in Share.

6.2 improved the Transform service by combining all the standalone transformers into an “all-in-one” transformer, making it easier to deploy. 

Version 7.0 had improvements in repository scalability and cloud deployments. More improvements to scalability, an events SDK, and the initial Elasticsearch based search services option were added in version 7.1. Version 7.2 added a small Angular-based user interface called Control Center for administering users and groups.

Choosing Your Deployment Method

There are four deployment methods available:

  1. Manual: Appropriate when running Windows, or unable to use Ansible or Docker.
    Install and configure Tomcat, upload the war files, manually stand up all the different pieces (i.e., repository, search services, transform router, transform engines, ActiveMQ).
    Pro: The best option for deploying on Windows.
    Con: It is error prone and often results in subtle differences between environments. You may have a 20-30 page Word document with all the steps required to do that deployment.
    Recommendation: Automate it as much as possible, documente everything very clearly, and follow a checklist with validation steps.
    Click here to read more about these options.
  2.  

  3. Automated Installation using Ansible Playbooks: Done when running Linux and unable to use Docker.
    Pro: It automates much of the manual effort required when doing a manual install. Beginning with 7.2, Ansible playbooks can deploy clusters in addition to single servers.
    Con: There is a learning curve and it doesn’t run on Windows.
    Recommendation: Embrace the learning curve.
     
  4. Containerization with Docker Compose: Used when running Linux.
    Pro: This is the sweet spot when an orchestrator is not required.
    Con: Not good for complex deployments or for companies that are unable to run production workloads on Docker.
    Recommendation: Alfresco states it is for development only. It can be used for small to medium sized production deployments.
  5.  

  6. Containerization with Kubernetes: This is a full-featured orchestrator that requires a team that is skilled in deploying and maintaining production workloads on Kubernetes.
    Pro: Good for complex deployments.
    Con: It is challenging for customers that don’t have a skilled team with Kubernetes experience.
    Recommendation: Make sure you have qualified and experienced staff to handle large deployments required.

 

Recommendation for Choosing a Deployment Partner

First and foremost, make sure you work with a team that is familiar with the deployment method of choice. If you are not sure which method to use, select a partner that has experience working with all four methods. Only then can they understand your unique situation and apply the appropriate method. Zia Consulting has extensive experience. Our approach is to take the time needed to understand your initiatives and goals before advising on the appropriate method and deployment plan. We don’t assume that you have to select the most expensive method. Before spending a lot of time and resources on Kubernetes, we talk through the pros and cons in great detail so that you can make an informed decision. Please reach out to us to discuss important information about changes and deprecations, as well as useful tips for planning a smooth and successful upgrade.

Bindu Wavell – Chief Architect
ABOUT THE AUTHOR

Bindu Wavell, Partner and Cheif Architect at Zia Consulting
Bindu has 25+ years of consulting experience with enterprise system integration. As the content lead, he provides technical and architectural reviews and guidance. Bindu supports project teams and runs the Alfresco support practice, overseeing issues across multiple customers. Additionally, he’s active in the Alfresco community, including being a member of the Order of the Bees, where he is a contributor to support tools projects. He’s the creator of the
 Alfresco Yoeman generator. Bindu is a tea connoisseur, and interested in hobby robotics and automation.

Bindu Wavell – Chief Architect
ABOUT THE AUTHOR

PJ Handerhand, Sr. Project Manager/Business Analyst at Zia Consulting
PJ’s technical career began as a database developer thirty years ago. He first started working with Zia Consulting in 2005 where he has played several roles. Most recently, he has contributed as a project manager and business analyst. He has guided many successful Alfresco and Ephesoft project teams. He is a music lover and enjoys playing the guitar from time to time. He lives in New Orleans.

 

Pin It on Pinterest

Sharing is caring

Share this post with your friends!