Microservices, DevOps and Docker: The new SOA software architecture Part I.

Everyone new something about SOA, it’s an architecture style based in business services, we know but what about Microservices…. Something new? Not really.

Adrian Cockcroft at Netflix, describing this approach as "fine grained SOA" was pioneering the style at web scale as were many of the others mentioned in this article - Joe Walnes, Dan North, Evan Botcher and Graham Tackley.  This approach is as we now in the traditional SOA, to developing a single application as a suite of small services (in different languages), each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. The traditional 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 or NoSQL, 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. Traditionally this server side is logically monolithic, that means any changes will create another build and deploy and the scale will be archived horizontally running many instances behind a load-balancer.

The Solution:

The monolithic server application normally will run in a single server and normally will replicate in a multiple server (Ex a VM in AWS). So is clever to use micro services put every functionality in a separate service that can scale across servers (replicates as need)

Microservice Architecture: the basics

Componentization (Services):

This is the field most advanced right now because we could define a component that is a unit of software that is independently replaceable and upgradeable and will represent functionality for business or accessory as SOA traditional definition. We define libraries as components that are linked into a program and called using in-memory function calls, while services are out-of-process components who communicate with a mechanism such as a web service request, or remote procedure call. One main reason for using services as components (rather than libraries) is that services are independently deployable. Are you think the same as me ?.. let explore a little more.

Organized around Business Capabilities

Normally we group IT (UI, DBAs, etc.) guys with similar skills, put a manager (that should know this skill) on every group. This cause several problems of budget, misunderstanding etc. and deliver a silo application because every group develop his own part ONLY.

This is SO common that was declare as a law

“ Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure".

-- Melvyn Conway, 1967

The question is WHY ?.. let explore a little more

The microservice change this, because splitting up the functionalities into services organized around business capability for that business area, including user-interface, storage, and any external collaborations. Consequently, the teams are cross-functional, including the full range of skills required for the development: user-experience, database, and project management.

mmm… there is something Agile in this approach? Definitely! Scrum methodology claim to put ALL the team together, include the business, do you remember? ... let see what more... in next chapter