From ddb57b27e593d0f39ee248c8f1d9a73f3ebfeff8 Mon Sep 17 00:00:00 2001 From: Rainer Zehnle Date: Mon, 7 Dec 2015 17:27:41 +0100 Subject: [PATCH] Added blog entry for devopscon --- _posts/2015-12-07-devopscon-2015.md | 70 +++++++++++++++++++++++++++++ 1 file changed, 70 insertions(+) create mode 100644 _posts/2015-12-07-devopscon-2015.md diff --git a/_posts/2015-12-07-devopscon-2015.md b/_posts/2015-12-07-devopscon-2015.md new file mode 100644 index 0000000..44ef200 --- /dev/null +++ b/_posts/2015-12-07-devopscon-2015.md @@ -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. +