Challenge Accepted Meme

Alfresco for SMBs: Fresh Challenges

Alfresco recently announced a lot of big changes coming our way. In this post, I’d like to focus and add my two cents to those which are likely relevant and “not so great” if you fall into the category of small and medium sized businesses developing and operating on premise. Content Services are becoming the new ECM all over the industry. Services are mostly built cloud first everywhere. Resistance is futile. This trend does not come for free.

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, 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” 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.


Andreas Steffan
Pragmatic ? Scientist and DevOps Mind @ Contentreich. Believes in Open Source, the Open Web and Linux. Freelancing in DevOps-, Cloud-, Kubernetes, JVM- and Contentland and speaks Clojure, Kotlin, Groovy, Go, Python, JavaScript, Java, Alfresco and WordPress. Built infrastructure before it was cool. ❤️ Emacs.

2 thoughts on “Alfresco for SMBs: Fresh Challenges”

  1. Most of the decisioins are consequent and will remove parts which are not playing a role in real live. Some of them caused wrong expectatons in the past anyway.The most critical change I see is the deprecation of share without having a replacement. This is limiting the market looking like a show stopper for new Alfresco business. I doubt the niche market is big enough for companies looking just for a backend plaltform without enterprise ready UI to develop their apps more or less again and again in every project. I’m sure the platform will survive long time because of the OpenSource and freemium concepts but SIs and OEMs familiar enough to implement their own UI may not need the Enterprise offer. So who is paying the employees and VCs in future?
    Maybe I missed something from the Alfresco announcements?

  2. Honestly, observation around the UI part of things starts looking really weird to me.

    They are building ADF, ACA and just released a brand new Process Services UI based on the former while … blatantly stating that they are not very good at building UIs and don’t want to be in that business? ?

    Also worth noting might be the fact Alfresco and Nuxeo offerings are very much starting to look alike – in general and with respect to the UI. Wonder when we’ll see the launch of Nuxeo Process Services – or Flowable for Nuxeo. ;)

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert