Ocado is the world's largest pure-play online supermarket and, for years, has been working to package the technology that powers its website, warehouses and back-end systems as a product that can be sold to retailers around the world.
"Even though we're a grocery retailer on the front of it, we're not your typical retail enterprise," said software engineering team lead Matthew Cornford, at this week's Computing DevOps Summit. "Behind the scenes there's a vast array of technology powering our retail business…
"We've learnt that just picking software off the shelf isn't sufficient for our real-world problems and our complex needs. To address these problems, we've had to build up competencies in-house."
Infrastructure team lead Luis Periquito said, "We had a very central typical enterprise solution, where if we want to grow things we just add more: we have central databases and if they run out of grunt, we add more CPUs and more RAM."
He continued, "As we have these massive monoliths, we force everything running on those machines to be exactly the same. Every single development team, every single application will have to work the same way [and] on the same environment."
This monolithic environment brought many challenges to Ocado, which Cornford summarised as competition; painful deployment; and, narrow focus.
Competition: "In a warehouse the size of ours, there are multiple projects going on, and these were assigned project managers, whose role it was to ensure that the technology part of the project was delivered on-time… The developers weren't equipped to know which projects were the most important - which was going to have the most valuable impact. What often happened was that the IT project manager who could shout the loudest would get their work done first."
Painful deployment: "If I wanted to deliver a monolithic application, that means downtime… and reduces the throughput and efficiency of our warehouse… Luckily there was a natural downtime window at the end of the day, and all of our deployments had to be done in this time.
"We also had quite a lengthy approval process to go through. To get a deployment done we had to sign a form; chase a manager to sign it off; find someone in Operations to action our deployment; and this was all at the end of the day when everyone either wants to go home, or has already gone home…
"Add to that the fact that our code wouldn't actually start running until six or seven in the evening, so if something did go wrong that inevitably meant the developer on call would get called in the early evening - if they were lucky - or more likely in the middle of the night to sort out a problem."
Narrow focus: "Our production environments were imposed on us by the infrastructure team. This led to teams that were quite narrow in focus and specialised… The problem with this is when something goes wrong, you need everyone to sort it out because no-one has the big picture. I remember a few support calls with tens of people where everyone was just trying to figure out if the fault lay in their area. That tendency can lead to stress, conflict and mistrust between teams."
Wikileaks Vault 7 suspect Joshua Schulte fingered by FBI after re-using smartphone passwords on his PCs
Joshua Schulte indicted on 13 counts relating to Vault 7 leaks and trading in images of child abuse
Alexa for Hospitality will link with existing systems so guests can order room service and control the air con
Massive volcanic eruptions could have warmed Mars' surface sufficiently for oceans to form
Examination of fruit flies' brains generated more than one billion data points for scientists to analyse