Phill Barber's Blog

I was lucky enough to attend a talk by John Turner from Paddy Power  as part of London Continuous Delivery  meetup.  The talk was very informative and gave the audience some great insight into rolling out PaaS and continuous delivery in the real world. In order to innovate faster, Paddy Power made a number of changes to "re-orient" the company and put the engineer team first.  To help speed up engineering, where possible, decisions on architecture were removed and replaced with convention. Pipeline An abstract (no tools specified) pipeline was defined with the following stages: 1. Code commit Trunk based commits with feature switches. 2. Build Component and Integration tests Code quality rules (enforced by sonar ) 3. Acceptance Tests Run against the application/service as delpoyed in a VM as provisioned by Gigaspace's Cloudify product.  Config for the VM's dependencies (e.g. java installation) is defined in a blueprint .  Acceptance te...

A member of our team recently suggested that we use pull requests in our development workflow.  Many points were made for and against in our debate.  After only a short time of adopting this change, the major benefit I have seen is the increased critique of the team's output. The debate The decision to use pull requests was certainly not a given and gave rise to an interesting debate.  Many arguments were made for and against which I've tried to summarise below. For pull requests Increased knowledge sharing - Non reviewers can view pull requests just as easily. Simpler commit messages - Each pull request is (hopefully) created "with the reviewer in mind" . Provides a forum for commenting on work. Increase in code quality Against pull requests "It's too much process and will slow things down" As a small team I think we take pride in our lightweight process of pair programming and informal ad-hoc code reviews.  Adding extra checks a...

Every time an alert notifies your Ops team, there should be a real problem.  If there isn't a real problem, you're wasting their time, adding confusion and making it harder for them to respond to real incidents. The problem we have: Too many alerts for non-issues and non-critical issues. I sat with a member of our Ops team recently and was horrified to see how many notifications they received for our monitoring systems.  At times, it was almost impossible to make any sense from them due to the sheer volume of emails filling their inbox.   Why is this such a problem? Multiple reasons: Each notification comes at a cost of lessening the impact of all other notifications.  Take this to the extreme, where Ops receive hundreds per day, the impact of an alert can be almost zero. A false alarm is a distraction and can waste valuable minutes in debugging real issues. How did we get here? The short answer is: by diligently adding more alerts but not dilig...

So far the services I have been involved with have had acceptance tests and monitoring checks.  For various reasons the tests and checks have been designed, developed and run in separate worlds.  This approach has lead to issues falling through the cracks and remaining undetected in live for too long. Here I will explain our first pass at joining these two separate suites... running browser based acceptance tests as monitoring checks. What we've done in the past... Separate tests and checks Acceptance tests A good suite of acceptance tests should test your service end to end, verify external code quality and run against real external dependencies.  Some acceptance test suites can tick all of these boxes without relying on browser based tests, this is great as much complexity is removed.  For other test suites, a browser is essential.  In past projects, the browser based acceptance tests have run against various non-production test/integration environ...

I have always liked Apache Maven, however I recently found a few issues with it that irritated me.  This post was going to moan about them, but after further reading I have come to realise that these issues are not as simple as I first thought.  They are in fact conscious decisions associated with a very complicated problem domain. Fist off, why is maven great? The best thing about maven is the standards it imposes on you.  This has the obvious downside of it feeling restrictive at times.  However, the benefits are huge.  The standard directory layout , standard build phases and of course the standard dependency management have been around so long now that we tend to take them for granted.  Unless a project uses custom or obscure plugins or overridden many default settings, each project looks and builds in a familiar way.  As mentioned on maven.apache.org, " ... [it's] only necessary to learn a small set of commands to build any Maven project ...

"The nice thing about standards is that you have so many to choose from" -  Andrew S. Tanenbaum This quote is very appropriate for Single-Sign-On and specifically SAML.  Here I will discuss why SAML is a great protocol for point to point integrations, but can get very complicated very quickly once you take it beyond that. Single Sign On - Why is it so hard? Single Sign On (or SSO) can be described very simply, to quote wikipedia "...user logs in once and gains access to all systems without being prompted to log in again at each of them". This boils down to three different entities who trust each other directly and indirectly.  A user  enters a password (or some other authentication method) to their identity provider (IDP)  in order to gain access to a service provider (SP) .  User trusts IdP, SP trusts IDP so SP can in-turn trust user. This seems so simple, however if you are a service provider and want to integrate with many IdPs (e.g. twitt...

Gunter Dueck - The World after Cloud Computing & Big Data Gunter is a funny and intelligent man with a delivery style I would compare to that of a stand-up comedian.  Some of his content was on dangerous ground, but he also made some very interesting points. Gunter showed a diagram similar to the above which illustrates the choices we face when creating an IT solution, which I'm inclined to agree with. He also showed another diagram which I'll re-create in list form.   Creative. Skilled. Rote work. Robotic work. Gunter made the point that work starts off at the top of this list and gradually works it's way down until eventually it's fully automated.   What I took away...  Make sure your work is as close to the top of the list as possible. Akmal B Chaudri - Next Gen Hadoop: Gather around the campfire and I will tell you a good YARN This talk was aimed at Hadoop novices which was perfect for me and also the rea...