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

More Related Content

What's hot (20)

Viewers also liked (9)

Similar to MicroService Architecture (20)

More from Fred George (9)

MicroService Architecture