Microservices (& SOA)

Service Oriented Architecture:

- Check this http://martinfowler.com/bliki/ServiceOrientedAmbiguity.html

- A way of structuring many related applications to work together, rather than trying to solve all problems in one application.

- SOA means so many different things to different people

- For some SOA is about exposing software through web services and expect the various WS-* standards and those that will accept any form of XML over http 

- For some SOA implies an architecture where applications disappear. 

 Instead core services supply business functionality and data separated by UI aggregators - That apply presentations that aggregate together the stuff that core services provide.

- For some SOA is about allowing systems to communicate over some form of standard structure (usually XML based) with other applications - like CORBA

- For some SOA is all about using (mostly) asynchronous messaging to transfer documents between different systems. 

 Essentially this is EAI without all the expensive EAI (Enterprise Application Integration))vendors locking you in.         

 - ESB (Enterprise Service Bus)

- Actually a communication system between mutually interacting software applications in a service-oriented architecture (SOA).

- https://en.wikipedia.org/wiki/Enterprise_service_bus

- Primary duties of an ESB are:

- Monitor and control routing of message exchange between services

- Resolve contention between communicating service components

- Control deployment and Versioning of services

- Marshal use of redundant services

- Cater for commodity services like 

- Event handling, 

- Data transformation and mapping, 

- Message and event queuing and sequencing, 

- Security or exception handling, 

- Protocol conversion and 

- Enforcing proper quality of communication service        

Understanding Microservice Architecture:

In short, 

- Microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. 

- These services are built around business capabilities and independently deployable by fully automated deployment machinery. 

- There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.

In Detail:

First, 

- Software built as microservices can, by definition, be broken down into multiple component services.

- So that each of these services can be deployed, tweaked, and then redeployed independently without compromising the integrity of an application.

- Its downsides, includes expensive remote calls (instead of in-process calls), coarser-grained remote APIs, and increased complexity when redistributing responsibilities between components.

Second, 

- Microservices style is usually organized around business capabilities and priorities and not project

- Unlike a traditional monolithic development approach — where different teams each have a specific focus on, say, UIs, databases, technology layers, or server-side logic— Microservice architecture utilizes cross-functional teams. 

- The responsibilities of each team are to make specific products based on one or more individual services communicating via message bus.

Third,

- Microservices act somewhat like the classical UNIX system: they receive requests, process them, and generate a response accordingly.

- This is opposite to how many other products such as ESBs (Enterprise Service Buses) work, where high-tech systems for message routing, choreography, and applying business rules are utilized. You could say that microservices have smart endpoints that process info and apply logic, and dumb pipes through which the info flows

Fourth, 

- Decentralized governance is favored since involvement of a variety of technologies and platforms, old-school centralized governance aren’t optimal. 

- Microservice encourage developers to save time by always using code libraries established by others, while also giving them the freedom to flirt with alternative solutions when needed. 

- Monolithic systems use a single logical database across different applications. In a microservice application, each service usually manages its unique database

Fifth, 

- Like a well-rounded child, microservices are designed to cope with failure. 

- Since several unique and diverse services are communicating together, it’s quite possible that a service could fail, for one reason or another. In these instances, the client should allow its neighbouring services to function while it bows out in as graceful a manner as possible

Finally, 

- Microservices architecture is an evolutionary design and, again, is ideal for evolutionary systems where you can’t fully anticipate the types of devices that may one day be accessing your application. 

 To sum up: Microservice architecture 

 - Uses services to componentize and is usually organized around business capabilities; 

 - Focuses on products instead of projects; 

 - Has smart end points but not-so-smart info flow mechanisms; 

 - Uses decentralized governance as well as decentralized data management; 

 - Designed to accommodate service interruptions; 

 - Last but not least, is an evolutionary model

Pros: 

- Microservice can be developed by a fairly small team and thus easy to understand and modify for developers, thus can help a new team member become productive quickly

- For changes required in a certain part of application, only related service can be modified and redeployed—no need to modify and redeploy entire application

- Microservice architecture gives developers the freedom to independently develop and deploy services

- Code for different services can be written in different languages (though many practitioners discourage it)

- The developers can make use of the latest technologies and also No long-term commitment to technology stack

- The code is organized around business capabilities

- Easy integration and automatic deployment (using open-source continuous integration tools such as Jenkins, Hudson, etc.)

- Better fault isolation: if one microservice fails, the other will continue to work (although one problematic area of a monolith application can jeopardize the entire system)

- Easy to scale and integrate with third-party services

- Starts the web container more quickly, so the deployment is also faster

Cons: 

- Due to distributed deployment, testing can become complicated and tedious

- In addition to several complexities of monolithic architecture, the developers have to deal with the additional complexity of a distributed system

- Being a distributed system, it can result in duplication of effort

- When number of services increases, integration and managing whole products can become complicated

- Developers have to put additional effort into implementing the mechanism of communication between the services

- The architecture brings additional complexity to mitigate fault tolerance, network latency, and deal with a variety of message formats and load balancing

- Handling use cases that span more than one service without using distributed transactions is not only tough but also requires communication and cooperation - between different teams

- The architecture usually results in increased memory consumption

- Partitioning the application into microservices is very much an art 

 SOA vs. Microservices

- Some advocates reject the SOA tag altogether.

- While others consider microservices to be simply an ideal, refined/special form of SOA. 

   Note: SOA Tenents

- Boundaries are explicit

- Services are autonomous

- Services share schema and contract, not class

- Service compatibility is based on policy

         

- Microservices fulfill at least the first two tenets (with a real emphasis on the second), but it's questionable whether they fulfil the third & fourth.

  The reason the third tenet may not hold for microservices is that one of the characteristics of microservices is that they are generally exposed over a RESTful API, which, one could argue, does not expose contract and schema at all (over and above the regular HTTP verbiage).

- Few differences:

- SOA usually has more dependent ESBs, with microservices using faster messaging mechanisms. 

- SOA also focuses on imperative programming, whereas microservices architecture focuses on a responsive-actor programming style. 

- SOA models tend to have an outsized relational database, while microservices frequently use NoSQL or micro-SQL databases

- Microservices is opposite to how many other products such as ESBs (Enterprise Service Buses) work, where high-tech systems for message routing, choreography, and applying business rules are utilized. You could say that microservices have smart endpoints that process info and apply logic, and dumb pipes through which the info flows

Well still the real difference has to do with the architecture methods used to arrive at an integrated set of services in the first place. 

 Hope this helps.

http://arun-architect.blogspot.com

Arun Manglick