Understanding Microservices

Lego building for your platform

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

mahtonu.wordpress.com

Imagine a local railway platform…

Scenarios!

• 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..

Monolithic App vs Microservices

• 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.

Microservice?

No official definition, No Standards,

But has a set of Characteristics

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.

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

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

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.

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

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

Prerequisites

• Rapid Provisioning

• Basic Monitoring

• Rapid Application Deployment

• Devops Culture

Case Study: Sample Microservices for an

E-Commerce Platform

An e-commerce platform that

• Talks JSON over HTTP

• User interface:

• Web frontend (javascript client)

• iOS app

• Android app

• Third-party clients

E-commerce: Define Scopes

• User accounts

• Catalog

• Cart and Checkout

• Orders processing

• Inventory

Monolithic way

• 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

Microservices way

• 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

• Independent deployments

• Issues are easier to diagnose and debug

• More maintainable codebase

• More testable application

Known users• Pivotal

• Uber

• Netflix

• Google

• Amazon

• Salesforce

• Soundcloud

Implementations

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)

References

• Martin Fowler’s Microservices: https://martinfowler.com/articles/microservices.html

• Photo courtesy: martinfowler.com