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."
Robot can assemble Ikea furniture in under 10 minutes - several hours less than the average human
Researchers claim to be one step closer to developing flexible screen televisions, tablets and phones
Thanks to the creation of an ultrafast, nanoscale transistor
The 'first demonstration' of a scalable method for manufacturing graphene
Lifted off on a SpaceX Falcon 9 rocket today following postponement on Monday