MicroService Architecture

µService Architecture:
A Personal Journey of Discovery

Fred George
fredgeorge@acm.org
@fgeorge52

Copyright © 2012 by Fred George. All rights reserved. 1

In the Beginning...


2004:
1M loc - Largest Certified
J2EE Application


It Started
Well...
Martin Fowler
consulted, then
joined ThoughtWorks

Copyright © 2009 by Fred George 4

What I Found in 2004

✦ 1M locs
✦ 2,000 tests
✦ 70% success rate on Acceptance Test was Acceptable
✦ Bug database with over 1000 entries
✦ Still being changed
✦ New tests almost non-existent


Unit Test Counts


assertNotNull (new Loan(50));

✦ Easy (reasonably) unit test
✦ On Saturday without interruptions

5 hours later, it passed!

2004:
J2EE Application

“100K loc trying to get out”
Jeff Bay


Why? What Happened?
Sloppy
Lazy?

Technical Debt
No power to refuse!
Inexperienced!


Evolution...


2005: SOA in Chinese Bank
Cash,
Loans Mortgage Insurance
Balances


Solution: Pub/Sub

e d
✦ Events “published”

c t
✦

✦
Interested applications “subscribe”

j e
Applications then “publish” interaction requests
✦

R e
UI elements render appropriate interactions


2004: 2005
J2EE Application

“20 5K loc trying to get
out”

“100K loc trying to get out”

2005: Medical Systems

Information “Nuggets”


From: CAT Scan

About: Jane Doe

e d
Urgency:
Time:
23 Apr 2012
20:13:45
Concern
c t Summary

Validity:
26 Apr 2012
20:13:45

j e Only relevant
until...

R e Information “Nuggets”


2005: Services for
Investment Management
p e
✦ Prototyping new system architecture

t y
o
✦ Baysian Service Principles (Jeff Bay)

t
✦ It’s okay to run more than one version at the same
time

✦
✦

r o
You can only deploy one service at a time
Decoupling result: Deploying 3 times a day!

P

2006: Batch Processing
Replacement Orders

✦ Client needed to replace parts on cars
✦ Many variations based on car, location of car
✦ Vendor estimated 15- months
18
✦ Unacceptable to business


2006: Batch Processing
Replacement Orders


Refined Packet Design

? Addr ? ? ? ?

? ? ? VIN ? ?

Date ? ? ? Name ?


? Addr ? ? ? ?

d
Join Table

e
•Need VIN
•Need zzz
•Inject aaa
r ks
e e
v e
i w
•Need Addr
•Inject Name

l
e 9
D •Need Name
•Need rrr
•Inject VIN

i n

New Observations and
Revelations
✦ Services are like Classes
✦ Small, crisp conceptualization
✦ Services got very tiny (100 loc)
✦ Smalltalk message passing perfect for services
✦ Encapsulation
✦ Database segregated among services w/o sharing
✦ Service publishes conclusions, not raw data


New Problems and
Challenges
d ?
✦ “WTF is going on ?”

r e
✦

✦
Cycles, lost packets
Needed to redefine tracking, logging

v e
✦ Inexperienced team in defining services
✦

l
Approach compromised in Release 2 i
✦

D e
Won award at TW Tech Day... for being a bad idea!


2004: 2005 2006
J2EE Application
200 500 loc
“20 5K loc trying to get
out”


Experiences at...


2007: Forward Needs to
Monitor AdWords Accounts
e d
t
✦ Pub/sub model based on Linda Spaces (tuples)
Segregate databases to services

c
✦

Define agent services for each user

e
✦

Start to automate activities and recommendations

j
✦

✦ Off-shore for implementation
✦

✦
solution R e
CTO killed it (former Oracle executive)
Replaced with a more traditional, SQL DB-driven


2008: CardWall

e d
✦ Front-end automated Card Wall in Agile
e r
✦ Back-end emerged as a set of services analyzing data

i v
l
✦ One service, one role

✦
✦

D
Migrated to Hadoop Cluster as it grew e
Post alerts (with recommendations) to users


New Observations and
Revelations
✦ Services became disposable
✦ Loosely coupled via RESTful Json packets or DB
✦ Albeit still knowledgeable about flow
✦ Self-monitoring services replaces Unit Tests
✦ Business monitoring replaces Acceptance Tests
✦ Services language-agnostic


Current State...


Design: Events, not Entities


Design: History, not Current


Legacy System
Web Web
Services Services
ETL/
Biz Biz Data
Muddling
Data Data

Reporting


Cloud of Signals
Email Read
Postcode

Email Address
Name
Postal Address

Server Load
URL Request

Data Ecosystem
Producers Kafka Consumers
Postal Address
App R
App
Hive
Service Email Address
Monitoring
Web Server URL Request
Apps/
3rd Party Services
Name
Web Hooks


Cross-sell Tracking


User Paths Through Site


Agile Best Practices Not Used
Trust w
✦ Stand ups collocation ✦ Unit tests
✦ Story narratives ✦ Acceptance tests
Small,
✦ Retrospectives ✦ Refactoring
short-lived
✦ Estimates ✦ Patterns apps
Results,
✦ Iterations not blame ✦ Continuous integration
✦ Mandatory pairing Continuous
deployment


What About Technical Debt?
Sloppy
Lazy?

Technical Debt

No power to refuse!
Inexperienced!


Conclusions (so far)...


Summary Principles of
µServices
✦ Very, very small
✦ Loosely coupled (including flow)
✦ Multiple versions acceptable (encouraged?)
✦ Self-execution monitoring of each service
✦ Publish interesting “stuff” (w/o requirement)
✦ “Application” seems to be poor conceptualization


“Living Software” System
✦ Long-lived system; short-lived services (human body)
✦ Extremely dynamic with continuous deployments
✦ 5- minutes between deployments typical
10
✦ Accept it is complex (especially for testing)
✦ Acceptance test on business outcomes instead
✦ Radical impact to processes (Anarchy)
✦ There will be a learning curve for developers!


µService Architecture:
A Personal Journey of Discovery

Fred George
fredgeorge@acm.org
@fgeorge52


MicroService Architecture

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (9)

Similar to MicroService Architecture

Similar to MicroService Architecture (20)

More from Fred George

More from Fred George (9)

MicroService Architecture