October 30, 2019
With so much innovation in this space, we thought it was high time we shared what we’ve been working on with Docker over the last couple of years.
I’ll talk you through how we’ve saved time, money and made genuinely exciting headway by running Sitecore in Docker. In just a few short months, we’ve got multiple teams up and running with this new approach, and unsurprisingly, we’ve learnt a lot along the way. We are really happy to be able to talk about what we’ve been working on, so here’s the low down on what we’ve found out along the way, as well as our tips and tricks for getting your development teams up to speed with some promising tech.
A Docker Recap
As many of you reading this will know, Docker is definitely not a new technology; most of us probably started playing around with it when Microsoft made the enterprise version available (for free) on early previews of Windows Server 2016. It was November 2015 when it became possible to run Sitecore in Docker containers. After some investigative work, we started playing with using the tech to accelerate several platform projects internally.
For those less familiar with Docker, it might be useful to have a quick refresher:
A Docker container image is a lightweight, standalone, executable package of software that includes everything needed to run an application: code, runtime, system tools, system libraries and settings. Container images become containers at runtime, and in the case of Docker containers - images become containers when they run on Docker Engine. Available for both Linux and Windows-based applications, containerized software will always run the same, regardless of the infrastructure. Containers isolate software from its environment and ensure that it works uniformly despite differences, for instance, between development and staging.1
For some less formal and more in-depth insights into what can be done with Docker, check out my blog where you can find a running commentary of my workings here.
Open Source Innovation
We work with Sitecore a lot. As a global platinum partner, a great deal of our work and experience is on building out the platform for clients across sectors. That means that at any one time, there’s probably at least a handful of developers getting on-boarded to the platform. Here’s the crux of the article: for such a long time, it took days or even weeks to set up (hardware dependant), but with the work we’ve been doing in Docker, we’re now getting people up and running within seconds. That has a massive impact when you are working on multiple projects (and particularly switching between instances). This is game-changing for us, saving client time and money and enabling us to get to the core of our tech projects faster. It’s also massive for the wider Sitecore community who are also starting to adopt and get excited about the work we’ve done so far.
It hasn’t all been plain sailing. We realised early on that it’s not easy for everyone to understand how to use Docker in their daily workflow. We are creatures of habit, and it’s a very different way of working to what people are used to on the Sitecore platform. There are lots of things that you used to be able to see that you can’t see anymore - all is seemingly hidden within the running containers (when you don’t understand what’s going on under the hood). Meaning, people need to know the Docker tools to be able to inspect what is going on in the containers, and that takes time.
With any project, there’s always going to be an equipment issue. Developers still using dated machines or older versions of OS are struggling to launch products. Sometimes people are scared of new things, and at the same time, encounter corporate restrictions and a lack of understanding leading to fear of change. If we own the code for the solution, then it’s a little easier, but sometimes that’s not always the case on a client project, so we don’t have the final call.
We’re responding to the challenges and supporting teams directly in adapting to this new way of working because we’re confident it’s the long-term answer. Lots of issues have been mitigated through documenting the process for each solution, and people are getting used to how Docker works now and are recognising the patterns in what they do; tool A works like tool B…
Crucially, we’ve also improved how we share knowledge with our dev teams, and we’re making significant efforts to document the process through our internal tools.
Internally, we’re making great progress in up-skilling and empowering our dev teams to consider this option when they are starting on a new project. But what about people outside of the company who want to replicate the process?
We started on our open-source GitHub repo early 2018, and then in mid-2019 (at Sitecore’s request), we moved everything into the Sitecore GitHub organisation.
When I first started investigating if Sitecore could be used with containers, I came across a few repos with examples that had similar but slightly different approaches. It seemed like everyone was trying to make things work in their own way. I saw an opportunity to bring together these smart people under one repository and created a repo hosted in the Sitecore org.
Jean-François Larente, Demo Delivery Manager, Sitecore
We still are the main contributors coordinating efforts together with Sitecore and other community members. The repo is now recognised as the main ‘go-to’ source of Sitecore Docker images and excitingly, the community is growing fast, so it’s well worth a visit.
Note, a lot of this had been worked on during our personal time. Still, as the possibilities grew, Valtech CTO Auke van Urk gave us the green light to dedicate more time to developing the features and keep innovating on the solution.
We had several people in Valtech who felt strongly about this initiative and given our status as a Global Platinum Partner. We found it logical to contribute to the community doing visionary work like this!
Auke van Urk, Group CTO Valtech
Sitecore has announced that they officially support running Sitecore in Docker, which is a great step forward and means that this work will gain new momentum.
One thing is improving the developer experience by simplifying onboarding. The next step is to explore how we can use Docker to bridge the gap between what developers experience locally and what actually happens in a production setup!
Going to be at Sitecore Symposium? Come and chat to us at our stand!