kidwellj/findcommonground.uk
1
0
Fork 0
Code Issues Pull requests Releases Wiki Activity

Added blog entry for devopscon

Browse source
This commit is contained in:
Rainer Zehnle 2015-12-07 17:27:41 +01:00
parent 66603cd742
commit ddb57b27e5
1 changed files with 70 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

70
_posts/2015-12-07-devopscon-2015.md Normal file
View file

@ -0,0 +1,70 @@
---
layout: post
title: Notes from DevOpsCon 2015
subtite:
description: Notes from DevOpsCon 2015
category: general
author: Rainer
author_email: rainer.zehnle@haufe-lexware.com
---
Elias Weingaertner, Helmut Strasser and I attended [DevOpsCon](http://devopsconference.de/de/) in Munich from 23th - 25th November 2015.
It was an impressive conference with a lot of new information and also excellent food :-).
I only want to focus on my personal highlights.
##Docker Basis Workshop
I joined the workshop **Der Docker Basis Workshop** form [Peter Rossbach](http://www.bee42.com/).
Till now I managed to stay away from Docker cause there are other collegeuges in our company that have more enthusiasm for tools like that.
A **Basis Workshop** offered a good way to get familiar with Docker.
The workshop itself focused on pure Docker. Peter introduced the intention and basic structure of the docker environment and the relationship between docker images, container, daemon, registry etc.
Peteres created his slides with markdown and shipped it as containers. This guy is really a docker evangelist and convinced about the stuff he presents.
For most of the workshop we worked in the terminal on a virtual machine running docker and learned about the different commands. It wasn't that easy for me cause the workshop is clearly designed for guys familiar with linux.
I struggled for example with creating a simple docker file with vi (don't know how anybody can work with this editor).
One of the reasons why I joined the workshop was to watch Peter presenting Docker and whether it is a good fit for an inhouse workshop. I'm sure this would work great. I'm also sure that it's a good idea to meet with Peter to review our own docker journey and to get feedback from him.
##Microservices and DevOps Journey at Wix.com
Aviran Mordo from [Wix.com](http://de.wix.com/) presented the way how wix.com separated their existing monolithic application in different microservices.
This was the session which I have most enjoyed.
Aviran explained how they divided the existing application in just two separate services in a first step. They learned a lot of stuff about database separation, independent deployment etc. They also learned that it's not a good idea to do too much at the same time. I loved to hear what he marked as **YAGNI** (You ain't gonna need it). It allowed them to focus on business value and how they could handle the task and got the job done.
Wix.com did not implement API versioning, distributed logging and some other stuff we are talking about.
Aviran emphasized more than once that they strictly focused on tasks that must be done and that they cut away the "nice-to-have" things.
Nevertheless it took a year to separate the monolith in two services!
After that they had more experience and they got faster. Now the need for distributed logging arose and they took care of it.
After three years Wix.com has now 140 microservices.
For me it was an eyeopener that it is absolutely ok to start with a small set of requirements in favor of getting the job done and to learn. Every journey begins with a single step!
##Spreadshirts way to continuous delivery
Samuel Ferraz-Leite from [Spreadshirt.com](www.spreadshirt.de) presented their way to continuous delivery.
They started with a matrix organisation. The teams were separated in
* Frontend DEV
* Backend DEV
* QA
* Ops
The QA team was located in another building than the DEV team. The Ops team as well.
This setup led to a monolithic app and architecture that didn't scale. Symtoms were ticket ping-pong or phrases like "the feature lies with Q&A". The deployment of DEV was different from QA. Ops deployed manually.
The cycles to even deploy a feature took days.
Samuel quoted [Conway's law](https://en.wikipedia.org/wiki/Conway%27s_law). They got the results according to their organization structure.
They reorganized.
They created teams with a product owner, DEV and QA. Ops was not included in the first step.
Each team got the full responibility for a service/product. They also got the authority to decide.
One outcome was the end of ticket ping-pong and the whole team felt responsible for product quality.
They also started the construction of a microservice architecture and reduction of technical debts.
After the first succesful reorganizatiion they integrated Ops to each team.
This resulted in excellent telemetry and monitoring capabilities, infrastructure as code (puppet) and continuous delivery (rundeck).
Team overlapping topics like Puppet are addressed in so called **FriendsOf** groups. Product owners and the whole management fosters these groups. Additionally they have weekly standups with representants of each team.
I was really amazed by the power of organization restructering. Of course I know Conway's law. But that it really influences the outcome of a whole company in such a heavy way made me thoughtful.
I mulled over our own company.
How is our company structured regarding the product teams? How do we setup the teams?
What about ourselves organized as one architect team? Isn't that an antipattern?
What about SAP, SSMP? CorpDev and SBC? BTS and H2/H3?
##Conclusion
It was a good conference and I especially appreciated learning from the experiences of other companies where they failed and where they are successful. I hope that in three years we can look back and share our successful way with others.