Lean Theory, Devops, Continuous Delivery and MarkLogic

Last month, we organised another MarkLogic User Group London (MUGL) meeting. The main speaker this time was my old colleague from IOP, Dr Stephen McKearney.

In 2008, we were both in a small agile team, delivering components for the new IOP journals platform. We got to play with some exciting tech (including MarkLogic), and I gave Stephen and the team freedom to trial this, as well as aspects of the development process.

2 years previously, I'd been "agile", running iterative development, with a test first, paper card backlog, acceptance criteria and all that goodness. I could tell Stephen enjoyed Agile when he joined, and we started to dabble with complexity points, and other techniques to make the process as foolproof and transparent as possible.

Time elapsed, we had fun, and Stephen couldn't resist the pull of working with the BBC, a good move. Taking him from Bristol to London and now to Salford.

This history makes it all the more interesting to catch up with Stephen again in more recent times. He's now the Engineering Manager of the Programme Metadata group at the BBC, and a visit to MediaCity to meet him was a great opportunity, as we were close by.

Their experiments and measurements of MarkLogic clusters are fascinating, and there had already been a talk at one of the MarkLogic Summits by Stephen on this very subject. The MUGL talk also leaned on (no pun!) Stephen's Agile experiences with Lean Theory and DEVOPS culture to underpin the continuous delivery of the Programme metadata API.

The MUGL slides illustrate how, by focussing on reducing bottlenecks in the development lifecycle, and eliminating them where possible, you maximise flow. The end reward is reduction in time, and increase in reliability in getting value into the live environment. You need to have some confidence with your environments, and a process for managing what code resides where, but they use an "As-live" concept to test, and can rollback if problems exist. It takes around 2 hours to release at present, and the team are focussing on improving this further.

All of this is made easier by the fact that the team are in control of their processes and environments. They also have responsibility for the release process and what's released. So a failure or P1 bug, results in the developers getting the 24/7 phone call. This certainly is living in DEVOPS utopia to some; a team of both specialisms with singular purpose: adding value.

After intensive testing, they found that the smallest MarkLogic cluster was the most linearly scalable, and have multiples of this topology to run in the cloud. This covers live and as-live too. Another interesting titbit (tidbit if you are Canadian/US) is that if you continually refresh your cloud infrastructure, you end up with faster machines as the underlying hardware is replaced.

It's good to know all these concepts can come together, with foresight, design and elegance to provide a solution that gives us the features we expect (as users), with cutting edge development lifecycle and processes. 

More recently at MarkLogic World London this week, I bumped into some of the BBC team. Stephen wasn't at MLW to defend himself, so there were no jokes on him, honest! 

Check out meetup.com/muglondon for the latest MUGL schedule. We're planning the next one in July. All welcome.