2014-11-18 - Conference, Software-Engineering, Trends
Unfortunately I couldn’t watch the keynote due to a system outage the day before. But I got a short summary from several guys and the opinions were really divided.
Some of them mentioned that it was really entertaining and that Mr. Dueck had made use of stereotypes in the IT industry to underpin common problems. But that was exactly the problem for some other folks - they expressed clearly that the use of such stereotypes was really annoying.
Nevertheless, I will watch and post the talk as soon as it is available on the web.
The second talk I attended was held by Mathias Mayer from Travis CI. Attending Mathias’ talk wasn’t an easy decision for me at first, because Chad Fowler was making a presentation at the same time. But it was totally worth joining Mathias’s talk.
He explained how they grew and organised their team at Travis CI to work in a devops kind of way. Everybody in the team is on-call during the week and is responsible for his changes. At the weekend they have dedicated team members who do on-call.
Another interesting point that he spelled out very clearly was that software architecture can only be evaluated in production. And a production system is not only defined by his architecture - operation of that system is also a big part.
Matthias defined a production system as follows:
PRODUCTION = ARCHITECTURE + OPERATIONS(PRODUCTION)
He also explained how they improved their operations and presented a big incident on Travis CI from 2012.
Slides from his talk: pdf
The talk started curiously, as the presenter hadn’t arrived yet due to a strike by the public transportation union. Instead the two Fowlers, Martin and Chad, held a short Q&A session about microservices. And it couldn’t have been a better start because, even though it was short, it was really useful and entertaining.
After 15 minutes the original presenter arrived and the scheduled presentation started.
The talk’s content itself wasn’t a big surprise. Phil presented how SoundCloud utilised microservices to make their stack more flexible to changes, especially if you provide several public APIs.
Theo’s talk was really mathematical. with him explaining how you can apply different mathematical approaches to detect anomalies in your system on a higher level.
One phrase of his really stuck in my mind when he talked about metrics:
Latency is king
Measuring latencies in your system can be really useful to detect wrong behaviour in your system. And when it comes to companies’ systems, being able to quickly detect unhealthy components in a distributed system is extremely useful. You wouldn’t even need more metrics for this purpose, although having more metrics can always come in handy anyway ;)
Theo also pointed out that we sometimes take the wrong metrics into account. For example: alerting based on disk usage. Imagine you get an alert in the night which says that the disk usage reached a certain limit (e.g. 95%). Now imagine that the disk runs slowly full and there is no need to get up in the night.
A better measurement would be how fast the disk runs full, 1% in 6 hours or something. In this case there is no need to wake up anybody and the problem can be fixed when someone comes to the office in the morning.
Slides from his talk: pdf
This slot was divided into three separate talks which were held by representatives from startups.
The two talks by Lennart (Graylog) and Mathias (Travis CI) were really interesting because they both gave great insights into the problems they had when building a company around open source.
The talk by Andreas was also worth watching, but it didn’t directly lie in my current field of interest.
Slides from the talks: pdf
I chose this talk because I like stories from real world projects and talks which use metaphors as examples. It is always really exciting to learn from other people’s experiences.
Before he got up to speak I knew nothing about the speaker and I had no idea what the content would be. After he sat down I was so happy that I had joined the presentation.
For me the main message was that you can’t think in gigantic roadmaps because you can’t plan the unexpected. Instead, you and your company should have a vision of where the company wants to go, with the tasks needed to achieve the goal varying from time to time.
Gojko presented a nice story where a small checkbox changed their whole roadmap. Their goal was to attract more users. After implementing a small feature, in collaboration with one of their customers, they solved a problem which helped many customers and attracted new ones. Then he questioned if their current roadmap is still valid or whether it would make sense to rethink the situation and next steps.
Gojko sometimes displayed quotes on his slides, among which this was one of my favourites:
Good user stories should be OPTIONS about SURVIVABLE EXPERIMENTS for BEHAVIOUR CHANGE
You can find the slides of his talk here: pdf
This presentation marked the ending of a great event and brought up again some real world stories.
Leslie went through several examples and pointed out how some things can make your daily work and company culture worse. Meetings, reinventing the wheel, team disharmony - they can all lead to unhappiness and ultimately to unsuccessful projects and companies.