Akeneo 2.0 - An alpha at it's best
I have been working with akeneo 2.0 for a few month now and I can say it has been a lot of frustrations.
I will try to balance this article with nice new features in Akeneo 2.0 but not sure I will be able to balance much.
Variations
First of all let’s talk about “the” main feature in this 2.0, variations. Indeed the variaiton modelisation is much better. Using the interface is easier and variations can be found easily without much issue.
If you have watched any of the Akeneo videos you will see how well it looks and seems to work. But here is where the dream ends, This new modelisation in reality is completely unfinished. I won’t talk about it in this article , but it is my belief there is a deep conception issue.
Performance
Globally the interface of the 2.0 is much quicker then the 1.7 thanks to elasticsearch but also thanks all the optimisations done by Akeneo. This is a real plus if not the only plus of this version. As the catalog becomes more complex (more attributes/locales) the old versions becomes slower and slower. The 2.0 is not affected by this and maintains quick response times.
When it comes to importing parent products(product models), Akeneo is not slow, it was slow before. It’s unbelievably slow.
Product imports might seem at first slightly slower, but a few test has shown me that it scales much better. Adding more attributes and more locales affects much less the import time. So if you have let’s say 10 locales you will have better import times then with the 1.7.
The imports are terrible but those are not actions you execute every few seconds (depends…) and at least you can see it’s status. The worse here is that some actions will trigger jobs that run in the background While these jobs run it’s impossible to do “mass edits” or any kind of “quick export”.
Among the many actions that will trigger jobs is modifying the attributes of a familly. If you add an attribute, save the familly then add a second attribute save the familly again, 2 jobs is scheduled. These jobs are not quick. They do run for hours. So we find ourself planning actions to the catalog as if we were planning a surgery. In order to minimize the down time of quck actions.
First import these then these. Then friday before laving modify the famillies so that we can import these Monday. And when somebody does modify a familly during the week…
It’s incredible how much this is causing stresfull situations with our clients and us.
Missing features
It’s not only missing features, it’s more things that look like they work but don’t work.
Let’s take an exemple, we select 10 product models and execute a “move category” bulk action. The interface is all pretty and all. We confirm the changes we wish to make. And await the notificaiton telling us our job has been executed. After a while, we discover an nice error telling us that Bulk aciton on product models are not possible…
If there was a way in the grid to see only the product’s instead of product models this could be okay, for some cases. But the way it is right now it’s unusable.
Another very simple case, each product model has a code as an identifier. Well you can’t search product models by code… Every time I have to go in the database and search in the database the products. How is that any better then an excel sheet ?
These are quick exemples and there is ton of things like that on product models. This creates huge frustration.
Migrating
For the migration Akeneo tells us that they created a fantastic tool, “transporteo”.
This tool has multiple issues thay you must know about :
- There are multiple cases that it will not migrate properly, it won’t do errors it will simply do something that’s not logical. For exemple if you had inner variaiton and had a parent product without child, it will not be migrated as a product model, but as a product.
- It’s very slow for “big catalogs” (for Akeneo big has never been really big)
If you have done any custom entities, they will not be migrated either. As well as some metadata such as product histories and such will be lost.
Finally let’s us note that if you are using the EE version and are hoping to get support, well “transporteo” is probably not part of your contract, so no support on the usage of transporteo or no help on bugs in transporteo.
Akeneo PAAS
Akeneo has a PAAS, and a SAAS version. On one of our client’s we are sadly using this.
I cannot start to explain what is wrong with the Akeneo SAAS solution, it’s so wrong…
First of all we are given accesses to connect to the server with a perticular linux user, it seems a good idea. We then realize that you own then all the “akeneo” sources. Digg a bit more and you see that apache runs with that user. So one user to rule them all. I want to cry.
On this ocassions wondered how the updates were done. In the shell history well I found a composer update.
Magento, which is not really know for fallowing good practices uses platform.sh for their PAAS equivalent solution. As much as platform.sh is not perfect (see my aging article about it), their approach is what I was expecting for a proper PAAS solution.
Making composer updates manually on an environment that you can’t even stop (because our user can’t stop apache) is risky, doing this on production is a terrible idea.
Just a few points points for why it’s such a bad idea to use composer update on production
1/ You can’t revert to old version, so if it goes bad it’s over. (well beside doing manual backups)
2/ The package versions you will get might be different then the ones you tested on. (that’s why you commit the composer lock)
3/ Worse if you do this manually on a multi front server you actually might get different version on different fronts (very rare but can happen if you are unlucky)
So basically the issue is you are not in control of what you install!
How does platform.sh or any decent system (even my websites deployment scripts) handles this, well by having a composer.lock file and using composer install to make the udate.
So with what Akeneo put in place I could upload my own composer.lock and use composer install to update the server. If I keep a copy of the previous version I can use that to revert the sources. But this is still not okay :
- Manual operations; always risks of forgetting something, we could do a ansible script doing it for us but still it should be normalized across all Akeneo PAAS servers. If we get the servers of different clients using different procedures the debugging can be a nightmare.
- There are no way to stop the servers during the process. So if it happens when there is heavy traffic we could end up having multiple cache builds in progress. Again we can fix by disabling the app.php in web but again not part of a clean procedure.
I will not even dwell on why having everything running with the same linuc user is is a bad idea.
Akeneo 2.1 any better
Recently we have upgraded from the 2.0 version to 2.1.
So is things any better? Well they are, we might have a beta here instead of an alpha. (Early beta)
There are still tons of features lots compared to a 1.7+Inner variation. Also a ton of bugs that seems not being fixes.
But we can mass edits product models now, and a big feature you can see products in thumbnails. Basically there is not much new and we still have alot of bugs.
Is it all bad ?
Well nearly, the only realy plus of this new feature is the better performances for “simple products”. The variations are much better but compared to Akeneo 1.7 with Inner variation performance and features are still very far from being complete.
New versions comes to quickly, the new 3 month rythm is not practical in my point of view. These versions have very short term support and therefore it is not worth upgrading to. They are far from being tested in real world conditions and therefore using any of them during the first monthes is risky. By the time you think it’s okay the new version is out and the support is dropped.
Conclusion
Has akeneo really done everything wrong? It might seems so. Akeneo 2 feels like an Alpha with features that are unfished and sketchy. You can see that all the code about product models were rushed and not thought well enought. Quite far from it actually.
You might thingk I am exagerating, well I don’t think I do. I am actually even holding back on what I would say are conception issues.
I sincerely hope akeneo learns from the mistakes of this version and that in Septembre the V3 will be much better. I am not looking for fantastic new features, I am looking for stability, performance and ease of use. The grid view added in the 2.1 is a waste of resources when considering the status of the tool at the moment.