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

Layout changes

Browse source
This commit is contained in:
Holger Reinhardt 2015-12-08 17:51:12 +01:00
parent 239efcc1e5
commit b0110f5047
1 changed files with 11 additions and 42 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

53
_posts/2015-12-07-devopscon-2015.md
View file

@ -9,62 +9,31 @@ 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. 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 :-). It was an impressive conference with a lot of new information and also excellent food :-). In the following I want to focus on my personal highlights.
I only want to focus on my personal highlights.
##Docker Basis Workshop ##Docker Basis Workshop
I joined the workshop **Der Docker Basis Workshop** from [Peter Rossbach](http://www.bee42.com/). Till now I managed to stay away from Docker cause there are other colleagues 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. Peters created his slides with markdown and shipped it using containers. This guy is really a Docker evangelist and is convinced about the stuff he presents. For most of the workshop we worked using the terminal on a virtual machine running docker and we learned about the different commands. It wasn't that easy for me because the workshop was clearly designed for guys that are 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).
I joined the workshop **Der Docker Basis Workshop** from [Peter Rossbach](http://www.bee42.com/).
Till now I managed to stay away from Docker cause there are other colleagues 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.
Peters created his slides with markdown and shipped it using containers. This guy is really a Docker evangelist and is convinced about the stuff he presents.
For most of the workshop we worked using the terminal on a virtual machine running docker and we learned about the different commands. It wasn't that easy for me because the workshop was clearly designed for guys that are 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 out 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. 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 out 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 ##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. 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 that I enjoyed the most. Aviran explained how they broke up the existing application in just two 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 split 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!
This was the session that I enjoyed the most.
Aviran explained how they broke up the existing application in just two 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 split 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 ##Spreadshirts way to continuous delivery
Samuel Ferraz-Leite from [Spreadshirt.com](www.spreadshirt.de) presented their 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
They started with a matrix organisation. The teams were separated in
* Frontend DEV * Frontend DEV
* Backend DEV * Backend DEV
* QA * QA
* Operation * Operation
The QA team was located in another building than the DEV team. The Ops team as well. 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. Symptoms 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 responsibility 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 started to reduce technical debts. After the first succesful reorganization 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.
This setup led to a monolithic app and architecture that didn't scale. Symptoms 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 responsibility 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 started to reduce technical debts.
After the first succesful reorganization 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 restructuring. 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 was really amazed by the power of organization restructuring. 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 it over for our own company.
I mulled over our own company.
How is our company structured regarding the product teams? How do we setup the teams? * 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 ourselves organized as one architect team? Isn't that an antipattern?
What about SAP, SSMP? CorpDev and SBC? BTS and H2/H3? * What about SAP, SSMP? CorpDev and SBC? BTS and H2/H3?
##Conclusion ##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. 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.