Tag: MultiCloud

Opublikowane w

Modernizacja systemów

Zaplanowania modernizacja systemów informatycznych często jest rezultatem nowej strategii biznesowej, dużych kosztów utrzymania i rozwoju systemów, niskiego poziomu bezpieczeństwa, wydajności czyli często określenia długu technologicznego. Określenie wielkości długu technologicznego i ryzyka z nim związane są często elementem zarządzania ryzykiem w firmie (Risk Management) oraz są uwzględnione w planie zachowania ciągłości biznesowej (Business Continuity Plan -BCP). Systemy zastane Legacy są obecnie jednym z poważniejszych wyzwań dla działów IT utrudniających rozwojów biznesowy.

Nowe strategie cyfrowe czy transformacje cyfrowe (Digital Transformation) wymagają od IT wysokoskalowalnych systemów, natychmiastowych zmian biznesowych, łatwych integracji oraz bezpieczeństwa danych. Dodatkowo presja na systemy IT jest ciągle w obszarze kosztów utrzymania tych systemów i ich rozwoju. Każda Strategia IT powinna obejmować elementy architektury systemów, ich rozwoju, a w przypadku długu technologicznego corowych systemów ich modernizację lub wymianę.

Modernizacja systemu jest często planowana na podstawie wykonanego audytu jakości kodu źródłowego, wydajności, architektury czy bezpieczeństwa.

Strategie IT realizowane przez Dyrektorów IT (CIO) odnosnie systemów Legacy

Strategie odnośnie systemów Legacy są związane m.in. z ważnością systemu, ilością wprowadzanych zmian, wystawieniem na ryzyko np. wycieku danych, ryzykiem wydajności systemu, itd. Strategie Legacy:

  • Strategia nie rób nic z systemem – utrzymanie
  • Eliminacja kluczowych problemów np. wydajnościowych czy bezpieczeństwa
  • Strategia modernizacji – refaktoring
  • Strategia wymiany systemu

Częste kierunki modernizacji systemów Legacy

Zapraszamy do kontaktu:

pfederowicz@gotechnologies.pl

Ponad 200 zadowolonych klientów
Opublikowane w

Architektura Cloud Native

Cloud Native to technologia wykorzystania chmury przy tworzeniu własnych aplikacji. Technologia korzystające z mikroserwisów, kontenerów czy usług bezserwerowych tzw. Serverless.

Planując architekturę Cloud Native należy zacząć m.in od pytania o stopień „przenaszalności” aplikacji pomiędzy dostawcami chmury (Vendor-lock). Kolejne pytania dotyczą apliakacji, które będziemy tworzyli lub przenosili. Dostawca chmury powinien być dopasowany do tych aplikacji, aby wykorzystać najlepiej ich możliwości.

W przypadku chęci uniezależnienia się od dostawcy chmury często stosuje się popularne kontenery np. na Kubernetes czy Amazon Elastic Container Service (Docker). Kontenery pozwalają na łatwą przenaszalność aplikacji pomiędzy środowiskami, budowanie mikroserwisów czy niemal nieograniczoną skalowalność.

Innym typem budowania aplikacji dla technologii Cloud Native jest wykorzystanie funkcjonalności chmur typu Serverless. Usługi tego typu są dostarczane przez wszystkich dostawców chmur jak AWS, Google GCP czy Microsoft Azure.

Aplikacje Cloud Native (Native Cloud Application – NCA) są tworzone zgodnie z zasadą rozdzielania zadań na usługi (mikroserwisy, mikrousługi) i zgodnie z zasadą oddzielania ich od infrastruktury np. z wykorzystaniem kontenerów czy funkcji serverless.

Jeśli potrzebujesz wsparcia w architekturze systemów czy audycie swoich aplikacji zapraszamy do kontaktu.

Zobacz także: doradztwo strategiczne IT

Zapraszamy do kontaktu:

pfederowicz@gotechnologies.pl

Ponad 200 zadowolonych klientów
Opublikowane w

Architektura systemów pod Big Data

Duże ilości danych wymagają zaplanowania architektury pod kątem ich zbierania, przechowywania, ich analizy czy udostępniania do innych systemów. W tradycyjnym modelu dane są zbierane przez hurtownie danych z systemów np. ERP, CRM, eCommerce, WMS, itd. a analizowane w systemach klasy Business Inteligence.

Poniżej przykładowy flow od źródeł danych, poprzez ich zbieranie, transformację, przechowywanie i analizę.

Źródła danych dla Big Data

  • Aplikacje mobilne
  • Aplikacje dedykowane
  • Systemy ERP, WMS, CRM, POS, MES, MRP, APS, TMS, itd.
  • Systemy eCommerce jak sklepy internetowe, marketplace
  • Bazy OLTP
  • Bazy logów, eventów
  • API innych firm
  • itd.

Zbieranie i transformacja danych

  • Konektory
  • Zbieranie danych
  • Workflow Manager
  • Platforma Spark
  • Python Libs
  • Batch Query Engine
  • Event Streaming

Przechowywanie danych

  • Data lake
  • Data warehouse

Analiza danych, predictive, sztuczna inteligencja (AI – Artificial Intelligence), uczenie maszynowe (Machine Learning)

  • Data Science Platform
  • Biblioteki Machine Learning
  • Analityka czasu rzeczywistego

Rezultaty analizy danych

  • Dashboardy
  • Wbudowana analityka
  • Rozszerzona analityka
  • Aplikacje wbudowane, frameworki app

Powyższy schemat architektury pozwala na zbieranie danych biznesowych, wyciąganie danych z systemów operacyjnych, dostarczanie danych do magazynów danych wg. określonych schematów, transformację danych dla narzędzi analitycznych, przechowywanie danych aby mogły być one używane do analizy z uwzględnieniem kosztów przechowywania, czasów dostępów czy czasów dostarczenia danych, analizę danych poprzez systemy lub platformy do analizy, analizy historyczne i próby przewidywania przyszłości (predictive) aż do prezentacji wyników analizy danych dla wewnętrznych lub zewnętrznych użytkowników np. w systemach czy aplikacjach.

Jakie są najnowsze trendy w architekturze Big Data?

  1. Zmiana systemów On Prem na Cloud Data Warehouse
  2. Zmiana Hadoop na Data Lakes
  3. Zmiany ETP (Extract Transform Load) na ELT (Extract Load Transform)
  4. Zmiana Workflow Manager na Dataflow Automation

Zobacz także:

Zapraszamy do kontaktu:

pfederowicz@gotechnologies.pl

Ponad 200 zadowolonych klientów

Opublikowane w

Architektura Serverless (bezserwerowa)

Architektura bezserwerowa (Serverless Architecture) pozwala programistom na koncentrowaniu się na kodzie anie na serwerach. W tej architekturze płacimy za dostępność całej infrastruktury na żądanie np. wraz ze zwiększeniem obciążenia czyli tylko wtedy kiedy my czy nasi klienci używają zasobów serwerowych. W modelu serverless nie martwimy się zarówno utrzymaniem infrastruktury, jej updatami, licencjami, skalowaniem, wydajnością, konfiguracjami, backupami czy zespołem administratorów.

Architektura bezserwerowa pozwala na wykonywanie kodu w tradycyjnej architekturze monolitycznej jak i w architekturze rozproszonej (mikroserwisy).

Architektura bezserwerowa jest jedną z odmian platform chmurowych PaaS (Platform as a Service), IaaS (Infrastructure as a Service) i często określana także jako FaaS (Function as a Service).

Popularnymi na rynku usługami Serverless / FaaS są np. AWS Lambda, Azure Functions i Google Cloud Functions.

Zobacz naszą ofertę na doradztwo w obszarze IT:

Zapraszamy do kontaktu:

pfederowicz@gotechnologies.pl

Ponad 200 zadowolonych klientów
Opublikowane w

Strategia MultiCloud

Strategia Multicloud jest często wdrażana z powodów dywersyfikacji i uniknięcia uzależnienie do jednego dostawcy (tzw. Vendor Lock). Uzależnienie do może być w obszarze jakości usług, cen czy zakłócenia ciągłości biznesowej (Business Continuity) – awarie, odtwarzanie po awarii (DR – Disaster Recovery), wysoka wydajność (HA – High Availability), itd. Strategia z uwagi na różne zakresy usług dostawców chmur musi uwzględniać wszystkie ich aspekty jak: koszty za storage czy moc obliczeniową, różnorakie platformy czy aplikacje, moduły bezpieczeństwa, itd. Usługi te muszą być wpisane zarówno w politykę bezpieczeństwa jak i architekturę tele-informatyczną firmy.

Oprócz dywersyfikacji, vendor-lockingu częstym powodem dla międzynarodowych firm jest zwiększenie ciągłości biznesowej zarówno w dostępie (np. wydajność) do infrastruktury z dowolnej części świata, jak i jej odporność na awarie i ataki.

Strategia chmurowa jest jednym z elementów Strategii IT wspierającej cele biznesowe. Jest ona zasadna w przypadku rozproszonych globalnie systemów, klientów, pracowników, wysokich parametrów SLA dla usług i systemów oraz dużej dojrzałości organizacji.

Zobacz naszą ofertę doradztwa strategicznego IT

Zapraszamy do kontaktu:

pfederowicz@gotechnologies.pl

Ponad 200 zadowolonych klientów
Opublikowane w

Vendor Lock – Uzależnienie od dostawcy

Uzależnienie od dostawcy występuje nie tylko w branży tele-informatycznej. Wszystkie firmy tworzą tak produkty, aby klient nie mógł w łatwy, bezproblemowy lub tani sposób zmienić dostawcę usług lub produkt. Polityka dostawców od lat jest taka sama, często świadomie dostawcy utrudniają migrację do systemów innych dostawców. Świadoma polityka dostawców powoduje, że każdy system jest niekompatybilny z innymi co powoduje duże koszty migracji danych, przestoje w biznesie związane ze zmianą dostawcy i inne ryzyka technologiczno-biznesowe. Projekty zmiany dostawców systemów kluczowych są bardzo zasobo-chłonne i kosztowne, jednakże występują coraz częściej.

GoTechnologies wspiera organizacje w Doradztwie Vendor Lock, jak zmienić dostawcę, jak się przygotować do tego procesu, jak wybrać dostawcę.

Oferta doradztwa IT:

Zapraszamy do kontaktu:

pfederowicz@gotechnologies.pl

Ponad 200 zadowolonych klientów