Wczoraj miała miejsce, zapowiadana na blogu, konferencja na temat Cloud Computing (CC). Nie będę tu powtarzał całego referatu, więc zyskali Ci którzy byli na konferencji :). Tu napisze kilka słów o CC w kontekście tego co było głównym przesłaniem mojego referatu:
Cloud Computing to praktyka realizacji komponentowej architektury systemu a nie kolejna odsłona dzierżawy oprogramowania
O CC często mówi się jako o cudzych aplikacjach dostępnych w sieci. Mówi się o Saleforce, Zoho i innych podobnych, ale to są systemy dostępne zdalnie i licencjonowane (nie ma tu znaczenia to, czy licencje są płatne czy nie). To jest stare i znane [[ASP]] czy [[SaaS]].
Od lat mówi się o SOA, jako o metodzie budowy i integracji systemów (tu już mamy integrację a nie tylko zdalne użycie). Jednak pojawia się tu potrzeba tworzenia pośredniczącego, kosztownego, elementu architektury ([[ESB]]) co skutecznie ograniczyło zastosowanie tej metody (a raczej technologii) integracji systemów.
CC to zupełnie inne podejście. To komponentowa architektura znana od lat. Dlaczego nie używana od lat? Otóż na przeszkodzie stały: brak doświadczeń w budowie systemów obiektowych, brak wydajnych i bezpiecznych protokołów sieciowych (teraz mamy np. webserwisy) oraz brak standaryzacji danych (a raczej referencyjnych struktur informacji). Tak więc CC to sposób dodawania nowych komponentów do posiadanego systemu.
Prawnik, jeden z prelegentów na tej konferencji, słusznie zauważył: CC to sytuacja gdy umowa określa, że płacimy za przetwarzanie danych a nie za korzystanie z oprogramowania.
Skoro CC to jednak architektura, proponuję taką kolejność działań w projektach tego typu:
- analiza biznesowa (cel projektu),
- analiza wymagań,
- projekt architektury systemu,
- decyzja, które komponenty systemu możliwe są do kupienia, a które należy potraktować jako zasób zewnętrzny (cudzy).
Osobiście nie polecam podejścia polegającego na znalezieniu “fajnego” komponentu i zastanawianiu się gdzie go u siebie upchać. To często spotykany przypadek, w którym “coś nam sprzedano”. Polecam rzetelne, pragmatyczne spojrzenie biznesowe, kończące się tym, że znajdziemy i kupimy od kogoś coś, co jest nam potrzebne i przyniesie korzyści, także finansowe.
Gdyby tylko zmienić nazwę tej koncepcji zgodziłbym się w całej rozciągłości. Cloud Computing to oryginalnie nie wzorzec architektury, ani żadna jego implementacja – to prosty model biznesowy polegający na rozliczaniu się z klientami za iloczyn dostarczonej mocy obliczeniowej i czasu jej wykorzystania z tym zastrzeżeniem, że ta moc obliczeniowa może być dostarczana przez bardzo różne maszyny (stąd cloud).
Historia sięga pierwszych komputerów typu mainframe i oferty IBM-a z 2 połowy lat 60-tych.
Natomiast zgadzam się, że dzisiaj CC to określenie dotyczące architektury oprogramowania – wcale nie trzeba kupować oprogramowania jako usługi aby z tej całej “chmurowości” korzystać. Trend może okazać się bardzo korzystny, bo pierwszy raz prowadzi do pewnej standaryzacji tożsamości, którą próbował kiedyś wprowadzić Microsoft ze swoim paszportem. Dziś coraz więcej systemów pozwala na uwierzytelnianie poprzez OpenID, Google Account, czy FB Account – i to jest dobrze.
Czekam na większą standaryzację API i zejście z nim niżej w architekturze systemu – tak aby integracja między aplikacjami dostępnymi w chmurze nie polegała na umiejętności importu czy synchronizacji danych, ale abym mógł używać jej obiektów jak swoich.
… i tylko ta standaryzacja…
Przy okazji: ciekawy artykuł o CC, polecam: Odpowiedzialność za zarządzanie ryzykiem w chmurze