OSMC 2020 | GET ON STAGE!

Hey folks, listen up!

OSMC’s call for papers is about to close. So prepare yourselves for the big monitoring stage and submit your paper.
We are looking for the latest trends, how-tos, case studies, best practices, future developments and anything that can help practitioners in their daily work. You can read more about CfP 2020 here.

The conference is aimed at professionals from the open source monitoring scene. The Open Source Monitoring Conference OSMC is about networking and meeting the international community. The lecture program provides up-to-date expert knowledge, and the workshops offer deep insights into various specialist areas. At the Hackathon, you build together with like-minded people on the project you always wanted to tackle.

So be there when the international open source scene meets in November at the monitoring hotspot Nuremberg! The conference will take place for the 15th time from November 16 to 19. You can find the ticket details here.

What are you waiting for? See you!

Pamela Drescher
Pamela Drescher
Head of Marketing

Pamela hat im Dezember 2015 das Marketing bei NETWAYS übernommen. Sie ist für die Corporate Identity unserer Veranstaltungen sowie von NETWAYS insgesamt verantwortlich. Die enge Zusammenarbeit mit Events ergibt sich aus dem Umstand heraus, dass sie vor ein paar Jahren mit Markus zusammen die Eventsabteilung geleitet hat und diese äußerst vorzügliche Zusammenarbeit nun auch die Bereiche Events und Marketing noch enger verknüpft. Privat ist sie Anführerin einer vier Mitglieder starken Katzenhorde, was ihr den absolut...
Kubernetes Nodegroups verwalten

Kubernetes Nodegroups verwalten

This entry is part 7 of 7 in the series Kubernetes - so startest Du durch!

Seit dieser Woche können unsere Kunden das “Nodegroup-Feature” für ihre NWS Managed Kubernetes Cluster nutzen. Was sind Nodegroups und was kann ich damit bewerkstelligen? Das und mehr erklärt unser siebter Blogpost der Serie.

Was sind Nodegroups?

Mit Nodegroups ist es möglich, mehrere Kubernetes-Node-Gruppen zu erstellen und unabhängig voneinander zu verwalten. Eine Nodegroup beschreibt eine Anzahl von virtuellen Maschinen, die als Gruppe diverse Attribute besitzt. Im Wesentlichen wird bestimmt, welches Flavor – also welches VM-Modell – innerhalb dieser Gruppe verwendet werden soll. Es sind aber auch andere Attribute wählbar. Jede Nodegroup kann unabhängig von den anderen jederzeit vertikal skaliert werden.

Wieso Nodegroups?

Nodegroups eignen sich, um Pods gezielt auf bestimmten Nodes auszuführen. Es ist zum Beispiel möglich, eine Gruppe mit dem “Availability-Zone”-Attribut zu definieren. Neben der bereits bestehenden “default-nodegroup”, die die Nodes relativ willkürlich über alle Verfügbarkeitszonen verteilt, können weitere Nodegroups erstellt werden, die jeweils nur in einer Verfügbarkeitszone explizit gestartet werden. Innerhalb des Kubernetes Clusters kann man seine Pods in die entsprechenden Verfügbarkeitszonen bzw. Node-Gruppen aufteilen.
Ein weiteres mögliches Szenario ist es, seine Nodegroups nach schnellen und langsameren VMs einzuteilen. Services und Anwendungen, die keine besonderen Ansprüche erheben, können der langsameren und somit meist auch günstigeren Nodegroup zugewiesen werden, während Pods mit mehr Anspruch ausschließlich auf schnellen Nodes betrieben werden. Der eigenen Fantasie und den eigenen Voraussetzungen wird durch die gewonnene Flexibilität Genüge getan. Neue Nodegroups lassen sich bequem über das NWS Web-Interface anlegen:

Existierende Nodegroups anzeigen


Im ersten Bild sieht man unseren exemplarischen Kubernetes Cluster “k8s-ses”. Dieser verfügt aktuell über zwei Nodegroups: “default-master” und “default-worker”.

 

Neue Nodegroup erstellen

Eine neue Nodegroup lässt sich über den Dialog “Create Nodegroup” mit folgenden Optionen erstellen:

  • Name: Name der Nodegroup, der später als Label für K8s genutzt werden kann
  • Flavor: Größe der eingesetzten virtuellen Maschinen
  • Node Count: Anzahl der initialen Nodes, kann später jederzeit vergrößert und verkleinert werden.
  • Availability Zone: eine spezifische Verfügbarkeitszone
  • Minimum Node Count: Die Nodegroup darf nicht weniger Nodes als den definierten Wert beinhalten.
  • Maximium Node Count: Die Nodegroup kann auf nicht mehr als die angegebene Anzahl Nodes anwachsen.

Die zwei letzten Optionen sind insbesondere für AutoScaling ausschlaggebend und begrenzen somit den automatischen Mechanismus.

 

 


Anschließend sieht man die neue Nodegroup in der Übersicht. Die Provisionierung der Nodes dauert nur wenige Minuten. Jede Gruppe lässt sich zudem individuell in ihrer Anzahl jederzeit verändern oder auch wieder entfernen.

 

Nodegroups im Kubernetes Cluster verwenden

Innerhalb des Kubernetes Clusters kann man seine neuen Nodes, nachdem sie fertig provisioniert wurden und einsatzbereit sind, sehen.

 
kubectl get nodes -L magnum.openstack.org/role
NAME                                 STATUS   ROLES    AGE   VERSION   ROLE
k8s-ses-6osreqalftvz-master-0        Ready    master   23h   v1.18.2   master
k8s-ses-6osreqalftvz-node-0          Ready    <none>   23h   v1.18.2   worker
k8s-ses-6osreqalftvz-node-1          Ready    <none>   23h   v1.18.2   worker
k8s-ses-zone-a-vrzkdalqjcud-node-0   Ready    <none>   31s   v1.18.2   zone-a
k8s-ses-zone-a-vrzkdalqjcud-node-1   Ready    <none>   31s   v1.18.2   zone-a
k8s-ses-zone-a-vrzkdalqjcud-node-2   Ready    <none>   31s   v1.18.2   zone-a
k8s-ses-zone-a-vrzkdalqjcud-node-3   Ready    <none>   31s   v1.18.2   zone-a
k8s-ses-zone-a-vrzkdalqjcud-node-4   Ready    <none>   31s   v1.18.2   zone-a

Die Node-Labels magnum.openstack.org/nodegroup und magnum.openstack.org/role tragen bei Nodes, die der Gruppe zugehörig sind, den Namen der Nodegroup. Zudem gibt es noch das Label topology.kubernetes.io/zone, das den Namen der Availability Zone trägt.

Mit Hilfe des nodeSelectors können Deployments oder Pods den Nodes bzw. Gruppen zugeordnet werden:

 
nodeSelector:
  magnum.openstack.org/role: zone-a

 

Du möchtest Dich selbst davon überzeugen, dass Managed Kubernetes bei NWS so einfach ist? Dann probiere es gleich aus auf: https://nws.netways.de/de/kubernetes/

Sebastian Saemann
Sebastian Saemann
Head of Managed Services

Sebastian kam von einem großen deutschen Hostingprovider zu NETWAYS, weil ihm dort zu langweilig war. Bei uns kann er sich nun besser verwirklichen, denn er leitet das Managed Services Team. Wenn er nicht gerade Cloud-Komponenten patched, versucht er mit seinem Motorrad einen neuen Rundenrekord aufzustellen.

Vom Bordstein zur Skyline von Robert Waffen | OSMC 2019

This entry is part 2 of 2 in the series OSMC 2019 | Recap

 

Auf der Open Source Monitoring Conference (OSMC) 2019 in Nürnberg hat uns Robert Waffen mit seinem Vortrag “Vom Bordstein zur Skyline” in den Bann gezogen. Für den Fall, dass jemand nicht die Möglichkeit hatte, an seinem Vortrag teilzunehmen, haben wir hier etwas vorbereitet: Seht euch das Video von Roberts “Kriegsgeschichte” – wie er selbst es nennt – an und lest weiter unten eine Zusammenfassung.

Die OSMC ist das jährliche Treffen internationaler Monitoring-Experten, auf dem zukünftige Trends und Strategien festgelegt werden. Seit 2006 findet die Veranstaltung jedes Jahr im Herbst in Nürnberg, Deutschland, statt. Führende Spezialisten präsentieren die ganze Bandbreite des Open Source Monitorings und stehen bereit, um Fragen zu beantworten, und seien diese noch so schwierig. Lernt neue Techniken kennen, tauscht Wissen aus und diskutiert mit Top-Entwicklern.

Ausführliche Workshops am Tag vor der Konferenz und ein Hackathon bieten weitere Möglichkeiten, eure Fähigkeiten zu erweitern und euer Wissen im Bereich IT-Monitoring und -Management zu vertiefen.

Die nächste OSMC findet vom 16. bis 19. November 2020 in Nürnberg statt.
Weitere Informationen und Tickets unter osmc.de.


Vom Bordstein zur Skyline

Der Talk von Robert Waffen “Vom Bordstein zur Skyline” handelt von den Monitoring-Entwicklungsstufen des Unternehmens Publicis Pixelpark.

Wie war der bisherige Stand im Monitoring?

Bei Robert Waffen in der Firma war schon Xymon oder – noch früher – Zabbix im Einsatz, was nicht richtig gepflegt wurde. Und wenn, dann nur zum Teil. Das dadurch entstandene Wissen wurde abgewandelt und daraufhin auf zwei Elk-Instanzen umgestellt. Als Metriken wurden nur Default-Metriken verwendet, also das, was das System standardmäßig bereitstellt. Dazu gehörten Metriken in 5-Minuten-Intervallen.

Das ganze Monitoring war weder automatisiert noch teilautomatisiert. Konfigurationen oder Interfaces konnte man einchecken, wenn man sich durchklickte.

 

Xymon

Xymon hat natürlich wie jedes andere Monitoring-System Checks, wodurch Auswertungen gemacht werden, wie zum Beispiel Shell. Dabei wurde meistens sehr viel Output produziert. Und zwar nicht wie beispielsweise in Icinga eine Zeile, sondern ganze Prozesslisten. Das ganze Interface war nicht dynamisch und wurde in HTML vorgerendert, was wiederum eigene Vor- und Nachteile hatte. Bei HD-Grafen, die auch gerne ein bisschen größer werden, mussten diese gelöscht werden. Das eigentliche Problem war, dass es sehr hohe Check-Intervalle gab und keine Anbindung an Grafana oder sonstiges möglich war, da Xymon aus den 1990er-Jahren kommt. Zudem ein Thema, das immer wieder zu Problemen führte: Es gab keine richtige Verschlüsselung.

 

Zabbix

Bei Zabbix hingegen macht das GUI alles. Es gibt zwar ein Puppet-Modul, welches einen Server aufbauen kann, aber das Modul kann den Server nicht konfigurieren, was problematisch ist. Weiter war ein Update auf die neueste Version nicht möglich, weil interne Probleme auftraten. Das heißt, man ist bei einer älteren Version hängen geblieben.

Probleme wurden prinzipiell zwar immer angezeigt, aber nicht welcher Art. In einem Monitoring wurde der Alarm aktiviert. Daraufhin musste man in einem anderen System nachsehen und eventuell dort das Problem ausfindig machen. Man musste in mehreren Interfaces nachsehen, was sehr umständlich war.

Der Aufbau der GUI in Zabbix war auch nicht logisch, wenn man es mit anderen Monitoring-Systemen vergleicht. Es zeigte nur an, wenn ein Problem auftrat. Das Host-Objekt an sich gibt es in Zabbix gar nicht, an dem man sieht, dass der Host up ist und der Host folgende Daten hat… Das wird nicht angezeigt, man muss erst nach diesen Informationen suchen.

 

ELK

Zudem gibt es zwei verschiedene ELK-Stacks. Ein Stack ist schon etwas älter und beinhaltet sensible Daten eines langjährigen Kunden, die auch separat gehalten werden sollen. Daneben gibt es einen neueren Stack der Version 6 mit entsprechender Umgebung. Die Stacks sind alle manuell aufgesetzt und eine nachträgliche Automatisierung scheint nicht möglich, da sonst Indexe oder ganze Konfigurationen verworfen werden oder ähnliches. Deswegen wird hier ein Neuaufbau geplant.

 

Graylog

Als Alternative zum ELK gibt es auch noch Graylog. Das wird für neuere Kunden eingesetzt und funktioniert ganz gut.

 

Wie ist der aktueller Stand im Monitoring?

Aktuell sieht das Monitoring bei Robert so aus: Zabbix und Xymon dienen als Hauptmonitoring. Hier wurde ein Grafana mit diversen Quellen hinzugebaut, wie InfluxDB, Prometheus, Graphite oder ElasticSearch. Daneben existiert ein Proof of Concept für Icinga 2 und ELK 7.

 

Prometheus

Wir haben von null angefangen und ein Prometheus aufgesetzt. Wenn man sich damit beschäftigt, meint man erst, oh, ja, Kubernetes, da ist alles schön und toll. Da deployed man sein YAMLs und es ist alles schön und sicher – bis man von Systemen außerhalb von Kubernetes auf Metriken zugreifen möchte. Mit einem Reverse Proxy davorgebaut, mit einem Apache und HTTPS, und einem IP Require, so dass nur der Prometheus-Server den Node Exporter abfragen darf.

 

Icinga 2

Bei Icinga 2 hat man einen Pock aufgesetzt, der vollautomatisch aus dem Puppet generiert wird. Das heißt, wenn man den Host wegreißt und neu startet, werden alle Hosts, Konfigurationen, Checks wie vorher angezeigt.

So weiß man, woher der Check kommt. In Vergleich mit Zabbix und Xymon weiß man weißt nicht, woher die Checks kommen und warum etwas anspringt. Viele sagen, man brauche Automatisierung erst dann, wenn man mehrere Server hat. Aber es geht auch darum, nachvollziehbar zu arbeiten, um Konfigurationen einsehen zu können.

 

Wie soll Monitoring in Zukunft aussehen?

Host-Inventarisierung: Wir haben viele Hosts, die keine Puppet-Module haben, Puppet ausgeschaltet ist oder eine alte Puppet-Version installiert ist. Wir müssen diese updaten und installieren und das ist teilweise schwierig wegen Solaris.

Benachrichtigungsplan erstellen: Man muss man sich ein Konzept überlegen, über was wann benachrichtigt werden soll. Zum Beispiel wenn ein Server nur tagsüber wichtig ist, braucht man keine Notifications in der Nacht. Dies ist zum Beispiel bei Testmaschinen der Fall, wenn es in der Testumgebung Probleme gibt. Wenn es sich allerdings um eine Produktionsumgebung handelt, möchte man rund um die Uhr benachrichtigt werden.

 

Saeid Hassan-Abadi
Saeid Hassan-Abadi
Junior Consultant

Saeid hat im September 2019 seine Ausbildung zum Fachinformatiker im Bereich Systemintegration gestartet. Der gebürtige Perser hat in seinem Heimatland Iran Wirtschaftsindustrie-Ingenieurwesen studiert. Er arbeitet leidenschaftlich gerne am Computer und eignet sich gerne neues Wissen an. Seine Hobbys sind Musik hören, Sport treiben und mit seinen Freunden Zeit verbringen.

Funk me Amadeus!

Seit geraumer Zeit haben viele unserer Hersteller angefangen, immer mehr Geräte mit LoRa-Technologie oder zusätzlicher WLAN-Funktionalität auszustatten sowie auf LTE-Empfang umzustellen. Die Vorteile liegen meistens auf der Hand:

  • Schlecht erreichbare Messpunkte können professionell angebunden werden
  • Messpunkte ohne Netzwerkzugriff können über LTE mit einer sehr guten Bandbreite angebunden werden
  • Einige Sensoren benötigen keine Messstation mehr, sondern können direkt mit der entsprechenden Monitoringsoftware kommunizern
  • Oft ist eine Kopplung bestehender Sensoren und Infrastrukturen möglich, da es durchaus Funkadapter für Sensor-Kabel oder potentialfreie Anschlüsse gibt
  • Vermeidung von Black Holes im 3G Mobilfunkbereich

 

LoRa-Technologie

Hier kann unser Hersteller AKCP auf ganzer Linie punkten, denn das L-DCIM ist ein drahtloses Mehrzweck-Sensor-Gateway mit LoRa™ Funktechnologie, WiFi, Ethernet und zwei USB-Eingängen und verfügt über einen integrierten AKCPro Server, der Überwachungsplattform von AKCP. Mit dem L-DCIM Gateway können die Daten von AKCP Sensoren – egal ob verkabelt oder über Funk – empfangen werden. Genauso können Geräte von Drittanbietern über SNMP oder Modbus überwacht werden. Mithilfe der Funk-Sensoren kann die Überwachungsumgebung einfach durch Hinzufügen weiterer Sensoren skaliert werden. Mit der Kombination aus L-DCIM Gateway und AKCPro Server können z. B. sämtliche intelligente Netzgeräte überwacht werden, wie PDU (Power Distribution Units), USV, Gleichrichter oder Klimageräte/-anlagen.

 

WLAN

HW group bietet hier zum einen die SD-Reihe an, die per WLAN direkt ohne zwischengeschaltete Basis mit der HW group eigenen SensDesk-Monitoring-Lösung kommunizieren kann. Sie verfügen alle über WiFi, Ethernet und PoE und sind in einem Metallgehäuse für die Hutschienen- oder Rackmontage erhältlich. SD-Geräte können alle Sensoren von HW group anschließen. Sie verfügen auch über Ausgänge, die über SensDesk gesteuert werden können. Direkt oder über Bedingungen.

Auch aus dem Hause HW group kann unter anderem das STE2 mit WLAN-Konnektivität aufwarten. Das STE2 ist eines unserer beliebtesten Messgeräte: Nach 4 Jahren und 13 000 verkauften Einheiten (leider nicht alle durch uns verkauft ;-D) hat HW group dieses Jahr nun ein Revision unter dem Namen STE2 R2 präsentiert. Auch das WLD2, das wir letzte Woche in unserem Blogpost vorgestellt haben, hat im Gegensatz zu seinem Vorgänger nun WLAN-Anschluss. Aktuell sind wir gerade dabei, beide neue Geräte-Versionen bei uns im Shop aufzunehmen und sie für Euch verfügbar zu machen. Solltet Ihr nicht solange warten können, dann lasst es uns wissen!

 

LTE-Standard

Wie die Überschrift bereits deutlich macht, ist LTE oder 4G mittlerweile nicht nur in der Technik und Industrie ein fester Standard, sondern auch im privaten Alltag. Man hat sich quasi an die hohe Bandbreite und die schnellen Übertragsungsraten gewöhnt. Und solche Bequemlichkeiten gibt man ja auch nicht mehr gerne auf.

Nicht nur bei den Geräten aus den Bereichen SMS-Gateways (SMSEagle, Braintower und MultiTech) oder LTE-Routing (Teltonika und AMIT), auch viele Messgeräte sind mittlerweile mit LTE-Funkverbindungen ausgestattet oder damit ausgerüstet worden. HW group bietet sowohl das Ares 10 als auch das Ares 12 als LTE Versionen an. Beim Hersteller AKCP gibt es z. B. den sensorProbe2+ auch mit optionalem 4G Modem.

 

Als Fazit können wir hier ziehen, dass einiges auf dem Markt aktuell in Bewegung ist. Selbstverständlich versuchen wir, auch mit unserem Angebot im Shop immer auf dem neuesten Stand zu sein – sollte uns dies einmal nicht gelingen und ihr vermisst ein Produkt, dann kontaktiert uns. WIr helfen gerne weiter!

Wir sind jederzeit für Euch erreichbar per Mail: shop@netways.de oder telefonisch unter der 0911 92885-44. Wer uns gerne bei der Arbeit ein bisschen über die Schulter schauen oder den Shop und die angebotenen Produkte verfolgen möchte, kann uns auch auf Twitter folgen – über @NetwaysShop twittert das NETWAYS Shop Team. Bleibt gesund – wir freuen uns auf Euch!

Nicole Frosch
Nicole Frosch
Sales Engineer

Ihr Interesse für die IT kam bei Nicole in ihrer Zeit als Übersetzerin mit dem Fachgebiet Technik. Seit 2010 sammelt sie bereits Erfahrungen im Support und der Administration von Storagesystemen beim ZDF in Mainz. Ab September 2016 startete Sie Ihre Ausbildung zur Fachinformatikerin für Systemintegration bei NETWAYS, wo sie vor allem das Arbeiten mit Linux und freier Software reizt. In ihrer Freizeit überschüttet Sie Ihren Hund mit Liebe, kocht viel Gesundes, werkelt im Garten, liest...

Is there a Company Backing PostgreSQL?

That’s a question I got asked when I was helping out at the PostgreSQL booth at this year’s FOSDEM.

I replied “yes”. And a second later, “there are even several!”.

But although the nerd density at FOSDEM is ridiculously high, I’m not sure he got that boolean joke “Are you going for lunch now or later?” “Yes.” … so, in the faint hope that, that guy will stumble upon this blogpost and hopefully as a nice read too many others, let me elaborate on that a bit.

PostgreSQL was Initially a Research Project

Back in the 1970’s, even in the US, universities could do research on things that would not directly lead to a patent for the corporate sponsor and a spinoff (owned predominantly by the corporate sponsor). They even received public money for such kind of research (whoo!), often from the DARPA.

Michael Stonebraker and Eugene Wong, who started PostgreSQL’s predecessor Ingres, were funded by a couple of military agencies, more detail here.

Stonebraker in fact did the spinoff “stunt” with Ingres which exists until today. However he returned to Berkeley to continue research on a “Post-Ingres” system, “Postgres”. Yada yada yada, long story short, Postgres was basically handed over to a group of enthusiast who kept working on it and turned it into PostgreSQL over time (we’re discussing the mid-90’s here). Some of those initial enthusiasts are still actively working on the project btw., one, Bruce Momjian, even attending FOSDEM on a regular basis!

It Today is a Community Project

The database system today is “owned”, which is in fact impossible due to the ridiculously open license, be the PostgreSQL Global Development Group, a non-profit that mainly runs the different postgresql.org sites. Alongside, there are several national & international non-profits, e.g. PgUS, PgEU and countless local usergroups, see the community page to get an idea.

… that allows a lot of Companies to generate Profit of it

So, people started doing serious stuff with Postgres, ran into problems and had them resolved, wanted advice on certain issues, get trained, or just someone to look after their databases on a regular base. Companies were founded, that specialised on PostgreSQL support and consulting. Some of these vanished, some still exist.

Some of these companies offer proprietary products that base on PostgreSQL. Also, there were “spinoffs”, companies that took the PostgreSQL code and ran with it, making something new of it. Just as well, some of these still exist and make good business.

… which some Feed Back partly into the Project

Many, if not most, of these companies contribute to PostgreSQL one way or the other. As a matter of fact, the vast majority of the core team members and major contributors work for a handful of companies.

Still, these people are probably working for those companies, because they are major contributers. E.g. Tom Lane these days works for Crunchy Data, but has been working for e.g. Red Hat and Salesforce before (rumours are that Salesforce hiring Tom was a huge factor in the Salesforce-Oracle “war” and led to their 2013 partnership – most probably due to a massive discount that Salesforce were willing to agree to…).

Corporate contributions are mostly code by hiring people, who hack on PostgreSQL and money by sponsoring infrastructure or events.

The community is rather small, so is the circle of corporate players. At the end of the days, everyone knows everyone and is engaged in a coopetition.

Most corporate code contributions stem from their customers’ requirements. Some improvements go to the proprietary variants first, very few go there only. However, the ultimate goal usually is to get a feature into the core product, so mainline, community PostgreSQL.

So how does this Model differ from Other Popular Projects?

Linux

These days, when we mention the kernel, we usually mean Linux, that has the Linux Foundation, essentially backed by all major players in IT, which realised that Linux is useful to them and decided to fund the development (essentially ending the UNIX wars).

There are only few, if at all, companies that “span off” the kernel, but the vast majority of code contribution these days is coming from corporations or their employees.

Some of these in turn “sell” Linux as distributions, essentially subscriptions today. Their share of Kernel contributions is a huge selling point.

Others, take NIC or SCSI controller manufacturers for example, were initially (like, 25 or 20 years ago) just hoping to sell a few more of their products by offering some nerd enthusiasts specs and technical documentation. Today, they know they just can’t sell anything that isn’t properly supported by Linux, and thus are willing to hire full-time developers to ensure so.

All of those contributions still go over the “benevolent dictator“‘s desk or one of his aides’ and thus have to fulfil certain requirements. And the distributors agreed years ago to only include mainline features in their products, to avoid fragmentation.

A major difference to PostgreSQL: all those companies (distributors aside) use Linux for their resp. products, not as their product.

MySQL / MariaDB

MySQL initially was written by the founders of MySQL AB, which was acquired by SUN in 2008, which in turn was acquired by Oracle in 2010.

While being an Open Source product and even being GPL-licensed as Free Software, MySQL was never renowned for being very open to contributions, however MySQL AB and SUN were striving to improve the product, based on what the “community” was wishing.

Oracle, being the major player in the RDBMS market, obviously has no interest in improving a “free” piece of software to a degree that it could effectively cannibalise their core product … so, the MySQL founders founded MariaDB and took a significant part of the MySQL developers with them.

Both products still evolve, but development is steered and driven by Oracle and MariaDB respectively (no idea what I should think of the MariaDB Foundation, to be totally honest), so probably to a good degree by the marketing departments and in Oracle’s case, fenced by the limitations from “above”.

Sure, you can get support from independent companies (many of those also offering PostgreSQL services, btw.). However, any large customer like financial institutions, the public sector, etc. prefer to go “straight to the source”, so chances are that offering support will stay a niche market. Percona maybe being the exception.

MongoDB et. al.

The “NoSQL” market is (IMHO) to a certain degree a reply to the pricing policy of RDBMS vendors and the “better safe than sorry” mentality of many IT managers. But that’s a different story …

However, a certain pattern has evolved over the last years:
Some Open Source projects become popular, companies are founded, the development is centralized there, conferences and trainings are offered etc.
And at some point, someone decides that actually earning money would be a nice idea …

So, an “enterprise” product is introduced, or a dual-license model, or a cloud service with limitation of competitors’ ability to offer such, etc. pp.

In essence, these are often Open Source products, but not Free Software. They sometimes get crippled beyond recognition.
The communities could sometimes be called that way because the mawning people in the forums are “managed” by “community members”.

Is this healthy? Couldn’t a Company buy PostgreSQL, like Oracle did with MySQL?

Short: No.
Longer: Sure, e.g. Oracle could probably buy one or most of those companies, but the product PostgreSQL is not “theirs”. I mean, even MySQL was forked after the acquisition of SUN …

We’ve seen PostgreSQL companies get bought, sometimes they even disappear from their “natural” markets.
But that had no significant impact on the project’s structure, pace or harmony.

PostgreSQL

  • is “smaller” than MySQL, Linux or many other important FOSS projects
  • we don’t have the Kernel.org power
  • nor Oracle’s cash and licensing department
  • is not controlled by any single entity, thus
  • “more free” than many other “open source” projects/products
  • can not be bought, shut down or in any way be tampered with
  • will never change its license
  • will never disappear
  • yet feeds a lot of mouths directly and many, many more indirectly, like your humble author here
  • many contribute back one way or the other

PostgreSQL is much closer to the Linux model, coopetition of many companies, plus a fair share of “private” contributors, than to any other Open Source DBMS, relational or not.

This worked very good for the last 25 years, and I doubt it will ever change.

As someone (was it Bernd Erk?) coined:
> “PostgreSQL doesn’t have a community, it is one!”

I second that!

Über den Author:

Gunnar “Nick” Bluth hat seine Liebe zu relationalen Datenbanken Ende des letzten Jahrtausends entdeckt. Über MS Access und MySQL 3.x landete er sehr schnell bei PostgreSQL und hat nie zurückgeschaut, zumindest nie ohne Schmerzen. Er verdient seine Brötchen seit beinahe 20 Jahren mit FOSS (Administration, Schulungen, Linux, PostgreSQL). Gelegentlich taucht er auch tiefer in die Programmierung ein, so als SQL-Programmierer bei der Commerzbank oder in App-Nebenprojekten.
Thomas Widhalm
Thomas Widhalm
Lead Support Engineer

Thomas war Systemadministrator an einer österreichischen Universität und da besonders für Linux und Unix zuständig. Seit 2013 möchte er aber lieber die große weite Welt sehen und hat sich deshalb dem NETWAYS Consulting Team angeschlossen. Er möchte ausserdem möglichst weit verbreiten, wie und wie einfach man persönliche Kommunikation sicher verschlüsseln kann, damit nicht dauernd über fehlenden Datenschutz gejammert, sondern endlich was dagegen unternommen wird. Mittlerweile wird er zum logstash - Guy bei NETWAYS und hält...