71 lines
5.4 KiB
Markdown
71 lines
5.4 KiB
Markdown
|
---
|
||
|
|
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.
|
||
|
|
|