Rozpocząć należy od dekompozycji aplikacji na podstawowe elementy funkcjonalne, takie jak dane, usługi, procesy, interfejsy użytkownika itp. Po gruntownym rozpoznaniu tych elementów można ponownie utworzyć architekturę aplikacji, która najlepiej spełni wymagania projektowanych usług w chmurach. Wtedy pozostaje odwzorować tę nową architekturę logiczną w architekturę fizyczną i określić zadania wymagane do jej utworzenia. Aplikacje w chmurze są tworzone z wykorzystaniem API - dla pamięci, przetwarzania, dostępu do danych itp. - które są w praktyce implementowane jako zbiór API i usług, zamknięty w aplikacyjnym kontenerze. Powodzenie projektu przejścia w chmurę zależy często od zapewnienia zdolności zarządzania API lub usługami. Wiele organizacji wdrażających projekt cloud po raz pierwszy nie ma doświadczenia w obchodzeniu się z architekturą opartą na usługach i nie widzi potrzeby zarządzania API aż do momentu wdrożenia. Niestety, wtedy jest już za późno. Zdolność zarządzania chmurowymi API staje się jednym z najważniejszych aspektów architektury cloud computing.

Wybór sposobu utworzenia cloud service

Docelowy system powinien zapewniać nowe mechanizmy, które zazwyczaj nie istniały w dotychczas używanych aplikacjach. Są to m.in.: adresowalność maszyn - zdolność do osiągania, przydzielania i używania cloud service, w układzie maszyna - maszyna, bez interwencji ludzkiej; wielodzierżawność, czyli zdolność do obsługi wielu zewnętrznych użytkowników cloud service w tym samym czasie, zapewniając jednocześnie spójną wydajność, jak również separację użytkowników; rozliczanie użytkowania - możliwość monitorowania użytkowania cloud service i obciążania użytkowników kosztami tego użytkowania; zaawansowane bezpieczeństwo - zdolność do zarządzania bezpieczeństwem z wykorzystaniem atrybutów tożsamości.

Istnieją trzy podstawowe scenariusze tworzenia cloud services z nowych lub istniejących aplikacji. W scenariuszu małego wdrożenia uzewnętrznia się tylko niewielką część aplikacji, zazwyczaj kilka usług, które wykonują proste operacje, takie jak np. walidacja danych. W tym przypadku wystarczy utworzyć web service, która ma dobrze zdefiniowany interfejs do akceptowania danych od użytkownika usługi, waliduje dane na zgodność z bazą danych podpiętą do aplikacji i zwraca status do użytkownika. Przykładem może być np. składanie zamówienia przez internet. W tym wypadku usługa wykonuje następujący ciąg zadań: otwarcie usługi - rejestracja użycia usługi i użytkownika - rejestracja czasu - akceptacja numeru zamówienia - walidacja numeru zamówienia - umieszczenie zamówienia w bazie danych - zwrot statusu zamówienia (poprawny lub nie) - rejestracja czasu - zamknięcie usługi.

Trzeba się oczywiście upewnić, czy można taką usługę wykonać w środowisku obsługującym wielu użytkowników (wielodzierżawnym), co przecież oznacza konieczność przydzielania zasobów równomiernie dla wszystkich użytkowników i chronienie procesów każdego użytkownika. Ponadto konieczne jest korzystanie z rozliczania opartego na użytkowaniu, w celu śledzenia użytkowania, bez względu na to, czy będzie się za to obciążać użytkowników, czy nie.

W małym wdrożeniu można wykorzystywać różne techniki, w tym programy zewnętrzne pracujące jako oddzielne procesy, które są wydzielone z rdzennych aplikacji i mogą wymagać niewielkich lub żadnych modyfikacji. Mogą to też być usługi ściśle sprzężone z aplikacją i wymagające pewnej modyfikacji programu podstawowego. Nie ma tutaj sztywnych reguł i każda taka cloud service powinna być traktowana jakom osobny przypadek.

Po zbudowaniu usługi włącza się powiązany z nią moduł WSDL (Web Services Description Language - oparty na XML język do definiowania usług sieciowych) i wybiera metodę komunikacji, którą jest zazwyczaj REST (Representational State Transfer). Użytkownik usługi powinien mieć możliwość dostępu do usług z wykorzystaniem URL - musi więc wiedzieć, jak wywoływać usługi przez czytanie WSDL, a następnie użyć REST do ich wywołania.

W scenariuszu wdrożenia średniej wielkości, zazwyczaj ma się do czynienia z wieloma różnymi usługami, zapewniającymi różne rodzaje funkcji. W tym scenariuszu istnieje dużo współbieżnych cloud services, które są dostępne dla różnych użytkowników usług, a to oznacza konieczność radzenia sobie z dużo większymi problemami współbieżności i wielodzierżawności.