Co sprawia, że ​​Erlang nadaje się do aplikacji w chmurze?

9

Rozpoczynamy nowy projekt i wdrażamy przy tworzeniu przez nas korporacje chmurę typu openstack (patrz http://www.openstack.org/ ). Projekt jest narzędziem bezpieczeństwa dla naszej korporacji. Obecnie prowadzimy setki dedykowanych serwerów dla narzędzi bezpieczeństwa i przenosimy je do instancji openstack w naszych korporacjach.

Inne projekty w mojej firmie używają obecnie erlang w kilku aplikacjach serwera rozproszonego, a inne pytania / odpowiedzi wskazują, że erlang jest używany w kilku popularnych usługach w chmurze. Próbuję przekonać innych do rozważenia, gdzie może to mieć zastosowanie w naszym projekcie.

Jakie są mocne strony Erlanga w zakresie programowania w chmurze? Gdzie są obszary, w których szczególnie zaleca się stosowanie Erlang?

Duncan
źródło
15
Zdefiniuj „chmurę”, a my powiemy ci, co możesz chcieć wiedzieć. Termin „chmura” oznacza marketing i oznacza coś innego dla każdej osoby, która z niego korzysta.
Pomyślałem, że powiedzenie chmury typu „openstack” byłoby wystarczającą definicją tego, co wdrażamy. Zobacz openstack.org . A może potrzebujesz więcej informacji o projekcie? To narzędzie bezpieczeństwa dla naszej korporacji. Obecnie prowadzimy setki dedykowanych serwerów dla narzędzi bezpieczeństwa i przenosimy je do instancji openstack w naszych korporacjach.
Duncan,
Zredagowałem pytanie, aby, mam nadzieję, poprawić je i usunąć obawy związane z „marketingiem”. Moim problemem jest wybranie najlepszego narzędzia do pracy. Jestem debiutantem w Stackexchange, więc nie do końca rozumiem.
Duncan,
1
konkretnie termin „chmura” jest mglisty i nie znaczy nic konkretnego, jest to marketingowy przekaz, wciąż nie zdefiniowałeś, co faktycznie kwalifikuje coś jako aplikację w chmurze . Osobiście wiem, co wiem, co myślę, że to znaczy, jestem pewien, że to nie jest to, co myślisz , biorąc pod uwagę pytanie.
„termin„ chmura ”jest mglisty” - dobry! Oznacza to coś wirtualnego i należy określić, czy to „coś” jest oprogramowaniem, systemem operacyjnym, pojedynczą maszyną, wieloma maszynami i siecią, czy czymś innym.
GlenPeterson

Odpowiedzi:

8

Oprócz faktu, że Erlang został specjalnie opracowany do pracy w sytuacjach współbieżnych / równoległych / rozproszonych, dwie główne techniki, które wykorzystuje, aby to umożliwić, to:

Bez skutków ubocznych:

Oznacza to, że jeśli dasz funkcji kawałek danych, który chcesz wykonać, nie będzie to miało wpływu, z wyjątkiem bardzo ścisłych przypadków, na cokolwiek innego w systemie / uruchomionym procesie. Oznacza to, że jeśli wykonasz funkcję 300 razy jednocześnie, żadne z tych 300 wykonań funkcji nie wpłynie na żadne inne.

Technika implementacji zapewniająca brak skutków ubocznych nazywa się „niezmiennością”, co z grubsza oznacza, że ​​nie może być zmutowana (zmieniona). Oznacza to, że zaraz po utworzeniu zmiennej wartość tej zmiennej nie może być modyfikowana. Erlang implementuje to zachowanie za pomocą „pojedynczego przypisania”, więc po przypisaniu wartości do zmiennej nie można jej przypisać ponownie.

X = 1.
X = 2. // This is not a valid operation

Zapewnia to, że żaden kod nie może przypadkowo zmienić wartości X powodującej wyścig, dlatego jest z natury bezpieczny dla wątków, a jednoczesne użycie staje się banalne. Jest to bardzo rzadkie zachowanie wśród języków oprogramowania i największy sposób, w jaki Erlang jest tak dobrze przystosowany do równoczesnego wykonywania.

Model aktora:

Jest to szczególny sposób modelowania, który pokazał, że upraszcza implementację przetwarzania równoległego i zarządzanie nim. Prosto z wikipedii (http://en.wikipedia.org/wiki/Actor_model):

Model aktora przyjmuje filozofię, że wszystko jest aktorem. Jest to podobne do wszystkiego, co jest filozofią obiektową stosowaną w niektórych obiektowych językach programowania, ale różni się tym, że obiektowe oprogramowanie jest zazwyczaj wykonywane sekwencyjnie, podczas gdy model aktora jest z natury zbieżny. Aktor to jednostka obliczeniowa, która w odpowiedzi na otrzymaną wiadomość może jednocześnie: wysyłać skończoną liczbę wiadomości do innych aktorów; stworzyć skończoną liczbę nowych aktorów; wyznacz zachowanie, które zostanie zastosowane dla następnej otrzymanej wiadomości. Nie ma założonej sekwencji powyższych działań i można je przeprowadzić równolegle. Oddzielenie nadawcy od wysłanej komunikacji było zasadniczym postępem w modelu aktora umożliwiającym asynchroniczne struktury komunikacji i kontroli jako wzorce przekazywania wiadomości.

Jimmy Hoffa
źródło
O „Żadnych skutkach ubocznych” mówisz „Jest to bardzo rzadkie zachowanie wśród języków oprogramowania” - jestem nieco zaskoczony. Czy Java i C # nie mogą tego zrobić dzisiaj? Jakie znasz języki, które muszą wywoływać działania niepożądane podczas wywoływania funkcji?
NoChance
3
@EmmadKareem To nie jest kwestia tego, czy można napisać program bez skutków ubocznych; jak zauważyłeś, możesz to zrobić w Javie lub C #. Chodzi o to, czy domyślnie nie ma skutków ubocznych i czy jest to obsługiwane przez kompilator. W Javie nie można na przykład powiedzieć kompilatorowi, że „ta metoda nie ma skutków ubocznych”. To z kolei oznacza, że ​​kompilator nie może cię ostrzec, gdy łamiesz zasady!
Andres F.,
@EmmadKareem Nie mówię, że nie można napisać C # lub java bez efektów ubocznych (choć niezwykle rzadkich), raczej mówię, że bardzo niewiele języków programowania ma ścisłe zasady wbudowane w język, który oddziela funkcje z efektami ubocznymi od tych bez.
Jimmy Hoffa
Byłoby wspaniale, gdyby Java miała adnotację @NoSideEffects, aby umieścić metodę informującą kompilator o wymuszeniu żadnych skutków ubocznych dla tej metody. W moim własnym kodzie lubię myśleć, że metody często nie wywołują skutków ubocznych. Pewnie, niektóre metody muszą być mutatorami w języku takim jak Java, ale wiele nie. Zwłaszcza jeśli wolisz niezmienne obiekty w swoich projektach.
GlenPeterson
Jimmy Hoffa i @AndresF., Dziękuję za wyjaśnienia.
NoChance
9

Erlang jest szczególnie silny w obliczeniach równoległych / równoległych. W rzeczywistości został zaprojektowany pierwotnie w tym właśnie celu. Nie ma to nic wspólnego z chmurą, poza tym, że często wymagające aplikacji obliczenia są równoległe i wdrażane w instancjach „chmurowych”, aby ułatwić zwiększenie / zmniejszenie wydajności na żądanie.

Reszta to tylko marketing-talk.

papka
źródło
7
Erlang został zaprojektowany do obliczeń odpornych na uszkodzenia . Po prostu przetwarzanie rozproszone jest warunkiem wstępnym (jak możesz niezawodnie zwrócić wynik, jeśli ktoś przypadkowo rozleje kawę na twój pojedynczy komputer, potrzebujesz co najmniej dwóch maszyn), a przetwarzanie równoległe i równoległe to tylko szczególne przypadki przetwarzania rozproszonego, więc Erlang zdarza się też być w nich dobry. Ale nie po to został zaprojektowany.
Jörg W Mittag,
1
@ JörgWMittag Tak długo, jak dzielimy włosy ... tak, celem było osiągnięcie odporności na uszkodzenia. To osiąga to poprzez parallelization. Został zaprojektowany w celu zaimplementowania tego w przełączniku telefonii cyfrowej AX, który przenosił dwie izolowane, równoległe rury obliczeniowe, z których jedna działała jako gorący tryb gotowości.
pap.
1
Tak, przepraszam, powinienem był być bardziej jasny: przetwarzanie w chmurze jest z definicji rozproszone i często (nie zawsze, ale zwykle) wdrażane przez klastry niedrogich i, co ważniejsze, zawodnych maszyn, ale zaprojektowane w celu zapewnienia niezawodnej usługi. Właśnie dlatego Erlang jest tak dobrze dopasowany.
Jörg W Mittag,
3

Jednym z aspektów chmury, który różni się od tradycyjnych wdrożeń sprzętowych, jest łatwość, z którą można w razie potrzeby rozpędzać nowe instancje. Możliwość monitorowania innych węzłów i procesów w innych węzłach sprawia, że ​​relatywnie proste jest budowanie wysoce dynamicznych systemów, które mogą dodawać lub usuwać VMS i zarządzać nimi w razie potrzeby.

Jest to szczególnie ważne, jeśli budujesz swój system za pomocą frameworka OTP (Open Telecom PLatform) erlanga, który zapewnia zarówno strukturę, jak i mechanizmy (drzewa superwizorów) do wspierania budowania całkiem skomplikowanych rzeczy przy znacznie mniejszym nakładzie pracy, niż można sobie wyobrazić. Erlang radzi sobie ze wszystkimi trudnymi bitami, więc nie musisz.

Garry Hodgson
źródło