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

Some corrections

Browse source
This commit is contained in:
Rainer Zehnle 2015-12-07 17:40:52 +01:00
parent ddb57b27e5
commit b39444a387
1 changed files with 15 additions and 15 deletions
Download patch file Download diff file Expand all files Collapse all files

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

@ -14,23 +14,23 @@ 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.
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.
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).
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 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
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.
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 separate the monolith in two services!
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.
@ -44,25 +44,25 @@ They started with a matrix organisation. The teams were separated in
* Frontend DEV
* Backend DEV
* QA
* Ops
* Operation
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.
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 responibility for a service/product. They also got the authority to decide.
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 reduction of technical debts.
They also started the construction of a microservice architecture and started to reduce 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 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 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 ourselves organized as one architect team? Isn't that an antipattern?
What about SAP, SSMP? CorpDev and SBC? BTS and H2/H3?
##Conclusion