APLIKACJE ROZPROSZONE
czyli
MICROSERVICES
Microservices, czyli aplikacje rozproszone, to podejście w budowaniu aplikacji, które było odpowiedzią na szereg problemów jakie wynikały z budowania aplikacji monolitycznych.
Zobacz również:
Analogia
Postaram posłużyć się analogią taśmowej produkcji aut. Pierwsze samochody budowane były przez specjalistów od A do Z. Mówię tu oczywiście o czystej produkcji, czyli składaniu pojazdu część po części, klocek po klocku, etap po etapie.
Nie było to ani do końca produktywne, ani efektywne. Stanowisko, na którym powstawało auto wymagało ciągłego zaangażowania ekspertów na każdym etapie produkcji. O samych specjalistów również nie było łatwo, by móc pracę zrównoleglić i podnieść skalę wytwarzania maszyn.
Henry Ford
Oto Henry Ford wpada na pomysł produkcji taśmowej. Tu każdy etap powstawania samochodu ograniczał się do kilku nieskomplikowanych operacji na każdym ze stanowisk.
Oznacza to, że każde ze wspomnianych stanowisk wymagało zaangażowania pracownika, który nie musiał być inżynierem z obszerną wiedzą budowania pojazdów, a szczególnie danego modelu. Pracownik osadzony na tym stanowisku potrzebował względnie krótkiego treningu i mógł nim zostać każdy.
Aplikacje rozproszone
Jak to się ma do aplikacji rozproszonych? A no tak, że zamiast wielkich i złożonych organizmów, dokonujących szereg operacji, aplikacja składa się z wielu małych organizmów, które z sobą współpracują. Tak jak pracownicy przy taśmowym składaniu aut, aplikacje rozproszone ograniczają zakres swojej pracy do drobnych czynności, za które odpowiadają.
Nie trzeba być ekspertem od danej aplikacji
Nie trzeba zatem super ekspertów od aplikacji, którzy potrafią się odnaleźć w milionach linii kodu, żeby móc coś naprawić, albo też dodać nową funkcjonalność – takich też ciężko byłoby zarówno znaleźć, jak i wdrożyć. W tym modelu wystarczy, żeby każdy pracownik znał się na kodowaniu, a poznanie logiki danego komponentu będzie już względnie proste.
Zobacz również:
Microservice a API
Aplikacje rozproszone potrzebują się z sobą komunikować i robią to na różne sposoby. W konsekwencji można zetknąć się z wystawianiem tzw. API dla poszczególnych microserwisów, by te mogły się z sobą łączyć w odpowiedni sposób i budować docelowe rozwiązanie. Kolejną zaletą tego podejścia jest to, że jako API (czy też web serwis), każdy z nich może być samodzielnym produktem, gotowym do sprzedaży.
Chcesz wejść do IT?
Jeśli jesteś zainteresowany pracą w IT, zachęcam do eksplorowania bloga. Dużo bardziej szczegółowo omawiam software development w książce Almanach Informatyczny – Lite.
Jej założeniem jest wprowadzenie każdego do świata IT w 100 słowach i turbo kompaktowych definicjach. Wszystko, czego potrzebujesz, żeby świadomie wybrać rolę dla siebie i czuć się komfortowo, kiedy już zaczniesz.
Powiązane wpisy:
- Czym zajmuje się Scrum Master
- Czym zajmuje się Product Owner
- Cechy dobrego Product Ownera
- 8 cech dobrego Scrum Mastera
- Co to jest Scrum w IT?
- Co to jest Agile w IT?
- Co to jest Product Backlog w IT?
Zobacz także:
- Jak znaleźć pracę w korporacji
- Praca w IT bez doświadczenia
- Praca w IT bez programowania
- Czy angielski jest konieczny w IT
- Humanista w informatyce
- (Nie)techniczna skala wejścia do IT
- Jak się pracuje w IT – czy to wszystko mit?
- Estymowanie w Scrumie
- Jak pisać User Story
- Jak dobrze napisać historyjkę użytkownika, a jak robić to źle?
- Humanista pośród informatyków
- Czym zajmuje się Scrum Master?
- Informatyk w informatyce.
- Umysł ścisły w informatyce
- Geograficzna eksploracja IT
Dodaj komentarz