The document discusses microservice architecture and compares it to monolithic architecture. It describes microservices as small, discrete, isolated services that can be deployed separately. A monolith is a single application combining all business logic and data access. The document outlines characteristics of microservices such as single responsibility, statelessness, independent data management and communication through APIs or message queues. It also covers deployment, testing, monitoring, metrics and the need for automation and a culture open to change when using microservice architecture.

1. Microservice
Architecture
Engin Yöyen
November, 2014

2. What is a microservice?
… is a small, discrete, isolated, lightweight
application that is stateless service and can be
deployed separately.

3. What is a monolith?
… is a single unit of application, which all the
business logic and data access code are combined
into a single application.

4. Microservice vs Monolith?

5. Call Center
• Agents : Current available agents
• Calls : Current calls with details such customer,
length of call, agent
• Statistics : Current number of calls per day
• Monitoring : Failing calls, connections, etc.

6. This is how does it look like!

7. And this is how you scale!
…of course, more work involved!

8. Comparison
Monolith Microservice
Update and Feature
Delivery
new features takes time
to implement
easy to understand
easy to implement
Deployment not frequent but easy
frequent but
orchestration can be
challanging
Isolation
errors can have effect
on entire system
error has effect only on
particular services
Response Time Process call (Faster) API Call (Slower)

9. Comparison (2)
Monolith Microservice
New Developers
Long learning curve
(understanding
application)
Long learning curve
(understanding
architecture)
Technology
Standardization on
single technology
Choice of technology
based on problem
Testing Relatively Simple
Complexity of
distributed systems
Development Tools
(IDE)
Larger the code base
slower the IDE gets
Not an issue

10. Characteristics of
Microservice Architecture

11. Single Responsibility
• Single Responsibility Principle : Do one thing, but
do it well
• a responsibility = a reason for change
• How small is small? Size does not matter!
• Line of code(LOC) is not a good measurement,
depends on language, on developer.

12. Stateless
• Each request as an independent transaction
• Persist your data!

13. Data Management

14. Data Management
Each service can have it’s own data store, and it can be different technology

15. Communication between
services
• HTTP (Request, Response)
• Message Queue (e.g. RabbitMQ, zeroMQ )
• Don’t Reinvent The Wheel. Use
• HTTP Status Code
• HTTP Headers
• REST (Not just the url also the body)

16. Deployment
• Each service has its own
• Repository
• Build Pipeline
• Host
• Build single artifact that represent release candidate. Do not
build artifact for different environment
• Manage configuration separately
• Can we provision a server less than 1 minute?

17. Deployment
Source : http://www.slideshare.net/fasgoncalves/hypervisor-versus-linux-containers

18. Deployment : Image
Management
Source : https://www.joyent.com/developers/image-management/

19. IT Configuration and
Automation
• Don’t do anything manually on any of your servers
• Good understanding of IT Automation and tools
(e.g. Ansible, Chef, Salt, Puppet)
• Flexibility to build and deploy new services
• You Build It, You Run It!

20. Testing
Source : http://lisacrispin.com/2011/11/08/using-the-agile-testing-quadrants/

21. Testing
• Test different scope,
for different purposes
• Higher the pyramid,
shorter the feedback cycle
Source : http://www.thoughtworks.com/insights/blog/
introducing-software-testing-cupcake-anti-pattern
• End-to-End tests are not easy for microservices
• Team structure, who writes the test
• Testing multiple microservices
• Network issues, time-to-complete

22. Monitoring
• Monitor your host and individual services
• Check health of your system
• Keep track of your logs
• Build and use conventions (e.g. Standardise your
logs)
• Use existing tools: ElasticSearch, Kibana, Graphite,
Logstash,

23. Metrics
• Response time
• Error Rate
• Correlation ID

24. The Company Culture
• Decentralized Governance: Right tool for right job
• Open enough to change and adopt
• Cross functional teams (e.g. for testing, operations)

25. Questions