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. In this slide we have discussed, Monolithic application vs Microservices, applicable scenarios for adopting the architectural pattern, when we need microservices, what are the benefits, case study of an e-commerce platform by compartmentalizing the scopes into different sample microservices and Docker implementations. The full talk has been recorded here: https://youtu.be/tNlp7HS533g

1. Understanding
Microservices
Lego building for your platform

2. About Me
M A Hossain Tonu
@Vantage Labs Dhaka
mahtonu@vantage.com
Authored the title “PHP Application
Development with NetBeans:
Beginner's Guide”
mahtonu.wordpress.com

3. Imagine a local
railway platform…

5. Scenarios!

6. • Few small agile teams (co-located in different
offices + remote team) working on multiple
products
• When it comes to Refactor
• Failure and blame game is On
• New members joins in
• Worried about scalability?
• and so on..

7. Monolithic App vs
Microservices

9. • A monolithic application built as a single unit.
• Enterprise Applications = a client-side user interface + a
database + a server-side application.
• Change cycles are tied together - a change made to a
small part of the application, requires the entire
monolith to be rebuilt and deployed.
• Over time it's often hard to keep a good modular
structure, making it harder to keep changes that ought
to only affect one module within that module.
• Scaling requires scaling of the entire application rather
than parts of it that require greater resource.

10. Microservice?

11. No official definition, No
Standards,
But has a set of Characteristics

12. In short, 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.

13. Architectural Pattern
• The microservices approach is a first realisation of
SOA that followed the introduction of DevOps and
is becoming more popular for building continuously
deployed systems.
• In a microservices architecture, services should
have a small granularity and the protocols should
be lightweight.
• Reinforced by the Single Responsibility Principle

14. Why?
• Failure isolation (yes, you’ll be greatful when it comes
to debugging issue in production, and you have clear
boundaries of each service responsibilities)
• Decentralized data management
• Super fast deployments to independent components
(microservices)
• Scalability
• Flexibility

15. Benefits
• Distributing different responsibilities of the system into
different smaller services
• Decreases the coupling
• Easier to change and add functions and qualities to the
system
• Allows the architecture of an individual service to
emerge through continuous refactoring
• Reduces the need for a big up-front design and allows for
releasing software early and continuously.

16. Benefits
• Implemented using different programming
languages, databases, hardware and software
environment, depending on what fits best.
• Small in size, messaging enabled, bounded by
contexts, autonomously developed, independently
deployable, decentralized and built and released
with automated processes
• Design for Failures

19. Criticism
• Network latency, message formats, load balancing
and fault tolerance
• Inter-service calls over a network have a higher cost in
terms of network latency and message processing
time than in-process calls within a monolithic service
process
• Moving responsibilities between services is more
difficult. It may involve communication between
different teams, rewriting the functionality in another
language or fitting it into a different infrastructure

20. Prerequisites
• Rapid Provisioning
• Basic Monitoring
• Rapid Application Deployment
• Devops Culture

22. Case Study:
Sample Microservices for an
E-Commerce Platform

23. An e-commerce platform
that
• Talks JSON over HTTP
• User interface:
• Web frontend (javascript client)
• iOS app
• Android app
• Third-party clients

24. E-commerce: Define Scopes
• User accounts
• Catalog
• Cart and Checkout
• Orders processing
• Inventory

25. Monolithic way

26. • ALL requests that user makes follow this pattern:
• Request delivered to app
• App reaches out to memcache to see if there’s cached version of that resource
• If no, then it makes query to get resource from database
• Simple, easy, not so scalable. From both: development and performance
perspectives.
• Imagine 30 people working on same app codebase - nightmare! I bet in effective agile
environment, they’ll have quite a few problems and these will be amongst them:
• Slow and clumsy releases
• Hard to manage incoming changes
• Lack of continuous delivery
• Struggling with time it takes to manage codebase and keep all in sync

27. Microservices way

28. • Talks json
• Logically (and ideally physically) isolated from
others
• Doesn’t share resources with other apps
• Has it’s own codebase
• Has clearly defined data ownership

29. • Independent deployments
• Issues are easier to diagnose and debug
• More maintainable codebase
• More testable application

30. Known users
• Pivotal
• Uber
• Netflix
• Google
• Amazon
• Salesforce
• Soundcloud

31. Implementations

33. Docker
• Package the microservice as a (Docker) container
image.
• Deploy each service instance as a container.
• Scaling is done based on changing the number of
container instances.
• Building, deploying, and starting microservice will
be much faster as we are using Docker containers
(which is much faster than a regular VM)

34. References
• Martin Fowler’s Microservices: https://
martinfowler.com/articles/microservices.html
• Photo courtesy: martinfowler.com