My view on Microservices Architecture (MSA)

It is a new architectural pattern to Design & Develop application(s) into smaller and manageable modular services that can be built using APIs/services with modern languages/frameworks. 

Though this is more popular and fashionable idea, is not a very new in Architects and Designers world when creating large and monolithic application. They have been contemplating to adopt this to build more scalable and maintainable solutions. Their thoughts were always limited by the availability of tools and technologies for implementation and new operational complexities.

Why MSA and What is the reason behind the popularity?

• The emergence of lightweight REST integration (API Management) over popular SOAP (SOA-ESB) systems.
• The emergence of new languages/technologies/frameworks that allow a few solutions can be developed with modern languages/frameworks. The replacement of these solutions can also be built more quickly if they are not addressing the requirements.
• DevOps: Advancement in hardware where a software (Hypervisor) can be used to automate infrastructure, scaling the instances as needed and utility computing. 
• Virtualization and Docker/Container management.
• Change in how systems are communicated with Datastore, As there are more reads of data over writes; the gaining popularity of CQRS (Command Query Responsibility Segregation) with Event Sourcing over CRUD (Create Read Update and Delete) operations.
• Emergence of new DBMS systems (RDBMS, SQL, NO-SQL, Graph SQL) etc..
• Different interfaces (Desktops, Hand held devices with Mobility) to access the solutions with different user experience built on the same back-end solutions.
• Growing popularity in Systems working on Distributed Architecture.

Characteristics:
The API brings standardization of service development and its accessibility.
It promotes to develop, build and deploy the pieces (modules) of software independently and also offers scalability in deployment.
It is also a new architecture & design style to migrate Monolithic application (one big single application with lot of components without modularity) into more smaller services that are designed, developed, built and deployed independently.
It offers re-usability of these smaller modules (services) as this is essential to Enterprise with shared services organization.
It prefers BASE (BasicallyAvailable, SoftState and Eventually Consistent) transactions over ACID (Atomicity,Consistency,Isolation, Durability) in Distributed Architecture.
It prefers CQRS (Command Query Responsibility Segregation) with ES (Event Sourcing) over CRUD operations as there are more Reads than Writes.

Problems of Monolithic:

Code complexity and maintainability
Deployment becomes the bottleneck
Fear to change once the asset is grown big enough to make changes and regression-impacts.
Lack of ownership as it is
One size doesn’t fit all (ex: relational DB)
Hard to scale out, though limited scale up is possible.

Benefits of Microservices:

• Speed
• Faster development and deployment
• Polyglot
• Innovation
• Autonomy of teams, culture of change
• Ownership and DevOps culture
• Quality
• Reusability & more maintainable code
• Better scaling and optimizations
• Failure Isolation and Resilience

Disadvantages

• Overhead or Complexity of Communication in Development, Deployment and Operational Management. Some Cloud vendors (AWS) have addressed some of these solutions with tools.
• Fairly new concept. Challenges in Finding experienced resources in market and Enterprise adoption.
• Change of mindset is required to adopt to realize the benefit on ease of doing.
• Technology stack is evolving fast: Determining when they are ready for Enterprise.
• Investment overhead of both new API and ESB in large enterprises.

Though the Tier-1 technology companies (ex. FAANG) which can repeatedly re-invest in re-writing their popular solutions on new and modern architectures to offer new experience to customers, it is fair to say that the Tier-2 and organizations where IT is supporting the other business would mostly wait and see until the tools and practices are stable and technology becomes enterprise ready.

The startups and smaller organization can always venture into as their size, existing and limited investments would allow them to invest in these new areas.