praca w integracji

0

Do tej pory sądziłem, że świat dzieli się na backend i frontend. Jednak coraz częściej, w ogłsozeniach rekrutacyjnych, dostrzegam wyróżniony osobny obszar pt. integracja.

Szukamy programistów z doświadczeniem w backend, frontend lub integracji.

Rozumiem, że integracja dotyczy głównie ESB, łączenia różnych soapowych webserwisów / restów / ftpów itd.? Czy kolejki też się w to wliczają?
Czym ta integracja jest i jaka może być jej przyszłość w dobie mikroserwisów?

3

TLDR
Nie wiem co poeta miał na myśli, ale dla mnie integracja oznacza że jest jakiś przedpototopowy SOAP i trzeba coś wyrzeźbić żeby się z nim zintegrować.

Rozwinięcie:
W czasach przed microserwisami, w czasach monolitów, integracja była czymś rzadkim, bo rzadko trzeba było integrować monolity. I w zespole mógł być tylko jeden programista który się na tym znał.
Dziś w czasach microserwisów wszystko się ze sobą integruje, nikogo to nie dziwi i wszyscy się na tym znają a przynajmniej tak myślą.

BTW
Jeśli szukają ludzi z wiedzą o kolejkach to powinni po ludzku napisać że chcą wiedzy o kolejkach i najlepiej konkretnie wypisać które kolejki (Kafka, Rabit czy Redis)

1

Ciężko powiedzieć na podstawie zdania wyrwane z kontekstu o co chodzi. Ale integracja to nie tylko ESB i web serwisy. Integracje robi się na pierdyuliard różnych sposobów: db to db, web serwisy (SOAP, REST i co se tam ktoś wymyśli), pliki, socety itp itd. Integracją to jest dość złażony temat np przez konieczność wyszukiwania zmian do zmigrowania, utrzymania spójności danych pomiędzy systemami itp itd.

0

Słowo, na które trzeba uważać. Obejmuje (wh marketingowców) od sprzedaży licencji i DVD na servery, po rzeczy naprawdę twórcze.

4

Ostatnio brałem udział w rekrutacji na Java Dev Jr. do zespołu integracji. Podczas rozmowy telefonicznej okazało się, że tak naprawdę chodzi o robotę w XML.

1

W moim świecie (nie wiem jak to się przenosi na normalne IT) integracja to łaczenie jakichś gotowych systemów ze soba, erpa z erpem, crm z crm. SOAPy i RESTy, najczęściej dla utrudnienia przez middleware, bo np. potwierdzenie zamówienia z zewnętrznego systemu X ma się rozprzestrzenić po kilku systemach u klienta, system 1 czeka na odpowiedź z systemu 2 itd itd. Podwójna robota głupiego, ale w wielkich firmach konieczna do trzymania tego bajzlu w jednym miejscu.

Do tego konfiguracja dostępów do zasobów baz (np. CRM czyta sobie bazę danych erpa, i musi być pozabezpieczane do czego ma dostęp a do czego nie) i na odwrót.

Całkiem fajna robota, jeśli ktoś lubi sobie pojeździć i pogadać na niekończacych sie warsztatach, poogarniac procesy w firmach, dużo słabsza jeśli lubi programować bo jedyna rzecz która trzeba wyklepać to formatowanie wartości pól, ewentualnie dłubanie w ustawieniach połaczeń. Więc kto co lubi.

2

Trzeba pytać bo nie wiadomo czy chodzi o stary legacy crap czy o integrację z innymi produktami chmurowymi.

W poprzedniej pracy robiliśmy integrację z chmurowym Salesforce'em i Stripe'em.
Problemy jakie tu występują to konieczność dogadywania wszystkiego z goścmi od tych programów (tutaj tylko Salesforce).
Gorsza kultura programistyczna po ich stronie (grzebanie ręczne w konfiguracji, problem żeby zrobić 2xśrodowiska testowe bo kosztuje choć 2x mieliśmy dla developerki, brak systemu kontroli wersji - np. X coś zmienił i poszedł na urlop ale nikomu nie powiedział, dziwne api np. wysyłanie sql'owych zapytań przez REST co by dane z Salesforce pobrać).
Praca nie najgorsza ale zupełnie nie rozwojowa. Dużo spotkań.

Integracja przez ESB, Oracle itp. - uciekaj, szybko, gdzie nogi poniosą. NIE CHESZ TEGO ROBIĆ! (ok ok ja niechę tego robić, za żadne pieniądze, po prostu nie, to taki COBOL 21 wieku).

2

Integracja dotyczy głównie części gdy przyjeżdża jaki top manago z US of A czy tam Lądku i trzeba się zintegrować. Nie wszyscy lubią tą część pracy, nie wszyscy mają predyspozycje a jest to bardzo ważna rzecz w ocenie zespołu i walce o podwyżki.

Dlatego też ludzie z doświadczeniem w integracji są bardzo ważnym assetem w zespole bo przynajmniej dają pewność że nie odwalą czegoś co będzie rzutować na relacje długo po odejściu takiej osoby z pracy.

0
loza_wykletych napisał(a):

Integracja dotyczy głównie części gdy przyjeżdża jaki top manago z US of A czy tam Lądku i trzeba się zintegrować. Nie wszyscy lubią tą część pracy, nie wszyscy mają predyspozycje a jest to bardzo ważna rzecz w ocenie zespołu i walce o podwyżki.

Dlatego też ludzie z doświadczeniem w integracji są bardzo ważnym assetem w zespole bo przynajmniej dają pewność że nie odwalą czegoś co będzie rzutować na relacje długo po odejściu takiej osoby z pracy.

To mi przypomina wypowiedź jaką usłyszałem w poprzedniej firmie X jest bardzo ważnym pracownikiem, ponieważ X był w Stanach i pił wódkę ze wszystkimi naszymi klientami

2

A jest już jakaś modna nazwa na to, np. DevGrator albo IntegrOps?
Zaraz znowu się okaże, że to, co robię od 5 lat to jakaś oddzielna specjalizacja. :/

0

Można powiedzieć że mam takie stanowisko.
ETL i BI Developer to chyba nieco inna para kaloszy bo chodzi o hurtownie/raporty i zestawienia danych potrzebne do analiz i podejmowania decyzji.
U mnie to wygląda tak że mamy ERP, API, Bazę danych, FTP lub Webservice SOAP/REST lub folder z plikami I trzeba dane przenosić np. Z 1 źródła w drugie. Lub np na podstawie plików zakładać dokumenty w systemie ERP/workflow.
Praca fajna bo ciągle są nowe integrację więc trzeba korzystać z dokumentacji innych dostawców o systemów i z czasem widać co się sprawdza a co już na etapie czytania dokumentacji jest źle przemyślane.
Głównie pisanie nowego kodu lub przez krótki czas utrzymywanie swojego.
Nie wiem jedynie jak to rynkowo wypada bo np nie mam prawie w ogóle doświadczenia w pisaniu, obsłudze GUI czy tam Fronta. Bo to co się pisze to DLLki, pluginy, serwisy

1

Inaczej to Backend powiększony o technologie ESB, WSO2, ETL, XML, JSON, Camel, każdą inną technologię potrzebną do pobrania danych jak sockety. Konsumowanie/przetwarzanie/wypluwanie usług SOAP, REST, IaaS, wszystkich innych usług czyli może być nowoczesny AWS, Api google/twitter jak i jakieś serwery telekomunikacyjne z lat 90 napisane w C++ z socketami. Mikroserwisy to raczej decyzja jak zaimplementować taki serwer integracyjny.
Świat dzieli się także na DevOps:)

1

Speech jakiegoś szkoleniowca/sprzedawcy IT lat 90/2000

Klient: "kupujemy i kupujemy tę integrację, i nic z tego nie mamy"
Marketingowiec:* "bo wy kupujecie integrację systemową, a wam potrzebna jest integracja aplikacyjna"*

Taki smaczek z tamtych lat, gdy sprzedanie pudeł z systemem Novell Netware lub Santa Cruz Operation SCO Unix, MS Serwer (też) nosiło nazwę integracji

1 użytkowników online, w tym zalogowanych: 0, gości: 1