Itanji Co., Ltd. (im Folgenden Itanji) bietet Dienstleistungen zur Erleichterung von Immobilienvermietungstransaktionen an. Diesmal steuerte Herr Akihiro Nagashima, Executive Officer von ITANDI, einen Artikel über den Zeitpunkt der Antragsteilung und die Vor- und Nachteile bei.
Anwendungsspaltungen, endlose Kontroversen
Auf dem umkämpften SaaS-Markt ist es besser, den ACV (durchschnittlicher jährlicher Vertragswert pro Unternehmen) zu verbessern und den LTV (Customer Lifetime Value) zu erhöhen, als zu versuchen, den Marktanteil eines Unternehmens in kurzer Zeit zu monopolisieren ist eine realistischere Managementstrategie.
Daher müssen viele SaaS-Unternehmen Upselling und Cross-Selling wiederholen, und die Anzahl der Anwendungen steigt unweigerlich.
Vor einiger Zeit hat der ehemalige CTO von GitHub Folgendes getwittert:
Quelle:Die Übersetzung wäre ungefähr so:
Ich glaube, dass einer der größten Architekturfehler des letzten Jahrzehnts darin bestand, bis hin zu Microservices zu gehen.
Im Spektrum von Monolithen bis hin zu Microservices würde ich vorschlagen:
Monolith > App > Dienst > Microservice
Betrachten wir nun einige.
Diesem Tweet-Thread folgte ein langer Kommentar, der viel Feedback hervorrief.
Insofern lässt sich sagen, dass das Thema Application Division beim Aufbau eines IT-Systems, also wie man das System aufteilt, für viele IT-Ingenieure von Interesse ist.
In diesem Dokument werden wir uns die Übergänge in der Anwendungsabteilung von Itanji, einem Immobilien-SaaS-Unternehmen, ansehen, zu welchem Zeitpunkt und in welchen Einheiten wir Anwendungen aufgeteilt haben und wie wir uns darüber freuen, dass wir das getan haben du was es ist.
Wir hoffen, dass diese Fallstudie als Referenz für die Teilung von Bewerbungen dient.
Definition von Wörtern
Zur Erleichterung der Diskussion finden Sie hier einige Begriffsdefinitionen.
Monolith: Ein Zustand, in dem mehrere Anwendungen (*eine Anwendung ist hier eine Einheit, die ein einzelnes Geschäftsproblem löst) von derselben Codebasis und Bereitstellungseinheit verwaltet werden.
Anwendungen: Ein Zustand, in dem die Codebasis und die Bereitstellungseinheiten für jede Anwendung verwaltet werden
Dienstleistungen: Ein Zustand, in dem die Codebasis und die Bereitstellungseinheiten nicht von der Anwendung verwaltet werden, sondern von der Funktion, aus der die Anwendung besteht (unter der Annahme, dass es einen EC-Dienst gibt, wird er in große Einheiten wie Produktsuche und -kauf unterteilt).
Mikrodienste: Ein Zustand, in dem die Dienste weiter unterteilt sind (im obigen EC-Beispiel ist der Kauf weiter unterteilt in das Hinzufügen zum Warenkorb, die Kreditanfrage, die Zahlung usw.)
Über Itanji Co., Ltd.
Itanji ist ein Unternehmen im 10. Jahr seiner Gründung, das SaaS usw. anbietet und sich auf den Immobilienbereich spezialisiert hat.
„ITANDI BB+“, eine SaaS-Dienstleistungsgruppe für Mietverwaltungsgesellschaften und Maklerunternehmen, die den Ablauf der Vermietung von Immobilien (Reservierung zur Besichtigung, Einzugsantrag, Abschluss des Mietvertrags) digitalisiert, und „ITANDI BB“, eine Echtzeit Website für Immobilienmakler usw.
„ITANDI BB“, eine Echtzeit-Website für Immobilienmakler, ist auf etwa 5,6 Millionen Seitenaufrufe pro Monat angewachsen, +70 %, Tendenz steigend.
„Application Reception-kun“, ein Dienst, der Mietanträge mit einer Anwendung von „ITANDI BB+“ digitalisiert, war das zweite Jahr in Folge der führende Dienst für die Anzahl der Anträge auf Wohnungsbezug und wird für etwa 630.000 Anträge pro Jahr verwendet (*2).) Das war es.
(*1) ARR: Jährlich wiederkehrende Einnahmen. Berechnet durch Multiplizieren der MRR zum Monatsende am Ende jedes Quartals mit 12. MRR umfasst monatliche Nutzungsgebühren, nutzungsabhängige Gebühren und Einnahmen aus Nebengeschäften. Vergleichen Sie ARR von ITANDI BB+ ab Oktober 2021 und Oktober 2022
(*2) Zielzeitraum: 1. April 2021 bis 31. März 2022. Forschungsauftragnehmer Nr. 1: TPC Marketing Research Co., Ltd. (Standort: Stadt Osaka, Präfektur Osaka, Präsident: Ryoma Matsumoto)
Service-Start, Monolith-Ära
Die Zahl der Bewerbungen für „ITANDI BB+“ ist mittlerweile auf rund 10 angewachsen. Die allererste Anwendung war ein automatischer Sprachdienst zur Eigentumsbestätigung „Bukkakun“. „Bukkakun“ ist ein Dienst, der die betriebliche Effizienz verbessert, indem er automatisch auf Immobilienbestätigungsanrufe zwischen Immobilienmaklern reagiert.
An diesem Punkt wird es natürlich zu einem Monolithen.
Als die Anzahl der „Bukkakun“-Installationen zunahm, war der nächste von uns veröffentlichte Dienst „Naimi Reservation Kun“, mit dem Sie Reservierungen für die Vorschau von Mietobjekten online abschließen können.
Sogar zum Zeitpunkt der Entwicklung von Naimi Reservation-kun war es noch ein Monolith.
Zu diesem Zeitpunkt wussten wir nicht, ob der Service erheblich wachsen würde, also entschieden wir uns, der Entwicklungsgeschwindigkeit Vorrang vor der Anzahl der Arbeitsstunden zu geben, die für die Partitionierung von Anwendungen aufgewendet wurden, wie z. B. Architekturdesign und Kosten für das Infrastrukturmanagement.
Drittes Service-Release, aufgeteilt in Apps
Danach, als sich die Einführung von „Naimi Reservation-kun“ ausweitete, entschieden wir uns, „Application Reception-kun“, ein Bewerbungssystem für Mietimmobilien, das derzeit der Hauptdienst ist, als dritten Dienst zu veröffentlichen.
Dies war das erste Mal, dass ich die Codebasis aufgeteilt habe. In Anlehnung an den Ausdruck des ehemaligen GitHub CTO wird es ein Übergang zu Monolith > Apps sein.
Hintergrund dieser Entscheidung ist, dass “Anwendung Rezeptionist-kun” wahrscheinlich komplexer als bisherige Dienste und die Codebasis groß sein wird und dass die Entwicklung eines mit “Anwendung Rezeptionist-kun” verknüpften Dienstbereichs geplant ist. ( B. „Elektronischer Vertrag-kun“, der Mietverträge digitalisiert).
Quelle:Bühne ist wichtig. Für Unternehmen mit 5-50 Mitarbeitern ist Monolith die einzige Wahl. Glauben Sie bitte.
Wie oben erwähnt, scheint der ehemalige CTO von GitHub die Phase um die Anzahl der Entwicklungsmitglieder zu kürzen.
Wie ich eingangs erwähnt habe, müssen SaaS-Unternehmen wiederholt Upselling und Cross-Selling betreiben, um den LTV zu maximieren.
Daher denke ich, dass es bei SaaS besser ist, mit einem Monolithen zu gehen, bis wir den sogenannten PMF (Zustand, in dem der Service vom Markt akzeptiert wird) erreichen. Und wenn PMF in Sicht kommt, werden wir eine Migration zu Apps in Betracht ziehen. Für uns war diese „Bewerbungsannahme“ genau das richtige Timing.
Auch die Login-Funktion und die Kernfunktion werden gleichzeitig als Service realisiert.
Auf diese Weise haben wir zum Zeitpunkt von PMF eine Richtlinienänderung an Monolith > Apps vorgenommen, und ich möchte die guten Dinge vorstellen, die gleichzeitig passiert sind.
Es ist die Login-Funktion und die Service-Konvertierung der Kernfunktion.
Ich denke, dass die meisten IT-Dienste heute eine Login-Funktion haben. Diese Anwendung heißt itandi-accounts und bietet jetzt Anmeldefunktionen für alle unsere Dienste.
Die andere ist die Kernfunktion, die wir Immobiliendatenbankdienst nennen.
In SaaS sollte es etwas geben, das Kerndaten entspricht, die von jeder Anwendung verarbeitet werden. Bei uns wären das Sachdaten, und wenn es zum Beispiel ein Service für Apotheker wäre, wären es Arzneimitteldaten.
Mit der Umstellung auf Apps wurden nur die beiden oben genannten in Dienste umgewandelt, sodass sich die danach zunehmenden Anwendungen auf ihre Aufgaben konzentrieren konnten.
Vorteile und Herausforderungen der Umstellung auf Apps
Abschließend fassen wir die Vorteile und Herausforderungen der Umstellung auf Apps zusammen, die wir fühlen.
Der Vorteil ist, dass der Wirkungsbereich leicht zu verstehen ist, da eine Anwendung klein ist.
Teams können klein gehalten werden, was es einfacher macht, Entscheidungen pro Anwendung zu treffen. Dies wird ein großer Vorteil für Start-up-Unternehmen sein, die Produkte mit einem Gefühl der Geschwindigkeit entwickeln müssen.
Umgekehrt möchte ich als erstes auf die große Schwierigkeit hinweisen, die Regionen für die Aufteilung festzulegen.
Es ist uns gelungen, Apps zu erstellen, aber wenn wir die Anwendung in die falschen Einheiten aufteilen, landen wir in einer Situation, in der „die Anwendungen getrennt sind, aber in Wirklichkeit eng voneinander abhängig sind.“ Es ist möglich, dass der ursprüngliche Zweck der Realisierung der Entwicklung von
Darüber hinaus ist es mit zunehmender Anzahl von Anwendungen erforderlich, eine separate Infrastrukturumgebung aufzubauen, was die Verwaltungskosten erhöht.
Die Kosten des Servers steigen einfach, aber die Arbeit, die Bibliotheken und Frameworks auf dem neuesten Stand zu halten, muss auch für jede Anwendung erledigt werden, was die Verwaltung kompliziert macht.
Zukunftsaussichten
Derzeit betreibt Itanji fast 10 Dienste als Apps. Aber ich glaube nicht, dass das der beste Weg ist.
Um das oben erwähnte Problem der Verwaltungskosten zu verbessern, werden wir in Zukunft den Wechsel zu einem modularen Monolithen in Betracht ziehen, und mit zunehmender Anzahl von Anwendungen werden Kernfunktionen auftreten, die bisher nicht sichtbar waren, und es wird notwendig sein, neue zu entwickeln gemeinsame Dienstleistungen Das Unbekannte der Suche geht weiter, wie zum Beispiel das Coming Out.
Wir hoffen, dass unsere Fallstudie als Referenz dient, wenn SaaS-Unternehmen Anwendungspartitionierung in Erwägung ziehen.
Akihiro Nagashima
Itanji Co., Ltd.
BetriebsoffizierAbgeschlossene Graduate School of Systems and Information Engineering, University of Tsukuba. Kam als frischgebackener Absolvent zu Nifty und war verantwortlich für die Entwicklung von SNS-Marketing-Tools. Danach kam er während der Gründungszeit zu Itanji und startete verschiedene neue Unternehmen. Am Ende des Geschäfts wechselte er zu Mercari und war an der Erneuerung der US-Version des Hilfezentrums, der Entwicklung von Kundensupport-Tools und der Einführung von Mercari NOW beteiligt. 2018 wurde er zum Executive Officer von Itanji ernannt.
