Today is the first day of the conference days of QCon London, which I have the honour of attending. The view from the conference centre is just great, as you can see above.
The kick-off key note “To the Moon” was given by Russ Olsen. In a very entertaining and energetic way he reviewed the Apollo project. He started at the 1959, when the Western world was plagued by protests and fear because of the Cold War. At this time, Russia was ahead in the space race and had produced the first picture of the far side of the Moon. The reaction of president Kennedy was to declare the goal of landing on the Moon before 1970. Russ Olsen took a chronological approach though the Apollo project, reflecting often on how difficult this actually was.
Some nice things I will remember from this story.
- The software driving the Eagle that landed was developed by a woman named Margaret Hamilton. Designing the first program that needed to do multiple things at once and should be able to react to unexpected situations, Olsen states that she invented the term “Software Engineering” to describe the field of programming at an unprecedented level of complexity, where human lives were on line.
- Although the space race was itself a part of the Cold War, the side effect of it was a hopeful subject. When the landing actually took place, the sense of exhilaration was enormous.
- Very small faults can have life-threatening implication. As an example: the air lock not being completely vented when the pod was released from the ship that was at that time already orbiting the moon led to about a 0.1% difference in speed. The result was that Armstrong and Aldrin had to literally take last-minute measures to avoid landing on a very unfriendly piece of Moon. A good lesson for programmers!
The conclusion strongly relates to Kennedy’s to-the-moon speech: “We choose to go to the moon in this decade and do the other things, not because they are easy, but because they are hard, because that goal will serve to organise and measure the best of our energies and skills, because that challenge is one that we are willing to accept, one we are unwilling to postpone, and one which we intend to win, and the others, too.” So, aim high. Aim for the moon. It’s in the nature of an engineer to do so.
It has to be remarked that the keynote talk has been given before, so if you’re interested you can view it on youtube http://www.youtube.com/watch?v=Z0MbpkYPgM8.
Moving on I visited two talks that might have been too much in my area of expertise. They were good introductions, but failed to give me any new insights. They mainly accomplished to reinforce the message of Microservices and DevOps and as such, I’m confident that they will have introduced many to the concepts in a good way, or at least refreshed those who were more experienced in the fields.
Firstly, Rebecca Parsons gave a talk “Evolutionary architecture and Microservices - A match enabled by Continuous Delivery”. She introduced microservices as a better implementation of the ideas that were already behind SOA architectures. She coupled many traits of microservices to those of evolutionary architectures, which effectively sum up to strong agility and a focus on change. She mentioned Martin Fowler's “prerequisites to a microservices architecture”, including having a DevOps culture.
A nice concept here was the “Reverse Conway’s Law”. While intuitive and on some occasions actual part of our strategy consultancy, this was the first I heard it defined as such. Conway’s Law in short states that organisation structures will be reflected in the architecture of the software that the organisation develops. For example, a company without a DevOps culture (meaning that operations is a separate team) that tries to implement a microservice architecture, will probably end up with many components that are strongly coupled on an operational level that can’t be deployed separately. The “Reverse Conway’s Law” then, is to create software in the way you would like the organisation to be. You will need to be conscious of the many pitfalls of Conway’s Law itself, but when done correctly this can be a good way to induce organisational changes.
Dave Farley, in his talk “The rationale for continuous delivery”, made the point that fast feedback loops are essential in software development. This reaches its best possible state by continuous delivery and deployment (which were both introduced), and strongly relate to the scientific method. I liked this comparison, but that might have to do more with my own scientific background than with the strength of the talk. The examples were the familiar ones of Google, Amazon and Hewlett Packard.
All in all: informative, but no convincing message that we are aiming for the Moon with DevOps and Microservices.
