This document discusses microservices architecture as an alternative to monolithic architecture. It defines microservices as independently deployable services that communicate through lightweight mechanisms like HTTP APIs. The document outlines benefits of microservices like independent scalability, easier upgrades, and improved developer productivity. It also discusses prerequisites for microservices like rapid provisioning, monitoring, and continuous deployment. Examples of microservices frameworks and a demo application using Spring Boot are provided.

1. Microservices Architecture
By Durga Lovababu

2. Agenda / Topics
• Monolithic Architecture
• Microservices Architecture
• Scalability
• When Microservices
• Microservices Prerequisites
• Demo Application
• Q?

3. Monolithic Architecture
• Monolithic application describes a single tiered software
application in which the user interface and data access code are
combined for every feature/business requirement into a single
war/ear/dll.
• There are logical components corresponding to different
functional areas of the application.
• Single war/EAR/dll/exes.
• Simple to develop, deploy and manage.

4. Monolithic Architecture.
• Typical Architecture Diagram.

5. Monolithic Architecture End
However once the application becomes large and the team grows in
size, this approach has number of drawbacks.
Large and complex code base can be difficult to understand and modify. As a result
development slow down.
Overloaded IDE, As a result slower the IDE and less productivity.
Overloaded Webcontainer - the larger applications slow down the server startup.
Continuous deployment is difficult – in order to change in one component forces to redeploy
the entire application.
Hard to Scale.
Require long term commitments to technology stack upgrade.

6. Microservices Architecture
• Microservice is an Architecture style as a specialization of SOA.
• Approach to developing a single application as a suite of small services, each
running its own process and communicating with light weight mechanism,
often an HTTP resource APIs.
• Each micro service is small and focused on specific feature/business
requirement.
• Independent scalable.

7. Microservices Architecture
• Typical Architecture diagram.

8. Microservices Architecture
Microservices can be developed independently by small team of developers.
Microservices are loosely coupled, means services are independent in terms of development
and deployment.
Each microservice can be developed in different programming language.
The productivity of new team member will be quick enough.
Should be container less deployment.
Sharing the same data base instance can be avoided, and NoSQL.
Microservices are easy to scale independently on demand.
No long term commitments required to upgrade tech stack.
Microservices are status aware.
 In app metrics.
 Ping and health checks.

9. What is Scalability?
• Is the ability of a computer application or product (hardware or software) to
continue to function well when it is changed in size or volume in order to
meet a user need.
• Capable of being easily expanded or upgraded on demand to handle
increasing loads without changing design.
• A service is said to be scalable if when we increase the resources in a system,
it results in increased performance in a manner proportional to resources
added.
• Scalability can be achieved in two ways.
• Vertical Scalability.
• Horizontal Scalability.

10. Scalability Continue
• Vertical Scalability. • Horizontal Scalability.

11. Microservices Architecture
Frameworks to develop Microservices.
Dropwizard (written in Java)
Spring Boot (“ in Java)
Vert.x (“ in Java, JS, Groovy, Python, Ruby, Scala and Clojura)
Grails (“ in Groovy)
Ratpack (“ in Java)
Play (“ in Scala and Java)
Django (“ in Python)
WCF (“ in .NET)
There is a option to design container less/independent deployable services
using known framework spring 3+ and embedded jetty.

12. Microservices Architecture
Disadvantages.
Developers must deal with additional complexity of creating a distributed
system.
IDE do not support to develop distributed systems.
Testing is more difficult.
Developers must implement the inter service communication mechanism.
Deployment and operational complexity of deploying and managing system
comprised of many different services.
Finally Distributed system are complicated to manage.

13. Microservices Architecture
• Success Stories.

14. When Microservices ?
Microservices approach is all about handling a complex systems.
Principle: Device and conquer. Break down the complex problems into smaller
parts that can be solved independently.
When you use microservices you have to work on automated deployment,
monitoring, dealing with failures and other factors that a distributed system
introduces.
Don’t even consider microservices unless you have a system that’s too complex
to manage as a monolithic.
Monolith first! Do pay attention to good modularity within the monolith, but
don't try to decompose it into services from Greenfield systems.

15. Microservices Prerequisites?
Rapid Provisioning – achieve through cloud.
Basic Monitoring – metrics and health checks.
Rapid Application Deployment – achieve through CD.

16. Demo Application.
• Tech Stack.
• Spring Boot
• Spring boot embedded tomcat.
• Hibernate ORM.
• H2 inMemory data store.
• Jsondoc user interactive documentation.
• Feign and OKHTTP for client implementation.
• Interested one can clone it from here.
https://github.com/lovababu/SpringBootExample.git

17. Q?