Why Micro Services ?

Why Micro Services ?

Micro Services are the next big thing in the modern software architecture and development. The distributed applications in the recent past changed the world of software outlook. Now the applications are developed, used, work and built differently. This caused the logical evolution of Micro Services. Some best examples of game changers in the software world are Git ( Distributed source control), Cloud computing (AWS, Azure, …), BitCoin (Distributed virtual currency).

Let’s begin our journey with understanding, What are Micro Services?

The Philosophy

The whole idea of Micro Service architecture is that they are small, focused and should be scaled.  

The Definition

The 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 centralized management of these services, which may be written in different programming languages and use different data storage technologies.” – Fowler & Lewis, 2014.

This idea looks very similar to SOA. When I first heard about Micro Services, I thought they are just web Services and got many questions related to them. Some of them are as below
Why these services are called Micro Services?
What is the difference between these micro services and web Services ?
How different this world is different from SOA world?

Characteristics of Micro Service:

Do One thing well : Services should hide, how they work and do a single thing and do it well. The encapsulation is based on the business function of the service that it encapsulates the functional requirements.

Business Domain Centric : Each Service should align to the context with in the domain model for this to make sense in the domain and in the service architecture.

Decentralization : Every service should be decentralized and autonomous, so that each service can operate on its own schedule and priorities. Each service can be updated and deployed as fit.

Smart Endpoints and dumb pipes: This characteristic has come based on SOA, in SOA we have many products / ESB where we can define lot of logic in routing and transforming etc. Where as in Micro services the focus on login inside the service and the communication should happen very dumb like a REST / HTTP resource call to get to the service.   

Fail-Safe : Enterprise systems need to be smart, in that they fail in a way that doesn’t break things in unpredictable ways. Anticipate failure in everything, among with  validation of input and validation of data we send downstream.

Automation : Services should use automation which keeps management and operational support efficient. Employing large number of small services can become a mess if you do not embrace automation.

Principles of Micro Services – Encapsulation, Automation, Business Domain Centric, Isolation, Fail-safe and Observable.

Micro Service Vs Web Service:

The regular Web services are definitely different from Micro services. The regular web services support is based on protocols like HTTP / SOAP. These services are invented to solve the integration problems between application when we have polyglot technologies with different vendors/ applications. So, the aim of web services is to integrate or build a channel to communicate between these applications. Where as Micro services aim is NOT to integrate applications, perhaps to reduce the complexity of a monolithic application to micro services. This would give us re-use, maintainability, test-ability, scalability etc in the application.

Micro Services Vs SOA:

SOA started with very similar characteristics mentioned above, but the idea got converted when many vendors started introducing new features to SOA. Then we have a vendor lock-in problem now. We have lot of logic built in around the services NOT inside the services. So, Micro services are the out come of learning of SOA. Still, micro services are evolving. We might end up with very similar problems of SOA, if we are not cautious. Hope we would be able to use micro services the way they are explained.

Technology Support:

Here are the technology

Building Micro services with Spring Boot

Building Micro services with Drop Wizard

References:

Fowler & Lewis on MicroServices

Videos on MicroService Architecture

Software Architects & Designers

Software Architects & Designers

Some days back when I was discussing something with my friend over a coffee we had this question. His idea goes like this – “All developers when they become seniors, they do design the system. If any developer with good  designing experience of some years, can become Architect.” I agree the fact, that you need a designing experience to become an Architect, however all designers may not be good fit for an Architect.

I would try to give my own definition of these two roles, let’s try to be on same page, then we can move on with the discussion point Architect Vs Designer.

Architect : He/ She is the one who defines the high level abstraction of the system/ software. The system/software may contain many different components inside. If it has many components then Architect’s job is to define the integration points, choose right technologies to different components, choose right tools & methodologies for these defined components. In some cases Architect even can influence the development process like introducing new step/ stage for code review and test with code static analysis tool before checking the code in to repository. He/ She is responsible for non-functional requirements like Scalable, Maintainable, Flexible, Available system.

Software Designer is not a very regular designation in software companies. So I would consider a Sr Developer / Technical Lead who is designing software for some years.

Designer : He / She define the low-level of the abstraction,each component should be designed by Designer to meet the functional requirements of that component by not compromising on Performance and Scalability of the system. Designing detailed interfaces and implementation of them.

I would like to map the things in a tabular format, for easier understanding.

Architect Designer
Vision Strategic (Long term – Alignment to Business) Tactical (Short term – Integration between modules /components)
Abstraction High Level Low level
Defines Skeleton of the System Fill the Skeleton with Designing the details
High level components Design each Component
Involved When ?  “What” Phase of the system “How” Phase of the system
Focus Area ? Non Functional requirements (Scalability,Availability,Flexibility etc) Focus – Functional requirements
Suggest Frameworks, Methodologies, Integrations, Tools, Technologies, Patterns etc Best Practices, Applying Design Patterns, Design Considerations
Create Component Diagram, Interaction overview, Deployment, Use case, Class, Package(optional) Class, Package, Object, Activity, Sequence
Document Architecture Overview, Integrations, Design Decisions Design Decisions, Best Practices, How to ..s ?, CODE

Finally a pictorial view

Architect_Vs_Designer

I hope this is useful for the people who are trying to understand these roles. Thanks

Useful references :

Software Architecture defined by Carnegie Mellon University

Learn UML Diagrams and their Importance

StackOverflow Architecture Vs Design Discussion