Erst den Arbeitsort bestimmen, dann den Serverstandort
Singapur, Tokio, Seoul, Hongkong und der Westen der USA – alle mit guter Verfügbarkeit.
Wählen Sie für Teammitglieder, die regelmäßig am Desktop arbeiten, zunächst einen Standort in ihrer Nähe. Berücksichtigen Sie anschließend auch die Wege für Builds und Dateiübertragungen. Sie mieten einen dedizierten physischen Mac mini, keine virtuelle Maschine. Die Verbindung hängt vom Standort, dem Internetanbieter und dem genutzten Netzwerk ab.
Alle 5 Standorte zum gleichen Preis, ab $21.8/Tag. Die aktuelle Verfügbarkeit sehen Sie bei der Bestellung im Portal.
Standorte
Die folgenden Einzugsgebiete helfen bei der Vorauswahl, sind aber keine Garantie für eine bestimmte Route oder Latenz. Beide Konfigurationen sind an allen 5 Standorten verfügbar. Wählen Sie zuerst den Standort und anschließend die Ausstattung passend zu Speicher- und RAM-Bedarf Ihres Projekts.
Einzugsgebiet: Südostasien
Platzieren Sie tägliche Arbeit und Builds in der Nähe Ihres Teams in Südostasien. Klären Sie bei Schichtübergaben zuerst, ob Aufgaben der vorherigen Schicht noch laufen, bevor Sie dieselbe Maschine übernehmen.
Einzugsgebiet: Japan und Ostasien
Für Desktop-Aufgaben mit häufigen Klicks, Scrollen und Vorschauen bietet sich ein Standort in der Nähe Ihres Teams in Japan an. Auch für andere Arbeitsorte in Ostasien kommt Tokio infrage – prüfen Sie die Verbindung mit Ihrem tatsächlichen Netzwerk.
Einzugsgebiet: Korea und Nordostasien
Teammitglieder in Korea können die grafische macOS-Oberfläche an einem nahegelegenen Standort bedienen. Seoul und Tokio liegen zwar in derselben Zeitzone; daraus lässt sich aber nicht ableiten, dass auch die Netzwerkverbindungen gleich funktionieren.
Einzugsgebiet: Südchina, Hongkong, Macau und Taiwan
Berücksichtigen Sie bei der Wahl die Anforderungen an grafische Arbeit Ihres Teams in Südchina, Hongkong, Macau und Taiwan. Für Nutzer auf dem chinesischen Festland spielen auch der lokale Internetanbieter und die grenzüberschreitende Verbindung eine Rolle: Die geografische Nähe garantiert keine niedrige Latenz.
Einzugsgebiet: US-Westküste
Teammitglieder an der US-Westküste können Desktop-Aufgaben und Regressionstests an einem Standort in ihrer Nähe erledigen. Halten Sie bei Übergaben an Teams in Asien-Pazifik auch das Datum fest, damit ein Wechsel auf den vorherigen oder nächsten Tag nicht übersehen wird.
Die Ortszeit wird anhand der Gerätezeit berechnet und jede Minute aktualisiert. Für den Westen der USA wird die Sommerzeit automatisch berücksichtigt. Die Uhrzeit ist keine Überwachung der Standortverfügbarkeit. Maßgeblich ist der aktuelle Status im Portal.
Verbindung einschätzen
Da derzeit keine belastbaren RTT-Werte für die Standorte vorliegen, finden Sie hier Auswahlkriterien nach Einzugsgebiet und Aufgabe – ohne beispielhafte Millisekundenwerte oder unbelegte Rückschlüsse aus der Entfernung.
| Standort | Einzugsgebiet | Geeignet für | Nach dem Verbinden prüfen |
|---|---|---|---|
| Singapur | Südostasien | Remote-Desktop, Builds, Dateiübertragungen | Reaktionszeit für Teammitglieder in Südostasien sowie die Wege für Projekt-Downloads und Build-Artefakte. |
| Tokio | Japan und Ostasien | Remote-Desktop, Builds, Dateiübertragungen | Tastatur- und Mausreaktionen für Teams in Japan und Ostasien sowie die Zuverlässigkeit beim Herunterladen von Projektabhängigkeiten. |
| Seoul | Korea und Nordostasien | Remote-Desktop, Builds, Dateiübertragungen | Wie flüssig Teammitglieder in Korea und Nordostasien arbeiten können und ob Dateiübertragungen unterbrochen werden. |
| Hongkong | Südchina, Hongkong, Macau und Taiwan | Remote-Desktop, Builds, Dateiübertragungen | Die Verbindung während der üblichen Arbeitszeiten der Hauptnutzer – nicht nur das Ergebnis eines einzelnen RTT-Tests. |
| Westen der USA | US-Westküste | Remote-Desktop, Builds, Dateiübertragungen | Die Bedienung für Teams an der US-Westküste und die Übertragungswege für Artefakte bei Übergaben an Teams in Asien-Pazifik. |
Die tatsächliche Verbindung hängt vom verwendeten Netzwerk ab. Ruckler können auch durch das lokale Netzwerk, die Bildübertragung oder die Auslastung der Maschine entstehen. Ein einzelner RTT-Test reicht nicht aus, um diese Ursachen auseinanderzuhalten.
Nach Aufgaben auswählen
Ermitteln Sie zuerst, wer täglich am Desktop arbeitet, und wählen Sie einen Standort in der Nähe dieser Person. Für den Remote-Desktop im Browser brauchen Sie einen aktuellen Browser und eine stabile Verbindung. Häufiges Ziehen, Scrollen und Betrachten der Oberfläche erfordert eine besonders flüssige Interaktion.
Klären Sie zuerst, wer Code, Abhängigkeiten und Build-Artefakte hoch- und herunterlädt. Richten Sie den Standort dann nach dem überwiegenden Teil des Teams aus. Builds lassen sich auch über SSH per Kommandozeile starten. Die Verbindung zum Desktop sagt nichts Verlässliches über die Kompiliergeschwindigkeit aus.
Wenn Teammitglieder in Asien-Pazifik und im Westen der USA arbeiten und beide Seiten häufig direkten Zugriff brauchen, können Sie jeweils eine Maschine mieten. Beide Instanzen werden separat abgerechnet und speichern ihre Daten getrennt. Halten Sie sie über das Code-Repository und die Übergabe von Artefakten auf dem gleichen Stand; Dateien werden nicht automatisch synchronisiert.
Beispiele für verteilte Teams
Die folgenden Beispiele veranschaulichen die Standortwahl. Es handelt sich weder um Kundenberichte noch um Latenzmessungen. Erfassen Sie zunächst Arbeitsorte und Hauptaufgaben der Teammitglieder. Entscheiden Sie dann, ob eine gemeinsame Maschine für die Übergabe genügt oder ob Sie an beiden Standorten eine Instanz benötigen.
Hongkong und Singapur kommen infrage. Arbeitet der Hauptnutzer am Desktop in Südchina, bietet sich zunächst Hongkong an. Erledigt das Team in Südostasien hauptsächlich Builds und den Umgang mit Artefakten, sollten Sie zuerst Singapur prüfen. Entscheidend bleibt die Verbindung über Ihr tatsächliches Netzwerk.
Tokio und Seoul kommen infrage. Da beide Standorte in derselben Zeitzone liegen, können Sie den Standort nach dem Hauptnutzer auswählen und anschließend die Reihenfolge für die Nutzung des Desktops abstimmen. Eine Maschine wird jeweils einem Kunden zugewiesen; mehrere Personen können sich bei gleichzeitiger Nutzung dennoch gegenseitig beeinträchtigen.
Der Westen der USA bietet sich als Standort in Teamnähe an. Vor der Übergabe aus Asien-Pazifik sollte das Team den Code bereitstellen und den Aufgabenstatus dokumentieren. Das Team an der US-Westküste prüft die Version, bevor es die Regressionstests startet. Bei einer zweiten Maschine müssen Toolchain und Abhängigkeiten zuerst abgeglichen werden.
Vor der Bestellung beachten
Derzeit stehen die 5 aufgeführten Standorte zur Verfügung. Eine bestehende Instanz wird nicht automatisch verschoben, wenn Sie die Region ändern. Für einen Wechsel öffnen Sie im Portal eine neue Instanz am Zielstandort und übertragen anschließend Projekt und Toolchain.
Prüfen Sie das Projekt-Repository, nicht committete Dateien, Signaturzertifikate, Provisioning-Profile und Versionen der Abhängigkeiten. Halten Sie fest, welche Aufgaben auf der bisherigen Maschine laufen, damit während des Umzugs keine Builds doppelt ausgeführt und keine Artefakte vergessen werden. Solange beide Instanzen parallel laufen, werden sie separat abgerechnet.
Richten Sie Xcode und die Abhängigkeiten auf der Zielinstanz ein und führen Sie einen Projekt-Build aus. Bei CI müssen Sie außerdem den Build-Rechner neu registrieren und die Jobs prüfen. Informieren Sie das Team erst, wenn Desktop und Dateipfade funktionieren, und aktualisieren Sie dann die Verbindungsdaten und Übergabenotizen.
Gleiche Preise an allen Standorten
UDP M4 16: M4 / 16GB / 256GB SSD für $21.8/Tag. UDP M4 24: M4 / 24GB / 512GB SSD für $40.9/Tag. Zur Auswahl stehen 4 Abrechnungszeiträume: Tag, Woche, Monat und Quartal. Die Abrechnung der Instanz beginnt nach erfolgreicher Zahlung.
Zahlung nur per USDT-TRC20 oder Visa / Mastercard / Amex über Stripe. Abgerechnet wird ausschließlich in US-Dollar. Welche Zahlungsoptionen verfügbar sind, hängt von der Rückmeldung des Zahlungs-Gateways ab.
Wählen Sie zuerst den hauptsächlichen Arbeitsort Ihres Teams, dann Konfiguration und Laufzeit. Stimmen Sie bei grenzüberschreitender Nutzung auch Toolversionen und Übergaben ab.