Kind of kills an idea of transactions over distributed system. Но лично мне идея eventual consistency куда больше нравится
Нашла крутое видео по теме, но примеры во второй части (там вначале упоминается название "apps plus data plus cloud what does it all mean" ...) следы которой я не могу нигде найти в Интернете. Никто не поможет ? Хотя бы code samples only
http://www.youtube.com/watch?v=iMvCOEsSuAc
UPD нашла PPT http://www.slideshare.net/SpringCentral ... t-all-mean...To start explaining the microservice style it's useful to compare it to the monolithic style: a monolithic application built as a single unit. Enterprise Applications are often built in three main parts: a client-side user interface (consisting of HTML pages and javascript running in a browser on the user's machine) a database (consisting of many tables inserted into a common, and usually relational, database management system), and a server-side application. The server-side application will handle HTTP requests, execute domain logic, retrieve and update data from the database, and select and populate HTML views to be sent to the browser. This server-side application is a monolith - a single logical executable[2]. Any changes to the system involve building and deploying a new version of the server-side application.
Such a monolithic server is a natural way to approach building such a system. All your logic for handling a request runs in a single process, allowing you to use the basic features of your language to divide up the application into classes, functions, and namespaces. With some care, you can run and test the application on a developer's laptop, and use a deployment pipeline to ensure that changes are properly tested and deployed into production. You can horizontally scale the monolith by running many instances behind a load-balancer.
Monolithic applications can be successful, but increasingly people are feeling frustrations with them - especially as more applications are being deployed to the cloud . Change cycles are tied together - a change made to a small part of the application, requires the entire monolith to be rebuilt and deployed. Over time it's often hard to keep a good modular structure, making it harder to keep changes that ought to only affect one module within that module. Scaling requires scaling of the entire application rather than parts of it that require greater resource.....
Я бы не сказал что сервисы у нас "микро", скорее "макро" потому что один сервис за достаточно много вещей отвечает. Насколько я понимаю в Gilt например сервисы действительно микро и их количесво сотни, у нас наверное десяток еле наберется.