© Liashko/Shutterstock.com
Entwickler Magazin
Interview mit Brandon Philips, CTO von CoreOS

„Container lösen Deployment- und Packaging-Probleme!“

Entwickler Magazin Spezial: Hi Brandon, bitte stell dich kurz vor!

Brandon Philips


Brandon Philips: Meine Karriere habe ich bei SUSE begonnen, wo ich mich im Lab-Team mit dem Linux-Kernel beschäftigt habe. Bei Rackspace habe ich an einem großen, verteilten Monitoringsystem sowie an einem Monitoringagent gearbeitet, der auf lua+libuv (luvit) aufgesetzt hat, worauf täglich zehntausende Maschinen laufen. Als CTO von CoreOS beschäftige ich mich derzeit mit zahlreichen neuen Technologien rund um Container und verteilte Systeme wie etcd und Docker.EMS: Wie kamen du und Alex [Koentwicker Alex Polvi, Anm. der Red.] auf die Idee, CoreOS zu entwickeln?Brandon: CoreOS ist aus den Erfahrungen entstanden, die wir bei zahlreichen, großen Projekten gesammelt haben. Dabei haben wir gemerkt, dass das Management von Betriebssystemen viel Zeit kostet – Zeit, die nicht fürs Entwickeln genutzt werden kann. Ferner gab es die problematische Tendenz, Anwendungen an spezifische Runtime-Versionen, Bibliotheksversionen und andere Teile einer Linux-Distribution zu binden. Aufgrund dieser Abhängigkeiten musste man immer ein Pseudo-Fork des Betriebssystems maintainen, während man auf Runtime- und Bibliotheksversionen die Layer setzte, die die eigene Anwendung zum Laufen benötigte. Und meistens kämpfte man noch damit, das Ganze in /opt oder /usr/local zu kapseln.Wir dachten uns, dass ein Betriebssystems, das weniger API-Versprechen auf Basis von Bibliotheken und Runtimes macht und stattdessen dem Nutzer dabei hilft, Anwendungen in Linux-Containern laufen zu lassen, das Leben von Entwicklern und Admins deutlich vereinfachen würde. Ein kleineres, fokussierteres Betriebssystem versetzt uns ferner in die Lage, konsistente, automatisierte Updates zu realisieren. Indem wir den Updatezyklus eines Clusters bis zum Ende durchgedacht haben, haben wir verstanden, dass Stammfunktionen von verteilten Systemen, wie etcd und fleet, erforderlich waren, um Anwendungen auf Clustern mit Selbstupdatefunktion laufen zu lassen.EMS: Was ist deiner Meinung nach der spannendste Aspekt eurer Arbeit an CoreOS im vergangenen Jahr?Brandon: Es gab viele! Ich denke, die Integration von etcd war ein großes Highlight. Als wir mit dem Projekt begannen, hatten wir einen Wunsch: Denjenigen eine Alternative zu bieten, die so etwas wie ein „Goo­gle Chubby“-System für eine konsistente Konfiguration und einen Service-Discovery-Store benötigen. Wir wollten ein System bauen, mit dem die Leute dank moderner APIs einfach interagieren können und das ihnen gleichzeitig konsistente und sichere Methoden für Lock...

Entwickler Magazin
Interview mit Brandon Philips, CTO von CoreOS

„Container lösen Deployment- und Packaging-Probleme!“

Entwickler Magazin Spezial: Hi Brandon, bitte stell dich kurz vor!

Brandon Philips


Brandon Philips: Meine Karriere habe ich bei SUSE begonnen, wo ich mich im Lab-Team mit dem Linux-Kernel beschäftigt habe. Bei Rackspace habe ich an einem großen, verteilten Monitoringsystem sowie an einem Monitoringagent gearbeitet, der auf lua+libuv (luvit) aufgesetzt hat, worauf täglich zehntausende Maschinen laufen. Als CTO von CoreOS beschäftige ich mich derzeit mit zahlreichen neuen Technologien rund um Container und verteilte Systeme wie etcd und Docker.EMS: Wie kamen du und Alex [Koentwicker Alex Polvi, Anm. der Red.] auf die Idee, CoreOS zu entwickeln?Brandon: CoreOS ist aus den Erfahrungen entstanden, die wir bei zahlreichen, großen Projekten gesammelt haben. Dabei haben wir gemerkt, dass das Management von Betriebssystemen viel Zeit kostet – Zeit, die nicht fürs Entwickeln genutzt werden kann. Ferner gab es die problematische Tendenz, Anwendungen an spezifische Runtime-Versionen, Bibliotheksversionen und andere Teile einer Linux-Distribution zu binden. Aufgrund dieser Abhängigkeiten musste man immer ein Pseudo-Fork des Betriebssystems maintainen, während man auf Runtime- und Bibliotheksversionen die Layer setzte, die die eigene Anwendung zum Laufen benötigte. Und meistens kämpfte man noch damit, das Ganze in /opt oder /usr/local zu kapseln.Wir dachten uns, dass ein Betriebssystems, das weniger API-Versprechen auf Basis von Bibliotheken und Runtimes macht und stattdessen dem Nutzer dabei hilft, Anwendungen in Linux-Containern laufen zu lassen, das Leben von Entwicklern und Admins deutlich vereinfachen würde. Ein kleineres, fokussierteres Betriebssystem versetzt uns ferner in die Lage, konsistente, automatisierte Updates zu realisieren. Indem wir den Updatezyklus eines Clusters bis zum Ende durchgedacht haben, haben wir verstanden, dass Stammfunktionen von verteilten Systemen, wie etcd und fleet, erforderlich waren, um Anwendungen auf Clustern mit Selbstupdatefunktion laufen zu lassen.EMS: Was ist deiner Meinung nach der spannendste Aspekt eurer Arbeit an CoreOS im vergangenen Jahr?Brandon: Es gab viele! Ich denke, die Integration von etcd war ein großes Highlight. Als wir mit dem Projekt begannen, hatten wir einen Wunsch: Denjenigen eine Alternative zu bieten, die so etwas wie ein „Goo­gle Chubby“-System für eine konsistente Konfiguration und einen Service-Discovery-Store benötigen. Wir wollten ein System bauen, mit dem die Leute dank moderner APIs einfach interagieren können und das ihnen gleichzeitig konsistente und sichere Methoden für Lock...

Neugierig geworden?


   
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang