Obliczenia zorientowane na usługi pojawiły się jako paradygmat dostarczania usług na żądanie użytkownikom. Tradycyjnie organizacje lub użytkownicy musieli dużo inwestować w zakup infrastruktury IT i wykwalifikowanych programistów, co skutkowało wysokimi kosztami posiadania. Jednak środowisko zorientowane na usługi oferuje użytkownikom znaczne korzyści, uwalniając ich od zadań niskiego poziomu, umożliwiając w ten sposób większe skupienie się na innowacjach. Na przykład osoba zajmująca się bioinformatyką może chcieć przetwarzać dane białkowe hostowane przez jedną instytucję za pomocą zdalnego serwera aplikacji w celu eksploracji danych prowadzonej przez inną, a następnie może chcieć zapisać wynik za pomocą publicznej usługi danych. Zamiast inwestować w infrastrukturę do wszystkich tych zadań, może on korzystać z usług oferowanych przez różnych usługodawców. Ze względu na te korzyści zapewniane przez różnych dostawców usług, wiele organizacji i użytkowników zaczęło teraz budować swoje aplikacje przy użyciu elastycznych i elastycznych usług oferowanych przez środowiska zorientowane na usługi. Jednak przejście do tych środowisk nie jest proste, ponieważ istnieje wiele wyzwań związanych z wykorzystaniem pełnego potencjału, jaki te systemy mają do zaoferowania. Wyzwania te są często związane z faktem, że odpowiadając każdemu z wymagań i charakterystyk specyficznych dla aplikacji, istnieje wielu konkurujących ze sobą dostawców, którzy mogą spełnić te wymagania przy różnej jakości usług (QoS) i różnych cenach. Ponadto może istnieć kompromis między różnymi funkcjonalnymi i niefunkcjonalnymi usługami świadczonymi przez różnych dostawców, co jeszcze bardziej pogarsza problem wyboru. Niektórzy złośliwi dostawcy mogą świadczyć usługi za niską cenę, choć może kosztem bezpieczeństwa lub prywatności przesłanej aplikacji. W związku z tym jest pewne, że ocena lub wybór dostawców musi odbywać się na podstawie takiego środka, aby zachować niezawodność i bezpieczeństwo aplikacji.