18 juli 2018
DevOpsDays report part 2
Conference Report: DevOpsDays Amsterdam 2018 - Pakhuis de Zwijger, Amsterdam, Wednesday, Jun 27 -Jun 29 2018
Walking next to 't IJ to the DevOpsDays Amsterdam venue now becomes a routine, very nice weather included. To my liking, the served breakfast this time also had Bacon and Eggs.
Conference Day #2 - Friday June 29, 2018
09:15 - 09:45 Lee Atchison - Monitoring the Dynamic Nature of Cloud Computing
Starting with the example of an issue where the backup database was used as a test environment because "the backup database is most of the time not used". And guess what: when the backup database was needed it didn't work. The use of dynamic resources (cloud/containers) makes monitoring more complicated. Old: Change indicated a problem, New: change is the norm. Besides traditional monitoring, also the lifecycle needs to be monitored and logged. What ran 5 minutes ago doesn't run now. Looking at the running time (lifecycle) of a large number of containers (At New Relic), showed that most containers ran less than 60 seconds (1.2 million). All though Lee only mentioned his company New Relic only once or twice, for me the talk was more a sales pitch than a DevOpsDays presentation.
09:50 - 10:20 Thiago de Faria - Chaos while deploying ML and making sure AI doesn't hurt your app
Currently companies are implementing DevOps teams that act as a separate entity from the development teams, so now there is a wall of confusion between Dev and DevOps, the time-less conflict. To solve this, we need DevDevOps. Doing DevOps the Agile way has mainly generated technical depth and proved there is no correct way to do DevOps (personal note: maybe there is only a way to be DevOps). After these bold but true statements Thiago start with the main subject of his talk. Artificial Intelligence (AI) and its underlying technique Machine Learning (ML). There are many AI oriented start-ups, but there is no way to do greenfield AI because one needs data to do the ML. ML makes machines find patterns in data without explicitly programming it to do so. But how do you test this? AI, the new-kid-on-the-block, is in the data science field. Data science is traditionally not connected to IT. The Data scientist does his own thing, using CVS files and other sources. Building the ML models take time and when everything is perfect, IT is asked to put things into production. Under pressure of management "because we are a AI company". Et voila, there is the time-less conflict again, how to become DevDevOps. To get thing running into production the Data Scientist has to become a Data-Engineer, which is probably not what he wants to be. Running AI/ML in production has a lot of challenges. Model Drift: Usage of Data influences data and the model needs to be adjusted accordingly. This is hard to measure due to missing feedback loops. The Data scientist again start taking his time to makes things perfect and meanwhile his data sources can also change. To solve this Data Science needs a culture change and start thinking CI/CD, release often, and fail fast. There are tools to support this culture change, Thiago shows a life example MLflow (https://mlflow.org/). In his talk Thiago addressed a lot of interesting subjects which I will take home to ponder about.
BREAK: Just to enough time to get a coffee.
10:35 - 11:05 Waldo Grunenwald - That Product Team Really Brought That Room Together
Waldo from Datadog gives his view on how to do DevOps. The Key is to have product teams that are self-contained and well defined. To communicate products, have interfaces (API), again well defined. The traditional Org-Chart doesn't work in this kind of Product oriented organisations. A vertical organisation structure is needed where managers are Product Leaders and Functional leaders. Using pictures of happy employees Waldo describes the transition of his own work environment that changed from traditional to product-oriented teams. After implementation employees that had minimal communication now had a common goal/product and communication started happening. Finally they were doing something together.
11:10 - 11:40 Karen Cohen - Have your cake and eat it too
Like the previous talk, Karen, who works at Wix, talks about the culture part of DevOps and not about cake baking as the title suggests. Particularly how a team can make big changes to/in a system like the rewrite of a Legacy system. The first try to rewrite the core wasn't a success, while looking for "The Golden Ticket" (a reliable opportunity for great success) the team lost touch with the users and a lack of documentation anode the users and even the team itself because onboarding new members was a big effort. To make the second try a success the team created a vision. This Vision should not be time based and can/need to change over time. Besides documentation also the terminology used was communicated inside and outside of the team. Karen noticed the shared vision was a success when team members aligned their actions and interactions with the shared vision.
11:45 - 12:15 Arnold van Wijnbergen - Why Tooling (only) isn’t the answer
Arnold is a Devoteam employee and describes the current status of Enterprise Operations teams as Firefighting. To be more than that a team needs the correct tools or else it will impact Team Performance. Missing integrations between tools or the presence of tools that are not used should be avoided. Arnold continues on presenting a lot of common sense that to me is no surprise. An example: Don't ask vendors what the best tools are, ask your fellow teams. The title suggested otherwise but to me this presentation focused on tooling only.
LUNCH BREAK: Found some familiar faces I didn’t speak to yet while eating a lunch and showing my workingspirit.nl polo-shirt.
13:05 - 13:35 Emily Freeman - Scaling Sparta: Military Lessons for Growing A Dev Team
While working at Kickbox Emily has seen the company grow and during this presentation she compares the various company sizes to how in history the variously sized Military institutions/civilisations where successful. Scaling People is Hard, and a company has to evolve to accommodate growth. Start-ups can learn from the Spartans (10.000 soldiers). Every spartan citizen was a warrior and the who civilization was based on War, War, War. A spartan soldier was an army by itself and merciless by default. A start-up should hire generalists, see every competition as an enemy and be bold like a spartan. But as it grows to a mid-sized company it should be like the Mongols (100.000 soldiers). The Autonomous Mongols had a very important tool: A Horse. When fighting there was a strategy and "what" mattered, not the "how". They focused on simple solutions and where though. A midsized company must focus on a simple strategy, the "what" not the "how" and find tools to use. After this a company matures to a full-sized enterprise, like the Romans (500.000 Soldiers) a part of employees are contractors. And like in the Roman empire the organizational structure needs the be relative flat with small natural teams with a clear vision. The most important factor that made the Romans successful: Infrastructure. So, when growing to enterprise size make sure your company has/uses the right infrastructure. What I liked about this presentation was the connection between history and the now, history shows what is/can be successful if you know how to relate the "then" and "now".
13:40 - 14:10 Ignites Day 2
Second session of talks that are time-boxed to the extreme and always leave an impression.
Jonah Meijers - Birds-eye overview of core concepts in cloud architecture
The overview in a view key words: Config, Infra as Code, Immutable Infra, Containers, Autoscaling, Blue/Green, Orchestration, Service Location (Ephemeral), 12factor.app
Aditya Vadaganadam - Organizational changes - Ops (as we know) must die!
To have Organizational changes creative destruction is needed. Not like the Enterprise, they started using cloud but didn't change the processes.
Serhat Can - DevOps in a Serverless World
Serverless is not Silver Bullet, it still need deployment, logs, distributed tracing, On Call Schedule, Security. And like it used to be with servers: "Know your limits".
Aernout van den Burg - The SAFE-O-METER
To create high-performance teams, Psychological Safety is needed. To establish this the SAFE-O-METER was created. While creating a whiteboard that rates the Psychological Safety, talking about it is part of generating the safety feeling.
14:10 - 17:00 Open Spaces
Again, the subjects where suggested by members of the audience and Open Space where planned and subjects where discussed. And oh, don't forget the Code-Of-Conduct. And while others were talking about for example YOLOOps (Because that is what Agile DevOps is), I had a very nice talks other people that where not participating in an open space, but there where discussion of various IT subject non the less.