This article shares my experience working with Docker across several projects over the past year and a half. I will compare making development changes to a local Docker instance first and then moving them to an XM Cloud instance versus working directly off a remote XM Cloud instance.
It is worth noting that I had two very different spec machines over this period, and this does affect which Docker is more or less viable which you can read about at the end of this article.
Now let’s break down the kind of work you might be doing in an XM Cloud environment.
Scenario 1: Working primarily on the front end
In our case, this involved leveraging the Sitecore-jss libraries, where we spent the majority of our time.
For most of our developers, the majority of the work is done on the front end, with some template and rendering definition. We might also define some partial designs and page branches but that is about it. For these developers, standing up and running a Docker instance is a little time consuming and there is very little reward for effort. Their machines may grind to a halt, as was the case with my lower-spec machine, taking several minutes just to start the Docker instance. Even though you may be working primarily on the front end, the extra load of a Dockerized instance running locally can severely slow down your machine. Furthermore, Docker sometimes does not work as well on Windows environments and often requires multiple startup attempts. So, when doing this kind of work, it normally wasn’t worth installing Docker. Especially with lower spec machines.
Things to consider:
When making changes on your remote instance, you will eventually need to serialize those changes. When we had very few items, it was just as easy to serialize items between the remote and local instances. However, once we added in a few thousand sample content items into both the local and remote instances, things changed dramatically. Even if none of these items were being serialized, the process would take a few seconds locally but 20 minutes remotely. I am guessing that when you try to serialize remotely it makes a call to analyze all items first and only later does it compare them against their serialization configuration files.
When several developers are working off the same instance, there is a good chance they will want to change the same items simultaneously. We found this is particularly true as it relates to which renderings are available for which placeholders. This can lead to some chaos, but it might be slightly less than the merge conflicts that occur with serialized items.
Serializing to a remote XM Cloud instance is a little more complicated than running dotnet Sitecore ser pull. You can find out how to do this here: https://doc.sitecore.com/xmc/en/developers/xm-cloud/synchronize-items-between-remote-and-local-xm-cloud-instances-with-the-sitecore-cli.html#connect-the-cli-to-the-xm-cloud-environment
Scenario 2: Working on the back end
Creating pipelines, modifying configuration files, third-party integration, etc.
You don’t have much choice here; you will want to work off your Docker instance for initial testing, etc. Otherwise, there is a significant risk of introducing errors that can block the rest of the development team.
Things to consider:
Do you have any other docker instances running? Are you going to need to spin them up and down as you switch between projects? If so, this can be a real pain especially if you have a slower machine.
Do you have any XP instances running? Are you using any of the same ports? This is going to be annoying, as you need to stop the same ports, then remember to start them again when you switch back.
In Summary
Docker works well enough with a more powerful machine. However, if all you are doing is front-end work using the Sitecore-jss libraries, you may want to avoid it.
Machine Specs
- Machine 1 had an Intel i3-1115G4 processor, 34GB Ram, 1TB SSD Ram
- Machine 2 had a Ryzen 9 7950X3D processor, with Kingston DDR5 64GB a MSI Ventus RTX 4070 Super and SN850X 2TB hard drive.
- Both machines were running Windows 11.
In short, the single-core speed for Machine 2 was twice as fast, and the multi-core speed was six times as fast. Additionally, Machine 2 had faster RAM, a faster hard drive, and more available space.