This blog has multiple authors and is updated continuously, during the conference - stay tuned - keep coming back”.
Yesterday was Kubernetes.
Today the keynote is about modernization. Do you follow every weird project posted on hackernews?!
80% of the budget is maintenance, and 20 % is innovation.
The main focus of the keynote is on Docker’s new Modernize Traditional Apps (MTA) POC Program for Docker EE. MTA is a program where select partners help customers running a proof of concept modernization of a few existing legacy apps and bring them to Docker EE without code changes. The program targets Java applications on Linux or .Net applications on Windows server.
The program has been developed together with major partners, such as Microsoft, and it was a bit unclear if the MTA program will only be handled by those big partners, or will be something offered to the market by regular partners like Praqma.
Docker is putting all its efforts in the introduction of Docker EE.
Markus Niskanen, Integration Management, Finnish railway is 150 years old “we have been doing containers, even before Docker”.
They only started the business case, if they could see a 40% reduction in cost by a conversion. “And since I’m standing here, it apparently worked.”
After the section about the Finnish Railways business case, Docker introduces the latest MTA partner - IBM. I guess this also answers the question above about whether or not MTA is an offering provided by smaller Docker partners.
Next on stage is, obviously, IBM. The main announcement is that they are now bringing major IBM products like WebSphere, messaging and DB2 to the Docker store.
They also announced Docker EE for IBM Cloud. We round this off with a live demo of starting a Docker EE cluster in IBM Bluemix, and deploying the good old JPetstore application.
To spice it up, this is not only the classic early millennia petstore sample. The sample has been extended with a mobile-friendly messaging frontend using Watson visual recognition to help you shop.
Then, comes the live demo from mobile phone: Send a message with a picture of a bunny, and Watson replies identifying it as a bunny and suggesting a suitable cute and jumpy item from the store.
A strong belief, loosely held: Bringing empathy to IT
Nirmal Mehta (@normalfaults), Docker Captain, talking about the culture challenges of adopting new technology.
“I love controlling the IP address allocation excel spreadsheet. I’m not too sure about this DEV-operations automation stuff”
Why does it take 100 days to get a
Let’s talk about Game theory. After mentioning a few different game theory concepts like zero sum games, prisoners dilemma and Nash equilibriums, Nirmal likens the conflict between Dev and Ops to the “golden balls” (aka. split or steal) game show with a few video clips from the old game show.
I find myself learning about things like “Pareto Inefficient Nash Equilibrium.”
The point he is trying to make, I think, is that you might have to change the rules of the game in your organization in order to allow people to make the right choices.
You are either building a learning org… or you will lose to someone who does”
His next topic is incentives. By example, an incentive where any change implemented as coded infrastructure automatically passes through the change review board and saves you weeks. It is easy to change behaviour if you reward the change in some form.
How can we help foster empathy?
- Strong opinions loosely held
- Active listening
- Avoid assumptions
- Incentivize teaching
- Incentivize learning
- Turn failure into understanding
- Recognize the stress levels of others
- Recognize burnout waves
Happiness at work:
- Assume people have positive intent
- Everything is solvable
- Never underestimate the power of human connections.
“Docker is a tool to foster empathy in your organization
“The core of DevOps is Empathy”
The value of diverse experiences
Nandhini Santhanam from Docker ventures into a talk about the value of diversity, starting with the question of what this diversity thing is.
Diversity in physiology, personalized skill sets and lastly multiple perspectives, the act of seeing and processing things differently.
As examples of lack of diversity, Nandhini presents the example of the car industry using crash test dummies that mostly match “male body” sizes, and voice recognition software that was originally trained mainly on caucasian voices.
When diversity reigns, thinking is more diverse, conversations become more diverse and this leads to more varied changes. Companies that embrace this thrive and do better.
Inertia is real. People gravitate towards similar individuals and have more natural self-expression in their native language. Going out of your way to overcome this often has no short term return on investment.
Good experiences for growing a more diverse team:
- hire from bootcamps - they naturally have more diverse attendees.
- candid feedback cycles - allows the quiet people a voice
- team building activities
- unconscious bias training
But there are pit-falls as well. It takes a conscious commitment to spend time, accept that change takes time and it is very hard to measure due to unclear metrics at the team level.
What can you do?
- Meet a colleague for lunch - someone from a different team, or with a different background
- When hiring think beyond school, experience or skill set
- Encourage the quiet ones to speak up
- Give the benefit of the doubt - conflicts in ideas are what you are trying to achieve, not trying to avoid.
And the closing take-away:
Start small, every step counts
For me, coming from Praqma, I think a lot of this rings very true. We also have grown from a rather homogenous 8-10 person company to a quite diverse 50-people company and gain great benefits from this. It sort of just happened when it did, but we noticed it, and now embrace it as an important part of our Praqma culture. We now do quite a bit of our recruitment from our Continuous Delivery Academy, where we teach students CI/CD for free during summer vacations.
And the guideline of starting small and doing small improvements obviously rings true with our approach to the technical world as well. It is not without reason that I go by the job title of “Continuous Improvement Agent”
It’s all about the community (theater)
One of the track is called Community Theater. It is a bunch of small talks by the large landscape of people who use Docker and everything around it.
During the two days, I’ve seen quite a few of them. Some very interesting, others just funny (look at one person go at making Docker containers visualization in a 3D landscape).
One of the talks I was really interested in was Containerizing Hardware Accelerated Applications by Chelsea Mafrica from Intel. A lot of the companies I’m working with have some hardware specific requirements, making them choose VM’s over containers right now.
But with the
--device mapping in Docker, you can actually have access to these capabilities right inside your Docker. This applies to ASICS, FPGA’s, and plain GPU’s. Chelsea made some performance tests on media conversion using the Intel GPU through three different set-ups displayed below.
The overall takeaway was that there is no significant performance degradation when using Docker over base host OS. And actually, having several containers running the same set-up multiple times made a small increase of throughput, but nothing that was worth mentioning.
Docker on Docker
The last talk of the day in the Docker Best Practices track is all about how Docker uses Docker to provide Docker infrastructure for Docker users using Docker and for the Docker developers building these Docker tools.
Previously Docker has provided their teams with groups od docker hosts using TLS certs for connection. This setup has been fully containerized the last 4 years with the Docker API being the only interface needed. The downsides were multiple deployment tools and imperative deployment scripts in Bash, Python or similar.
So, what was missing? Mainly a high level orchestration system, but things like user management and resource access control needed to be addressed as well.
A look inside saw Swarm as the obvious answer.
Just like the MTA approach discussed during the morning keynote, Docker approached this challenge with the “Don’t change anything” philosophy. Let’s add orchestration without messing with everything that already works.
From here, the talk took a technical deep dive into how the new orchestration setup was designed and various technical aspects of its design, that are too detailed to capture here.
With the new setup came a new model for deploying to production. The old imperative mindset was replaced by a declarative approach using compose and deployed with
docker stack deploy. All stack definitions obviously stored in version control.
Even supporting rolling updates and automated rollback was done through
update_config in the compose files. Access control was provided through Docker EE’s access features targeting container labels in the compose files.
All told, this new setup helped decouple hosts from applications thus allowing fail over and host replacements without a scale up -> replace -> scale down cycle.
- All of Docker SaaS running in Docker EE
- 80 worker nodes
- 60 swarm services
But the work continues in various areas. Coming soon at success.docker.com
Practical Design Patterns in Docker Networking
Dan Finneran (@thebsdbox) - Solutions Architect, Docker.
“Why have a talk about Design Patterns in Networking Architecture?” Dan Begins.
A slide appears, showing 23.5 million hits on Google and 5.3 tagged questions on Stack Overflow; because people clearly are curious about the topic!
After a short presentation of the historic network setup - every application had a machine, and every machine had its own IP, and LANs were used to segregate machines.
VMs appear, and things get a little better, we can start breaking up an application, but now, suddenly every part of an application has its own IP and VLANs are used for segregation.
“An abundance of IP addresses and complicated networks, and tasks for the network administrator, to make sure the network is configured as well.”
Enter, Docker Networking!
We’re presented a the different concepts, like Host- and Bridge Networking, for enabling more or less communication between hosts and containers, but also Swarm Overlay Networking, which is a way of enabling containers to communicate across hosts using VXLAN, automatically encrypted with AES with 12 hour key-rotation, (making this security-geek very excited!)
Macvlan is mentioned, a way of exposing a container as if it was an actual device on the network, discoverable by other devices, use with caution - possible IP overflow yet again, and it’s directly accessible from the network!
Tying it all together
We’re stepped through, (what certainly seemed like the morning topic), migration of a legacy application! (On a legacy network of course.)
It seems fairly straightforward, like a demo always does, but they’ve certainly made tools available that combined can first support a variety of setups, almost verbatim, and afterwards help in the process of updating the network structure.
Lastly a Docker EE feature, the UCP Architecture, is presented, which greatly helps with managing Docker and Kubernetes together; using a built-in Ingress-Controller (service-routing mechanic primarily from Kubernetes.)
It’s clear that a lot of energy has been put into making a flexible environment everyone should be able to fit in.
Stay tuned - there’s more to come - we’re blogging live from DockerCon in Copenhagen - hit refresh - maybe it already happened!