Zurück 
Im letzten Jahr haben wir eine Reihe von Blogs über NewEdge veröffentlicht, das Netzwerk oder die Infrastruktur, auf der wir die Netskope Security Cloud-Dienste bereitstellen, und es mit anderen Ansätzen von Cloud-Sicherheitsanbietern verglichen. Wir haben ausführlich über den grundsätzlichen Ansatz von Netskopezur Überwindung der inhärenten Leistungsbeschränkungen des öffentlichen Internets gesprochen. Außerdem haben wir darüber gesprochen , warum Backhauling (oder „Hairpinning“) innerhalb der Cloud eine schlechte Strategie ist, warum es bei der Abdeckung nicht nur um die Zählung von Rechenzentren geht und wie wichtig Peering und eine aggressive Verbindungsstrategie für die beste Leistung und Benutzererfahrung sind .
Ein Thema, das in Gesprächen mit Führungskräften aus den Bereichen Netzwerke und Infrastruktur häufig zur Sprache kommt und auf großes Interesse stößt, ist der Ansatz, den wir bei Netskope hinsichtlich des tatsächlichen Aufbaus und der Skalierung von NewEdge verfolgen. Ich persönlich freue mich sehr, diese Geschichte zu erzählen, da es zu meinen täglichen Aufgaben gehört, dies zu ermöglichen, und es mit meinen bisherigen Erfahrungen bei AWS, der weltweit größten und bekanntesten öffentlichen Cloud, übereinstimmt. Wir sind jetzt an einem Punkt angelangt, an dem wir NewEdge entmystifizieren und die Begeisterung unserer internen Teams für NewEdge nutzen möchten, um die Einzelheiten mit unseren Kunden und Partnern zu teilen.
Wir entwickeln NewEdge unter Berücksichtigung einer Reihe von Designgrundsätzen und das Ziel besteht darin, Verfügbarkeit, Leistung und Skalierbarkeit effektiv ins Gleichgewicht zu bringen. Da diese miteinander im Widerspruch stehen können, müssen wir nicht nur bewusste Entscheidungen darüber treffen, welche Hard- und Software wir jetzt verwenden, sondern auch um die Ecke denken und vorhersagen, was wir brauchen werden, bevor wir es brauchen. Unser aktueller Footprint mit über 50 Standorten nutzt eine Infrastruktur, die am ältesten Standort weniger als drei Jahre alt ist und von Dritten und unseren eigenen QA-Teams gründlich getestet wurde. Wir nutzen bei Bedarf erweiterte Plattformfunktionen, stürzen uns jedoch nicht kopfüber auf die neuesten Funktionen von Drittanbietern. Wo wir spezielle Funktionen benötigen, bauen wir sie selbst. Wir überdimensionieren das Netzwerk, um einen Puffer für die Skalierung vor Bedarf zu haben und wir arbeiten in einem nicht blockierenden Modus, sodass selbst wenn alle Dienste verfügbar sind, die Anwendung unserer Sicherheitsfunktionen den Kundenverkehr zu und von ihren SaaS-Anwendungen nicht drosselt. Bei Netskope unterliegt alles, was wir entwerfen, entwickeln und bereitstellen, einer Reihe von Grundprinzipien oder Werten, an die wir fest glauben, und unsere Kultur schreibt vor, dass wir unseren Fortschritt an diesen Prinzipien messen. Wir möchten die Frage beantworten können, ob wir das Leben unserer Kunden besser oder schlechter gemacht haben. Dazu nutzen wir Daten.
In diesem Blog werde ich einige Zeit darauf verwenden, die Rechenzentrumsstrategie von NewEdge zu erläutern und Ihnen die „Rechenzentrumsfabrik“ hinter NewEdge vorzustellen. Ich werde nicht nur im Detail darauf eingehen, was wir getan haben, sondern auch , warum wir es so getan haben. Außerdem werde ich einige unserer Best Practices weitergeben. Das Ziel besteht nicht nur darin, transparent zu sein und Sie von der Leistungsfähigkeit von NewEdge zu überzeugen, sondern auch darin, Erkenntnisse weiterzugeben, die Sie berücksichtigen können, wenn Ihr Unternehmen den bedeutenden Übergang in die Cloud vollzieht und wichtige Erkenntnisse der Cloud- und Hyperscale-Pioniere nutzen möchte.
Nutzen Sie einen schlanken Fußabdruck
Seit der Einführung von NewEdge vor etwa zwei Jahren haben wir unseren Rechenzentrums-Footprint vollständig neu gestaltet, indem wir Optimierungen in unserem gesamten Infrastruktur- und Softwareportfolio gefunden und implementiert haben. Unsere bisherige Architektur erforderte einen hybriden Mix aus mehreren physischen Racks vor Ort sowie eine erhebliche physische Präsenz in gehosteten Computerumgebungen. Wie viele unserer Konkurrenten verließen wir uns eine Zeit lang auf die öffentliche Cloud und konnten uns selbst von der unvorhersehbaren Leistung dieser Architekturen überzeugen, wenn es um die Bereitstellung von Inline-Sicherheitsdiensten in Echtzeit ging. Vor NewEdge beispielsweise erlebten wir erhebliche Leistungsschwankungen, da öffentliche Cloud-Anbieter den Datenverkehr entsprechend ihren Geschäftsanforderungen, Kosten oder anderen Faktoren umleiteten. Da die Latenzzeit für den Benutzerverkehr an manchen Standorten von einstelligen bis hin zu Dutzenden von Millisekunden (ms) reichte, kam es bei den Kunden zu Anwendungsproblemen, insbesondere dort, wo die Anwendungen empfindlich auf Jitter reagierten. Heute streben wir mit dem NewEdge-Footprint eine konstante Latenz im einstelligen Millisekundenbereich an. Dementsprechend brauchten wir eine Lösung, die leistungsstark, schlank und fokussiert ist und mehr Kapazität, Flexibilität und Leistung in einem einzigen Rack bietet. Darüber hinaus könnten wir durch den Einzel-Rack-Ansatz schnell reagiere