fbpx
Überspringen zu Hauptinhalt

Produkte & Lösungen

Ja. Wir haben Lösungen für Managed Docker bzw. Managed Kubernetes, die auf AWS ECS sowie AWS EKS basieren und sich nahtlos mit anderen AWS Diensten kombinieren lassen.

Nach Bereitstellung Cloud Umgebung erhalten Sie bzw. Ihre Entwickler eine persönliche Einführung in die neue Umgebung, eine Dokumentation sowie persönliche Unterstützung beim Umzug Ihrer Applikation durch unsere Mitarbeiter.

Ja, unbedingt. Wir stellen für Sie beim Setup Ihrer Cloud-Umgebung Mechanismen und Lösungen bereit, damit das Deployment (also Aufspielen bzw. Aktualisieren) Ihrer Applikation (Shop, PHP-App, CMS) einfach und stabil funktioniert – sowohl bei automatisch skalierenden Systemen als auch Docker.

Ja. Wir empfehlen dies sogar, da über GIT die Nachverfolgbarkeit von Änderungen gegeben ist.

Ja, wir unterstützen bei der Anbindung des Cloud-Deployments an Ihre CI bzw. Deployment-Pipeline (z.B. Bitbucket, GitLab, Jenkins).

Bei einer Cloud-Umgebung mit nur einem Web-Server wird das Aufspielen der Software per SSH direkt auf dem Web-Server angeboten. Bei Cloud-Umgebungen mit mehreren Web-Servern (bei Autoscaling bzw. Redundanz-Anforderungen) erfolgt das Deployment über ein Deployment-System, welches die Applikation automatisch auf die Web-Server verteilt. Dabei wird die Software von einer definierten Quelle (GIT, Download, FTP) automatisch bezogen und auf die verfügbaren Server verteilt. Die Installation auf jedem Server kann mittels eines Bash-Scriptes gesteuert werden. Hier gibt es weitere Details zu root360 Code Deploy.

Jede AWS-Umgebung bei root360 verfügt über Standard-Mechanismen, um Angriffe wie DDoS-Attacken zu begegnen. Dazu gehören:

  • netzwerkseitige Trennung von extern erreichbaren und nicht erreichbaren Systemen
  • restriktive Firewall-Regeln zwischen den Server
  • restriktive Netzwerk-ACLs zwischen den Netzwerksegmenten
  • Aktivierung AWS Shield (Managed DDoS Protection)
  • Einsatz von AWS Loadbalancern mit implementierten Erkennungs- und Vermeidungstechniken
  • Monitoring-Systeme zur Erkennung von DDoS Angriffen

Darüberhinaus steht uns ein breites Arsenal an weiteren Werkzeugen zur Verfügung, um Angriffe zu verhindern, zu erkennen und abzuwehren.

Wir sehen unseren Kompetenz-Schwerpunkt bei Web-Applikationen. Hier betreuen wir von Websites bis reichweitenstarken Portalen oder SaaS-Lösungen ein breites Spektrum an Kunden.

Im E-Commerce Bereich haben wir bei Spryker, Shopware, Magento und OXID wesentliche Kompetenzen für Managed Cloud Hosting mit AWS, Lastspitzen und Optimierung aufgebaut.

Unter Up-Scaling verstehen wir die Veränderung des Instanztyps eines AWS Diensts. Ein Beispiel: Es wird eine EC2-Instanz vom Typ „t3.medium“ genutzt. Diese soll zu einer „t3.large“ verändert werden.

Up-Scaling (also vertikale Skalierung) erfolgt in solchen Fällen manuell. D.h. wenn wir über unsere Metriken erkennen, dass andere Instanztypen für den derzeitigen Workload besser geeignet sind, ändern wir den Instanztyp unterbrechnungsfrei nach Rücksprache mit unserem Kunden. Dabei werden alle Instanzen neu aufgebaut und der alte Instanztyp terminiert.

Im Gegensatz dazu erfolgt die horizontale Skalierung im Rahmen der initial festgelegten Rahmenparameter automatisch. Bei Single Server Umgebungen ist ein Reboot für den Wechsel der Instanzgröße notwendig.

Hardware-Redundanz bedeutet für uns, dass ein Service (z.B. Webserver, Datenbank oder Cache) aus mindestens zwei Instanzen besteht und seine Daten zu jedem Zeitpunkt somit mindestens doppelt vorgehalten werden. Bei uns bedeutet Redundanz somit gleichzeitige erhöhte Ausfallsicherheit, da im Fall des Ausfalls einer Instanz sofort eine andere Instanz die Aufgaben übernimmt. Die ausgefallene Instanz wird dann erneuert und dem Service wieder hinzugefügt.

Ausfallschutz (Ausfallsicherheit) durch automatische Wiederherstellung bezieht sich bei uns auf Services (Webserver, Datenbank, Cache), die nur aus einer Instanz bestehen oder bestehen dürfen. Im Fall des Ausfalls dieser Instanz wird sie innerhalb weniger Minuten mit dem Datenstand vor dem Ausfall automatisch wieder zur Verfügung gestellt. Hierbei kann es in Einzelfällen zu Dateninkonsistenzen kommen, die dann über das Einspielen von Backups behoben werden müssen.

Im Fall des Ausfalls einer Instanz wird sie innerhalb weniger Minuten mit dem Datenstand von vor dem Ausfall automatisch wieder zur Verfügung gestellt. Hierbei kann es in Einzelfällen zu Dateninkonsistenzen kommen, die dann über das Einspielen von Backups behoben werden müssen. Um dieses verbleibende Restrisiko weiter zu reduzieren, empfehlen wir die Nutzung von mindestens zwei parallel laufenden Instanzen – wenn dies wie bei Web-Servern oder Datenbanken möglich ist.

Die Dimensionierung und Zusammenstellung der Hardware kann jederzeit angepasst werden bzw. erfolgt über Automatismen. Dennoch wird oft ein Ausgangspunkt – vor allem für die Einschätzung der Kosten – gewünsch. Daher fragen wir auch die grobe Dimensionierung der Hardware ab. Hier ist wichtig zu wissen, dass dies keine statische Festlegung ist. Ihre Cloud Umgebung wird (nur) mit der Hardware ausgestattet sein, dies sie tatsächlich benötigt.

Standardmäßig führen wir täglich (Nachts) Snapshots von allen Server und Datenbanken. Bei Bedarf kann die Frequenz erhöht werden. Details zum Backup finden Sie hier.

Ja, E-Mails können über mehrere Wege versendet werden:

  • Sendmail(): Der Standard in vielen PHP-Anwendungen. Es ist zu beachten, dass die Vorteile der flexiblen AWS-Infrastruktur bei vielen Spammern zum Einsatz kommen. Daher sind die IP-Bereiche von AWS bei vielen Mail-Server bereits negativ vorbelastet. Dieser Weg wird nicht empfohlen.
  • Externer SMTP-Server: Der Versand über einen Externen SMTP-Server als Mail-Relay ist eine gängige Möglichkeit für einen sicheren E-Mail Versand. Es ist auch hier zu beachten, dass AWS aus Gründen des Spamschutzes den Port 25 überwacht und ggf. reglementiert. Wir empfehlen daher den verschlüsselten Versand über TLS/SSL auf Port 465 oder 487.
  • AWS Simple E-Mail Service: AWS SES ist ein Mail-Relay, welcher bei fast allen großem Mail-Providern „whitelisted“ ist. Um dieses Qualitätsmerkmal aufrecht zu erhalten, muss jede Absender-Domain per DNS (TXT-Record) validiert werden.

Auf der AWS Infrastruktur können vorhandenen SSL-Zertifikate importiert und genutzt werden, sofern die Zertifikatsinformationen (Key, Zertifikat, ggf. Chain) vorhanden sind. Alternativ nutzen Sie die kostenfreien SSL-Zertifikate von AWS, die wir selbstverständlich für Sie managen.

Gerade bei Multi-Server Umgebungen kann das Zusammensuchen der einzelnen Logfiles zur Geduldsprobe werden. Bei uns werden die Logfiles automatisch zentral auf einem „Jump-Server“ 30 Tage vorgehalten. Dabei werden standardmäßig alle Logs der Applikation (Apache2, NGINX usw.) von allen Servern bereitgestellt. Es ist ebenfalls möglich, dass anwendungsspezifische Logs aufgenommen werden, sofern diese root360 bekannt sind.

Neben dem obligatorischen Zugriff auf die Cloud-Umgebung per SSH stellen wir unseren Kunden das root360 Cloud Dashboard zur Verfügung. Dieses Dashboard stellt Metriken wie CPU, RAM, Zugriffe, Auslastung der einzelnen Cloud-Komponenten im Kontext Ihrer konkreten Cloud-Architektur dar. Weitere Informationen dazu finden sich unter root360 Cloud Plattform.

Load More

An den Anfang scrollen