Za kulisami wykonuje się wiele pracy, aby nasz LMS był dostępny online. Złożenie wszystkiego razem wymaga wiele pracy programistycznej.
Wiele rzeczy zmieniło się od czasu, gdy firma zaczęła budować Easy LMS. Chcesz dowiedzieć się więcej? Nasza Marketing Owl Priscila przeprowadziła wywiad z jednym z naszych programistów, aby dowiedzieć się, jak budujemy Easy LMS przy użyciu architektury mikrousług, co to oznacza i jak wpływa to na pracę, którą wykonujemy jako zespół i użytkownicy końcowi.
Priscila:Dzięki za dołączenie do mnie w tym wywiadzie, Thomas! Pierwszą rzeczą, którą chciałabym wiedzieć (i wierzę, że większość czytelników) jest to, czym jest architektura mikroserwisów. Czy mógłbyś to wyjaśnić?
Thomas: Nie ma problemu. Architektura mikrousług to sposób budowania kodu w wielu częściach lub repozytoriach. Można powiedzieć, że dzielimy sposób budowania kodu na wiele instancji zamiast budować jeden duży blok kodu.
Priscila:Interesujące. Oznacza to, że zespół programistów tworzy fragmenty niezależnego kodu, które pasują do reszty oprogramowania, prawda? Ale nie zawsze tak było w Easy LMS. Dlaczego zespół programistów dostrzegł potrzebę zmiany sposobu tworzenia kodu? Co do tego doprowadziło? Czy był to nowy trend, czy coś innego?
Thomas: Tak, to trend, ale to nie był główny powód. Zawsze wiedzieliśmy o architekturze mikrousług. Ale na początku zbudowaliśmy Easy LMS jako duże kawałki kodu, czyli tak zwany monolit. Kiedy zaczęliśmy się rozwijać jako firma, mieliśmy znacznie większy ruch na stronie internetowej, co spowodowało wiele problemów, takich jak niereagujące strony i błędy. Zdaliśmy sobie sprawę, że musimy zmienić sposób, w jaki budujemy kod, aby strona mogła się automatycznie dostosowywać i skalować.
To tak, jakbyśmy mieli "dużą fabrykę", która łatwo zostaje przytłoczona dużą ilością pracy. Zdaliśmy sobie sprawę, że musimy zbudować kilka "mniejszych fabryk", które zajmą się innymi częściami pracy.
Odkryliśmy, że niektóre części kodu nie były praktyczne i mogliśmy je ulepszyć. Wtedy pomyśleliśmy, że łatwiej będzie wprowadzić te ulepszenia w mniejszych fragmentach, zamiast brać je na siebie jako gigantyczny projekt. To tak, jakby mieć "wielką fabrykę", która łatwo zostaje przytłoczona dużą ilością pracy. Zdaliśmy sobie sprawę, że musimy zbudować kilka "mniejszych fabryk", które zajmą się innymi częściami pracy.
Priscila:Czy możesz podać przykład czegoś, co zbudowaliśmy w architekturze mikroserwisowej? .
Thomas: Ostatnim przykładem mikrousługi, którą wdrożyliśmy, jest nowa funkcja eksportu dla eksportu sesji egzaminacyjnej i eksportu danych uczestników. Zrobiliśmy to w ostatnich dwóch cyklach. Stare funkcje eksportu działały w naszej starej "dużej fabryce" razem z wieloma rzeczami i nie były zoptymalizowane.
Moglibyśmy stworzyć "maleńką fabrykę", która specjalizowałaby się w tworzeniu tych nowych produktów eksportowych. W przypadku eksportu napotkaliśmy wiele problemów. Na przykład, gdy klienci mieli zbyt dużo danych do wyeksportowania, ich żądania przeciążały główny system. Teraz, gdy mamy oddzielną usługę dla eksportów, mogą one działać płynnie. W rzeczywistości stworzyliśmy kod dla eksportów i inny, aby informować administratorów, że ich eksporty są gotowe. Są to samodzielne jednostki, a nie duże fragmenty.
Priscila: Cool! Czy są jakieś inne części Easy LMS, które zbudowaliśmy w architekturze mikrousług?
Thomas: Tak, są. Jednym z najbardziej interesujących jest nowy wygląd Akademii. Zbudowaliśmy nową Akademię przy użyciu Reacta, który jest frameworkiem do budowania interfejsów. Zbudowaliśmy ją na podstawie starej architektury (monolitu), wzięliśmy fragmenty z tego kawałka i stworzyliśmy samodzielną część. Zbudowaliśmy również API (interfejs programowania aplikacji) do pobierania danych do wyświetlenia w interfejsie. Mamy teraz dwie samodzielne części: pobierającą dane i wyświetlającą te dane. Są one mniejsze i łatwiejsze w utrzymaniu.
Priscila:Ok, w oparciu o to, co mi powiedziałeś, wciąż mamy trochę starego kodu. Czy to problem, że mamy teraz dwa rodzaje kodu w systemie ?? Czy są plany aktualizacji? .
Thomas: Nie, to nie jest problem. To proces. Zbudowaliśmy pierwsze części systemu używając metody "dużych kawałków kodu". W planach jest ich zastąpienie. Ale klienci nie zauważą różnicy. Budujemy nowy kod w taki sposób, aby mógł płynnie współpracować ze starym.
Priscila:Zrozumiałem. Więc jako deweloper, co wolisz? Czy tworzenie kodu w architekturze mikrousług jest łatwiejsze czy bardziej skomplikowane w porównaniu do poprzedniego procesu?
Thomas: Tak, znacznie łatwiej jest myśleć małymi fragmentami i utrzymywać nowy kod. Rozważamy aktualizację interfejsu uczestnika w przyszłości, aby działał lepiej w połączeniu z Akademią i samym sobą. Jeśli zbudujemy go w architekturze mikroserwisów, znacznie łatwiej będzie dodawać funkcje, ponieważ będziemy mogli pracować nad każdą częścią z osobna.
Priscila:W jaki sposób praca z mikrousługami zmieniła Twój sposób pracy?
Thomas: Możemy rozwijać się szybciej i lepiej. Mikroserwisy pomagają nam w utrzymaniu strony internetowej i umożliwiają nam szybsze wydawanie rzeczy.
Możemy również zdecydować o najlepszym sposobie wykonania zadania, ponieważ każdy fragment kodu jest samodzielną jednostką. Oznacza to, że możemy określić, jakiego języka programowania chcemy użyć i jaki rodzaj usługi chcemy uruchomić.
Kiedy używaliśmy starego systemu, jeśli chcieliśmy zaktualizować kompilację przy użyciu określonego języka, musieliśmy kontynuować tworzenie kodu w tym języku. Teraz możemy wybierać między różnymi językami w oparciu o to, co uważamy za najlepsze dla danej funkcji. Pracujemy w zespołach. Jeśli rozpoczynamy nową mikrousługę, badamy nasze opcje, a następnie decydujemy, co będzie dla nas najlepsze. Daje nam to więcej możliwości.
Priscila: Czy ma to wpływ na dotykanie niechcianych części systemu, na przykład, gdy próbujesz rozwiązać problem i ostatecznie tworzysz inny (taki jak błąd)?
Thomas: Tak, nawet rok temu, kiedy próbowaliśmy rozwiązać rzeczy, które wymagały dużej ilości kodu, kończyliśmy pracując nad zbyt wieloma niepotrzebnymi rzeczami. Na przykład, jeśli zamierzaliśmy rozwiązać X, rozwiązywaliśmy Y, a następnie tworzyliśmy błąd Z. Praca z mikrousługami zmniejszyła ten problem.
Priscila:Ok. Widzę, że architektura mikrousług ułatwia pracę zespołowi programistów. Ale jak to wpływa na naszych klientów i ich uczestników?
Thomas: Cóż, jak już powiedziałem, klienci nie zauważają (i nie powinni zauważać) różnych części kodu. Wszystko powinno działać razem, aby stworzyć płynne doświadczenie. Klienci mogą na tym skorzystać, ponieważ teraz możemy szybciej wydawać nowe funkcje i ulepszać je w oparciu o ich opinie.
Jest to drastyczna zmiana w stosunku do sposobu, w jaki robiliśmy to wcześniej. Na przykład, kiedy wydaliśmy nowy pulpit administratora Exam, zajęło nam to około sześciu miesięcy rozwoju, zanim wydaliśmy całość naraz. Jeśli klienci go pokochali lub znienawidzili, nie było już odwrotu (na szczęście pokochali go?). Teraz zmieniliśmy sposób, w jaki tworzymy i udostępniamy nowe funkcje.
Na przykład nowy kreator kursów został po raz pierwszy udostępniony w wersji beta. Zbudowaliśmy go przy użyciu Reacta i wypuszczaliśmy stopniowo, dodając drobne nowe funkcje, aż do momentu, gdy miał wszystkie funkcje, aby w całości zastąpić stary kreator kursów. W międzyczasie mogliśmy zobaczyć, co działa, jak klienci z niego korzystają, ulepszyć go, iterować, a następnie wprowadzić zmiany. Nie byłoby to możliwe w przypadku dużych fragmentów kodu wydanych na raz.
Priscila: To ma dużo sensu. Z tego co pamiętam, jest to zgodne z zasadami Toyota Improvement Kata, które stosujemy w firmie. Lepiej jest stworzyć prototyp, uzyskać informacje zwrotne i ulepszyć funkcję, zamiast spędzać dużo czasu, nie wiedząc, jak odbiorą ją klienci. Dziękuję za dołączenie do mnie w tym wywiadzie!
Thomas: Tak, myślę, że to działa lepiej. Mam nadzieję, że mogłem rzucić trochę światła na to, jak pracuje nasz zespół programistów w Easy LMS! Nie ma za co.
