Inhaltsverzeichnis
FAQ

2. Ist Namesphere auch in AWS und Azure verfügbar?

Namesphere ist derzeit nicht direkt in AWS oder Azure verfügbar. Als Betreiber von Namesphere verfügt Metaways jedoch über umfassende Erfahrung im Kubernetes-basierten Plattformbetrieb in den Cloud-Umgebungen von AWS und Azure.
Das zugrunde liegende Verständnis von Platform-as-a-Service sowie der Full-Service-Management-Ansatz entsprechen dem von Namesphere. Weitere Informationen finden Sie unter: https://www.metaways.de

3. Wer steht hinter Namesphere?

Hinter Namesphere steht die Hosting Company Metaways Infosystems GmbH. Seit der Gründung im Jahr 2001 betreibt das Hamburger Unternehmen geschäftskritische Webanwendungen für Kunden aus dem Mittelstand und dem Enterprise-Umfeld und entwickelt eigene Open-Source-Software. Die Erfahrung aus über zwei Jahrzehnten Betrieb moderner Webplattformen ist direkt in die Entwicklung von Namesphere eingeflossen.
Die Stärken des Teams liegen insbesondere im projektorientierten Plattformbetrieb, im Full-Management-Ansatz sowie in der praktischen DevOps-Expertise.

4. Für welche Anwendungen eignet sich Namesphere?

Namesphere eignet sich besonders für moderne Webanwendungen, APIs und digitale Geschäftsapplikationen. Typische Einsatzszenarien sind E-Commerce-Plattformen, PIM- und Content-Management-Systeme, DXP-Systeme, Frontends für Headless-Architekturen, Unternehmensanwendungen oder individuelle Softwarelösungen.
Durch die Kombination aus Container-Plattform, gemanagten Plattformdiensten und automatischer Skalierung ist Namesphere sowohl für kleinere Projekte als auch für Anwendungen im Enterprise-Bereich geeignet.

6. Basiert Namesphere auf Kubernetes

Ja. Namesphere basiert auf einer Kubernetes-Plattform, die als mandantenfähiger Cluster betrieben wird. Anwendungen und Plattformdienste werden innerhalb logisch isolierter Projekte betrieben, sodass mehrere Anwendungen sicher voneinander getrennt laufen können.
Kunden profitieren damit von den technischen Vorteilen von Kubernetes wie Container-Orchestrierung, Skalierung und Hochverfügbarkeit, ohne sich selbst um den Betrieb oder die Administration eines Kubernetes-Clusters kümmern zu müssen.

7. Ist Namesphere eine PaaS-Plattform?

Namesphere kann als moderne Plattform-as-a-Service (PaaS) verstanden werden. Sie stellt eine vollständig gemanagte Laufzeitumgebung bereit, in der Anwendungen zusammen mit den benötigten Plattformdiensten betrieben werden können.
Im Unterschied zu vielen klassischen PaaS-Angeboten basiert Namesphere auf einer offenen Container- und Kubernetes-Architektur. Kunden behalten dadurch die volle Kontrolle über ihre Anwendungen und Container, während Betrieb, Skalierung und Verwaltung der Plattform von Namesphere übernommen werden.

8. Welche Plattformdienste stehen in Namesphere zur Verfügung?

Namesphere stellt eine Auswahl vollständig gemanagter Plattformdienste bereit, die direkt innerhalb einer Namesphere genutzt werden können. Dazu gehören aktuell PostgreSQL, MariaDB, Redis, Valkey, RabbitMQ, OpenSearch, Solr und Mercure.
Alle Plattformdienste werden durch die Plattform betrieben, überwacht und aktualisiert. Das Portfolio wird kontinuierlich weiterentwickelt und bei Bedarf projektbasiert erweitert.

9. Kann ich eigene Container in Namesphere betreiben?

Namesphere grundsätzlich als Container betrieben. Für jedes Betriebsprojekt richtet die Plattform innerhalb des Kubernetes-Clusters mehrere Namespaces ein.
Ein dedizierter Namespace steht dem Kunden für seine Anwendungen zur Verfügung. In diesem Namespace können Container-Images deployt, Konfigurationen verwaltet und auch mehrere Container-Replikas betrieben werden, um beispielsweise hochverfügbare Setups zu realisieren.
Weitere Namespaces werden von der Plattform für den Betrieb der Plattformdienste und Kubernetes-Systemdienste genutzt und vollständig durch Namesphere verwaltet. Dieses Modell gilt sowohl für die PROD- als auch für die STAGE-Umgebung.

11. Welche Aufgaben übernimmt Namesphere und was bleibt beim Kunden?

Namesphere übernimmt den vollständigen Betrieb der Plattform. Dazu gehören unter anderem Infrastruktur, Kubernetes-Cluster, Kubernetes-Systemdienste sowie alle bereitgestellten Plattformdienste wie Datenbanken, Messaging- oder Suchsysteme.
Der Kunde ist für den Betrieb seiner eigenen Anwendung verantwortlich. Dazu zählen insbesondere das Erstellen der Container-Images, das Deployment der Anwendung sowie die Applikationskonfiguration und -logik innerhalb des bereitgestellten Namespaces.
Dieses Modell trennt klar zwischen Plattformbetrieb durch Namesphere und Anwendungsbetrieb durch den Kunden.

12. Wer betreibt und aktualisiert die Plattformdienste in Namesphere?

Alle Plattformdienste werden vollständig durch Namesphere betrieben und verwaltet. Dazu gehören Installation, Konfiguration, Monitoring sowie regelmäßige Updates der Dienste.
Plattformdienste werden von der Plattform überwacht und bei Bedarf skaliert, sodass sie zuverlässig und hochverfügbar innerhalb der Namesphere betrieben werden können. Kunden müssen sich daher nicht um Wartung, Updates oder den technischen Betrieb dieser Dienste kümmern.

14. Wie unterscheiden sich STAGE und PROD technisch?

STAGE und PROD verfügen über die gleiche Plattformarchitektur und die gleichen Plattformdienste. Der Unterschied liegt vor allem in der Auslegung der Ressourcen und der Betriebsform.
Die Plattformdienste in der PROD-Umgebung werden in der Regel geclustert und hochverfügbar betrieben. Die STAGE-Umgebung ist dagegen für Entwicklungs- und Testzwecke ausgelegt und nutzt reduzierte Ressourcen. Typischerweise stehen dort etwa 50 % der Systemressourcen (CPU und RAM) der Produktionsumgebung zur Verfügung.

15. Kann eine Namesphere um weitere Umgebungen erweitert werden?

Ja. Neben den standardmäßig bereitgestellten Umgebungen PROD und STAGE kann eine Namesphere bei Bedarf um weitere Umgebungen erweitert werden. Dies kann beispielsweise sinnvoll sein, wenn Projekte zusätzliche Entwicklungs- oder Testumgebungen wie DEV, QA oder PRE-PROD benötigen.
Zusätzliche Umgebungen werden technisch nach dem gleichen Prinzip wie die bestehenden Umgebungen aufgebaut und in die Namesphere integriert. Dadurch lassen sich auch komplexere Entwicklungs- und Release-Prozesse innerhalb der Plattform abbilden.

16. Kann ich Anwendungen unabhängig in STAGE und PROD deployen?

Ja. STAGE und PROD sind vollständig voneinander getrennte Umgebungen. Anwendungen können daher unabhängig voneinander in beiden Umgebungen deployt werden.
Es gibt keine automatische Synchronisation oder Promotion zwischen STAGE und PROD. Kunden steuern selbst, wann und in welcher Version ihre Anwendungen in den jeweiligen Umgebungen deployt werden.

17. Wie deploye ich meine Anwendungen in eine Namesphere?

Anwendungen werden in Namesphere als Container betrieben. Kunden erstellen ihre Container-Images selbst und können diese über Git-basierte Workflows deployen.
Für jedes Betriebsprojekt stellt Namesphere einen dedizierten Kubernetes-Namespace für die Kundenanwendung bereit. In diesem Namespace werden die Container der Anwendung betrieben. Namesphere stellt dafür unter anderem eine Container Registry, Konfigurationsmechanismen sowie passende Berechtigungen zur Verfügung.
Mehrere Container-Replikas einer Anwendung können ebenfalls deployt werden, um beispielsweise skalierbare oder hochverfügbare Anwendungsarchitekturen umzusetzen.

19. Wie funktionieren die Service-Pläne (S, M, L, XL)?

In Namesphere werden Ressourcen über standardisierte Service-Pläne bereitgestellt. Diese Pläne definieren das Basis-Sizing für Plattformdienste, Object Storage, Traffic sowie für den Namespace, in dem die Kundenanwendungen betrieben werden.
Die einzelnen Pläne unterscheiden sich durch die bereitgestellten Ressourcen wie CPU, Arbeitsspeicher oder Speicherplatz. Typischerweise stehen mehrere Größenstufen wie S, M, L und XL zur Verfügung.
Durch dieses Planmodell lässt sich jede Namesphere individuell konfigurieren und mit einem initialen Basis-Sizing ausstatten, das zum jeweiligen Projekt und dessen Anforderungen passt.

20. Kann ich Ressourcen oder Service-Pläne später anpassen?

Ja. Gebuchte Service-Pläne können grundsätzlich angepasst werden, wenn sich die Anforderungen eines Projekts verändern.
Anpassungen von Service-Plänen erfolgen mit einem Vorlauf von mindestens fünf Werktagen zum Beginn eines neuen Abrechnungsmonats. Dadurch kann das Basis-Sizing der Namesphere für Plattformdienste, Anwendungen, Storage oder Traffic an veränderte Anforderungen angepasst werden.

21. Sind auch individuelle (größere) Pläne möglich?

Ja. Individuelle Pläne sind möglich, wenn das Basis-Sizing eines XL-Plans für die Anforderungen eines Projekts nicht ausreicht.
In solchen Fällen können Ressourcen für Plattformdienste, Anwendungen oder weitere Komponenten der Namesphere projektbezogen dimensioniert werden. Individuelle Pläne werden gemeinsam mit dem Kunden abgestimmt, um besondere Leistungs- oder Kapazitätsanforderungen zuverlässig abzudecken.

23. Was bedeutet digitale Souveränität bei Namesphere?

Digitale Souveränität bedeutet bei Namesphere, dass Infrastruktur und Plattformbetrieb unabhängig von globalen Hyperscaler-Plattformen erfolgen. Die Plattform wird auf eigener Infrastruktur betrieben und unterliegt damit europäischen rechtlichen Rahmenbedingungen.
Dadurch sind Kundendaten nicht von extraterritorialen Zugriffsmöglichkeiten betroffen, wie sie bei internationalen Cloud-Anbietern unter Umständen bestehen können.

24. Welche Sicherheitsmechanismen bietet Namesphere für Anwendungen?

Namesphere stellt eine sichere und stabile Plattformumgebung für den Betrieb von Anwendungen bereit. Dazu gehören unter anderem die Isolation von Projekten innerhalb der Kubernetes-Plattform, der überwachte Betrieb der Infrastruktur sowie der Betrieb und die Aktualisierung der Plattformdienste durch die Plattform.
Zusätzlich können optionale Sicherheitslösungen wie Web Application and API Protection (WAAP) eingesetzt werden, um Anwendungen vor Angriffen wie DDoS-Attacken, schadhaften Anfragen oder automatisierten Bots zu schützen.
Die Sicherheit der Anwendung selbst – beispielsweise auf Ebene des Anwendungscodes oder der Applikationslogik – liegt weiterhin in der Verantwortung des Kunden.

26. Gibt es ein Dashboard für meine Namesphere?

Ja. Für jede Namesphere stellt die Plattform ein eigenes Monitoring-Dashboard bereit. Dieses Dashboard bietet einen zentralen Überblick über Zustand, Auslastung und Performance der Anwendungen und Plattformdienste innerhalb des jeweiligen Betriebsprojekts.
Die Dashboards sind bereits vorkonfiguriert und können direkt genutzt werden, ohne dass zusätzliche Monitoring-Konfigurationen erforderlich sind.

27. Welche Metriken werden standardmäßig überwacht?

Namesphere stellt eine Reihe von Standardmetriken bereit, die einen schnellen Überblick über den Zustand der Plattform und der Anwendungen ermöglichen. Dazu gehören unter anderem Metriken zur CPU- und Speicherauslastung, zur Container-Laufzeit sowie zu Request- und Fehler­raten von Anwendungen.
Diese Standardmetriken sind bereits im bereitgestellten Dashboard integriert und ermöglichen eine schnelle Analyse von Performance und Systemzustand.

28. Kann ich eigene Metriken in Namesphere integrieren?

Ja. Neben den von der Plattform bereitgestellten Standardmetriken können Anwendungen auch eigene Metriken bereitstellen. Diese können beispielsweise aus der Anwendung selbst exportiert und in das Monitoring integriert werden.
Dadurch können neben technischen Systemmetriken auch anwendungsspezifische Kennzahlen überwacht werden.

30. Welche Arten von Supportanfragen werden unterschieden?

Im Betrieb der Plattform werden drei Arten von Anfragen unterschieden:

Störungen (Incidents)
Störungen sind Ereignisse, die den Betrieb einer Anwendung oder Plattformfunktion beeinträchtigen können. Incidents werden in der Regel durch das plattformeigene Monitoring erkannt und automatisch gemeldet. In solchen Fällen beginnt das Namesphere-Plattform-Team proaktiv und innerhalb der im SLA vereinbarten Reaktionszeit mit der Analyse und Behebung der Störung.

Change-Aufträge
Change-Aufträge betreffen Anpassungen an Konfigurationen oder Ressourcen innerhalb einer Namesphere, beispielsweise Änderungen an der Plattformkonfigurationen oder den Zugangsberechtigungen.

Allgemeine Support-Anfragen
Darunter fallen technische Fragen zur Nutzung der Plattform oder zum Betrieb von Anwendungen innerhalb einer Namesphere.
Diese Unterscheidung ermöglicht eine strukturierte Bearbeitung der unterschiedlichen Anfragearten.

31. Zu welchen Zeiten ist der Support erreichbar?

Der Plattform-Support ist zu definierten Supportzeiten erreichbar. Dabei wird zwischen Standard-Supportzeit und optional erweiterter Supportzeit für die Behandlung von Störungen unterschieden.

Standard-Supportzeit
Montag bis Freitag, 09:00 bis 18:00 Uhr CET (an Werktagen).
Während der Standard-Supportzeit werden Störungen (Incidents), Change-Aufträge sowie allgemeine Support-Anfragen bearbeitet.

Erweiterte Supportzeit (Entstörung)
Montag bis Freitag, 18:00 bis 09:00 Uhr CET sowie an gesetzlichen deutschen Feiertagen.
Diese erweiterte Supportzeit steht ausschließlich für die Behandlung von Störungen (Incidents) in der PROD-Umgebung zur Verfügung.

32. Welche Reaktionszeiten gelten für Störungen?

Für Störungen gelten definierte Reaktionszeiten im Rahmen der vereinbarten Service-Level. Diese beziehen sich auf die erste qualifizierte Reaktion des Supports auf eine gemeldete Störung. Störungen werden vom Kunden oder vom Monitoringsystem gemeldet.

33. Was beinhaltet der optionale 24×7-Support?

Der optionale 24×7-Support ermöglicht die Behandlung von Störungen in der Produktionsumgebung unabhängig von den Standard-Supportzeiten.
Dieser erweiterte Support gilt ausschließlich für Incidents in der PROD-Umgebung. Change-Aufträge und allgemeine Support-Anfragen werden weiterhin während der Standard-Supportzeiten bearbeitet.

34. Wie werden Änderungen und Updates an der Plattform kommuniziert?

Geplante Änderungen und Wartungsarbeiten an der Plattform werden in der Regel mindestens sieben Tage im Voraus angekündigt. Die Ankündigung erfolgt über die kundeneigene Ticketqueue im Supportsystem, sodass Kunden ausreichend Zeit haben, sich auf geplante Wartungsarbeiten vorzubereiten.
Regelmäßige Updates der genutzten Plattformdienste werden zunächst in der STAGE-Umgebung eingespielt. Treten dort keine technischen Störungen oder Beeinträchtigungen auf, erfolgt das Update in der Regel mit einem zeitlichen Versatz von etwa sieben Tagen auch in der PROD-Umgebung.
Durch dieses Vorgehen erhalten Kunden die Möglichkeit, ihre Anwendungen nach einem Update zunächst in der STAGE-Umgebung zu testen und eigene Funktions- oder Smoke-Tests durchzuführen, bevor Änderungen in der Produktionsumgebung wirksam werden.
Bei kritischen Wartungsarbeiten kann die Ankündigungsfrist im Einzelfall verkürzt sein.