This document compares and contrasts microservice architecture (MSA) and service-oriented architecture (SOA). SOA defines application components as loosely coupled services that communicate over a network, while MSA develops applications as suites of small services communicating via lightweight mechanisms like REST. The document also discusses Netflix's transition from a monolithic to a microservices architecture led by Adrian Cockcroft, highlighting benefits like speed, autonomy, and flexibility.

1. 1
Microservice Architecture (MSA) and
Service-Oriented Architecture (SOA)
Sonic Lee
mcsonic@gmail.com

2. 2
1
2
3
4
Service Oriented Architecture
Description and comparison with monolithic architecture
Microservice Architecture
Simple example and key characteristics
MSA vs SOA
Show difference in overall architecture and comm. protocol
MSA Case Study: Netflix
Adrian Cockcroft’s effort in turning legacy system into MSA and
what we can learn

3. 3
Service Oriented Architecture
Definition (from Wikipedia)
• Architectural pattern in computer software design in which application components
provide services to other components via a communications protocol,
typically over a network.
Characteristics
• Service is the basic building block, and is a self-contained unit of functionality.
▪ Ex: View last month’s credit card history.
• Services use loosely-coupled components that can be reused later.
• Components communicate using standards like JSON, XML, SOAP.
• Independent of any vendor, product or technology.
• Must be incremental, and built on current investments.
• SOA is a means, not an end.
Why?
• Adapt applications to changing technologies.
• Easily integrate applications with other systems. (systems are exposed)
• Quickly create a business process from existing services.

4. 4
Service Oriented Architecture – Four Tenets
1. Boundaries are explicit
• Services interact by sending messages across boundaries.
• No assumptions about how other service is made.
2. Services are autonomous
• Services do not depend on other code.
• Deploy and version services independently from clients.
• Contracts (WSDL: Web Services Description Language)
should not be changed once published.
3. Services share schema and contract, not class
• Services communicate by using schema & contracts (WSDL in XML)
• Internal data format should be hidden from consumers.
• Public schema should be immutable.
4. Service compatibility is based upon policy
• Define what (structural) and how to (semantic) communicate.
• Every service provides a description of capabilities & requirements in machine code.

5. 5
Before / After SOA
App A Service AApp A DB A
App A App B App C Service A

6. 6
Microservice Architecture (MSA)
Definition (from Martin Fowler)
• Approach to developing a single application as a suite of small modular services,
each running in its own process and communicating with lightweight
mechanisms, often an HTTP resource API. (REST with JSON, SOAP with XML)
• Each service is independently deployable by fully automated deployment machinery.
Client-side
[JS / HTML]
Server-side
[HTTP request]
Relational DBMS
monolith
[Monolithic]
Client-side
[JS / HTML]
Customer
User DB
[Microservices Architecture]
Product Order
Product DB Order DB
API (Remote call)
URL 1 URL 2 URL 3
REST
RPC AMQP

7. 7
Microservices: Key Characteristics
• Store data in different DB for efficiency. (Polyglot persistence)
• Must keep DB’s in sync. (DB structures / foreign keys)
• Use Master Data Management tool to fix inconsistencies.
✓ Many RDBMSs do these checks, but require too much coupling.
• Immutable Infrastructure Principle
✓ Apply changes to a new service.
• Do separate build for each microservice.
(OK to have different revision level files)
• Servers must be interchangeable and able to scale.
Treat servers like generic cows, not pets
• Each microservice can use its own language / technology.

8. 8
Microservices: Key Characteristics
Small, cross-functional teams with
flat, self / peer-management structure
Can scale and innovate successfully
“It’s not about technology, it’s about people.”
- Asim Aslam from MicroHQ
• Set up comparable teams
• DevOps: respond faster to customer feedback
Just using REST or Docker does not make it MSA

9. 9
Microservices: Key Characteristics
Product-based not project-based
• Project is a one-time development, making it hard to accumulate expertise.
• De-centralized gov. model needs to guarantee developers’ career in some way.
• Service team: Product planning, Development, QA, Operation.
Team as suggested by Amazon

10. 10
Who uses Microservices?
• Netflix: https://www.nginx.com/blog/microservices-at-netflix-architectural-best-
practices/
http://techblog.netflix.com/2016/12/netflix-conductor-microservices.html
• Amazon: http://www.slideshare.net/apigee/i-love-apis-2015-microservices-at-
amazon-54487258
• Ebay: http://www.slideshare.net/kasun04/microservices-at-ebay
• Uber
• Groupon
• Capital One

11. 11
SOA vs Microservice Architecture (MSA)
What is the difference?
• SOA is a broader concept, and refers to architectural pattern.
• Microservices is a fine-grained, more modular “ideal” type of SOA.
SOA
• More dependent ESBs
• Imperative programming
• Large relational DB
MSA
• API Gateways
• Reactive programming
• NoSQL or micro-SQL DB
…But Both Share
• Loosely coupled elements with
bounded contexts
Payment
Service
Cancel
Service
DB DB

12. 12
SOA vs MSA communication protocol
SOA ESB (Enterprise Service Bus)
• Communication backbone to connect various services together.
• Applications can communicate asynchronously and not have to wait.
• Allows loose coupling between applications.
Disadvantages
• Parsing XML messages causes overhead.
• ESB can become single point of failure for the network.
• Often wrongly used to integrate applications. (EAI)
• Vendor-driven

13. 13
SOA vs MSA communication protocol
MSA API Gateway
• Smart endpoints and dumb pipes. (Most operations occur in endpoints)
• REST protocols and lightweight messaging. (RabbitMQ / ZeroMQ)
• Orchestration: Combine multiple services to create new ones. (Buy + membership)
• Cross cutting function handling: Handle common functions. (Auth, logging)

14. 14
MSA disadvantages
Performance
• API call returns results in JSON or XML. (Marshalling overhead / Network latency)
Memory
• Each service is deployed in its own server instance. (# of Service * memory in each)
Testing
• Each service is separated, so integrated testing becomes more difficult.
Guaranteeing consistency may be hard
• HTTP protocol is sync in nature.
• Client -> Server can be sync, but internal microservice comm. must be async.
1. 202 Accepted (Tell client to wait)
2. 200 OK (Final result returned)

15. 15
MSA Case Study: Netflx
Netflix: Adrian Cockcroft
• Key architect: moved Netflix’s own data centers to Amazon’s cloud.
• Implemented public-cloud architecture & open-sourcing Netflix OSS platform. (MSA)
• Changed Monolithic service to hundreds of meshed-up microservices.
• Built on NGINX:
Open source SW for web service, reverse proxy, cache, load balancing

16. 16
MSA Case Study: Netflx
Typical Reaction to Cockcorft’s Netflix talks
“What Netflix is doing
won’t work” – 2010
“It only works for ‘Unicorns’
like Netflix” – 2011
“We’d like to do that but
can’t” – 2012
Lesson learned from time at Netflix
• Speed wins in the marketplace.
• High trust, low process, teams communicate with each other.
• Freedom & responsibility culture.
• Use simple patterns automated by tooling.
• Don’t do your own “undifferentiated heavy lifting.” (특색없는 노동)
• Self-service cloud makes impossible things instant.

17. 17
MSA Case Study: Netflx
Cockcroft’s Philosophy
Common assumption: Process prevents problems (?)
Organizations build up slow complex “Scar tissue” processes
* Scar tissue: 반흔조직
상해되어 죽은 세포와 그 주변부의 비삼투성 보호물질로 형성된 세포로 구성된 조직.
HR Rules Processes Infra Security

18. 18
MSA Case Study: Process Improvement
Hardware Provisioning
Waterfall Product Dev
IaaS (SW Provisioning)
Agile Product Dev
PaaS
Continuous Delivery
SaaSBetter

19. 19
MSA Case Study: Netflx – Agile style
Agile style development
Email / SMS /
Mobile Push / Phone call
(Bit scary)

20. 20
MSA Case Study: Netflx
Development Cycles
• 4 features / 4 weeks VS 2 features / 2 weeks
Work in Progress = 4
Opportunity for bugs = 100% (baseline)
Time to Debug each = 100% (baseline)
Delivery Complexity = 100% (baseline)
Work in Progress = 2
Opportunity for bugs = 50% (baseline)
Time to Debug each = 50% (baseline)
Delivery Complexity = 100 - 25 = 75%

21. 21
Q&A Session
Questions, comments, feedback, analysis, etc

22. 22
References
1. An Introduction to Service-Oriented Architecture from a Java Developer Perspective
http://archive.oreilly.com/pub/a/onjava/2005/01/26/soa-intro.html
2. Microservices - a definition of this new architectural term
http://martinfowler.com/articles/microservices.html
3. What is Microservices Architecture?
https://smartbear.com/learn/api-design/what-are-microservices/
4. Service-oriented architecture (SOA)
http://www.tridens.si/expertise/soa/
5. Vivat SOA diagram
http://hyperty.com/portfolio/2008/04/04/vivat-soa/
6. Pattern: API Gateway
http://microservices.io/patterns/apigateway.html
7. The introduction to Reactive Programming you've been missing
https://gist.github.com/staltz/868e7e9bc2a7b8c1f754
8. Service Oriented Architecture (SOA)
http://tutorials.jenkov.com/soa/soa.html

23. 23
References
9. Adrian Cockcroft Slideshare
http://www.slideshare.net/adriancockcroft
10. How Nginx Works
https://www.atulhost.com/ngin
11. Cockcroft, the Man Behind Netflix’s Move to AWS, Joins AWS
http://www.datacenterknowledge.com/archives/2016/10/25/cockcroft-the-man-behind-
netflixs-move-to-aws-joins-aws/
12. Adopting Microservices at Netflix: Lessons for Architectural Design
https://www.nginx.com/blog/microservices-at-netflix-architectural-best-practices/
13. The Real Success Story of Microservices Architectures
http://blog.christianposta.com/microservices/the-real-success-story-of-microservices-
architectures/
14. An Introduction to Service-Oriented Architecture from a Java Developer Perspective
http://archive.oreilly.com/pub/a/onjava/2005/01/26/soa-intro.html
15. Why Companies Adopt Microservices And How They Succeed
https://medium.com/microhq/why-companies-adopt-microservices-and-how-they-succeed-
2ad32f39c65a#.o6dl9bl0q