SOA var i sin spæde begyndelse (SOA v1.0) centreret om at transport data og orkestrering af funktionskald via et centralt komponent kaldet en enterprise service bus (forkortet i dette blogindlæg som ESB). Det centrale komponent var på en række områder en type system der ville påvirke den måde som webservices skulle udvikles så data kunne transporteres mellem endpoints der skulle modtage dem.
Siden da er der kommet nye paradigmer til i forhold til konceptet SOA og et af disse er microservices. Paradigmet stiller nogle andre krav til de forskellige applikationer og IT-løsninger der bygges i organisationen der vælger at anvende det pågældende arkitekturparadigme. Der findes også andre anskuelser af det pågældende arkitekturparadigme og det går blandt andet ud på, at der findes udfordringer ved at arbejde med den pågældende måde at arbejde med integrationer på.
I videoen nedenfor præsenteres en række interessante perspektiver på, hvorfor netop microservices kan vise sig at være en måde vil medføre en række udfordringer for organisationen med henblik på udvikling af informationssystemer.
Antiteserne
- Mange skridt for at opnå gevinstrealisering ved anvendelse af microservices.
- Mange køer for at håndtere hændelser i applikationerne.
- Risici for hardcode services lokalisering, hvilket betyder at IP-porte er programmeret ind i selve webservicen.
- Deployments af kildekode kan blive kompliceret.
- Ændringer i kildekoden kan lede til problemstillinger med produktionsmiljøerne.
- Risiko for debugging helvede slippes løs og en kæmpe samling af “correlation of IDs”.
- Risiko for “Flying Blind” der involvere udfordringerne ved at overvåge de rigtige data og at reagere på de rigtige data.
CoherencyArchitect
EnterpriseArkitekten.com 
Microservices er et interessant nyt element i værktøjskassen for at realisere service orientering, Som det er fortalt af Fowler og andre blev de udviklet som koncept af udviklere hos Netflex for at muligøre en løbende trinvis udvikling og deployere af funktionalitet, uden at skulle håndtere en traditionel ESB platform.
Når man begynder at få mange af dem kræver det som så meget andent en stærk og sund gennemgående og discliplineret software arkitektur for at styre de problemer, der nævnes i ovenstående. Dertil kræver det som i alle integrationsopgaver en koordineret og styret semantik på tværs af alle implementeringer. Begge dele er mest muligt hvis man har kontrol over hele softwarelandskabet. Men det er jo ikke altid tilfældet.
Et hovedproblem, som delvis berøres i ovenstående, er at hver microservice holder og ejer sine data, hvorfor en stram styring på tværs af sine microservices af netop ens tolkning af samme data (semantisk koordinering og master data management) er strengt nødvendig.
Anne Thomas hos Gartner foreslår at man implementerer et service control layer mellem de microservices, man selv har kontrol over, og eksterne microservices. Det skal være det sted hvor man enforcer policies og sikkerhed ift parter, man ikke har kontrol over, En salgs policy gateway.
Nils Bundgaard
Rambøll