Contenu connexe Similaire à MicroService Architecture (20) MicroService Architecture3. 2004:
1M loc - Largest Certified
J2EE Application
Copyright © 2012 by Fred George. All rights reserved. 3
5. 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
Copyright © 2012 by Fred George. All rights reserved. 5
7. assertNotNull (new Loan(50));
✦ Easy (reasonably) unit test
✦ On Saturday without interruptions
5 hours later, it passed!
Copyright © 2012 by Fred George. All rights reserved. 7
8. 2004:
1M loc - Largest Certified
J2EE Application
“100K loc trying to get out”
Jeff Bay
Copyright © 2012 by Fred George. All rights reserved. 8
9. Why? What Happened?
Sloppy
Lazy?
Technical Debt
No power to refuse!
Inexperienced!
Copyright © 2012 by Fred George. All rights reserved. 9
11. 2005: SOA in Chinese Bank
Cash,
Loans Mortgage Insurance
Balances
Copyright © 2012 by Fred George. All rights reserved. 11
12. 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
Copyright © 2012 by Fred George. All rights reserved. 12
13. 2004: 2005
1M loc - Largest Certified
J2EE Application
“20 5K loc trying to get
out”
“100K loc trying to get out”
Copyright © 2012 by Fred George. All rights reserved. 13
15. 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”
Copyright © 2012 by Fred George. All rights reserved. 15
16. 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
Copyright © 2012 by Fred George. All rights reserved. 16
17. 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
Copyright © 2012 by Fred George. All rights reserved. 17
19. Refined Packet Design
? Addr ? ? ? ?
? ? ? VIN ? ?
Date ? ? ? Name ?
Copyright © 2012 by Fred George. All rights reserved. 19
20. ? 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
Copyright © 2012 by Fred George. All rights reserved. 20
21. 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
Copyright © 2012 by Fred George. All rights reserved. 21
22. 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!
Copyright © 2012 by Fred George. All rights reserved. 22
23. 2004: 2005 2006
1M loc - Largest Certified
J2EE Application
200 500 loc
“20 5K loc trying to get
out”
Copyright © 2012 by Fred George. All rights reserved. 23
25. 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
Copyright © 2012 by Fred George. All rights reserved. 25
26. 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
Copyright © 2012 by Fred George. All rights reserved. 26
27. 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
Copyright © 2012 by Fred George. All rights reserved. 27
33. Legacy System
Web Web
Services Services
ETL/
Biz Biz Data
Muddling
Data Data
Reporting
Copyright © 2012 by Fred George. All rights reserved. 33
34. Cloud of Signals
Email Read
Postcode
Email Address
Name
Postal Address
Server Load
URL Request
Copyright © 2012 by Fred George. All rights reserved. 34
35. 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
Copyright © 2012 by Fred George. All rights reserved. 35
38. 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
Copyright © 2012 by Fred George. All rights reserved. 38
39. What About Technical Debt?
Sloppy
Lazy?
Technical Debt
No power to refuse!
Inexperienced!
Copyright © 2012 by Fred George. All rights reserved. 39
41. 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
Copyright © 2012 by Fred George. All rights reserved. 41
42. “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!
Copyright © 2012 by Fred George. All rights reserved. 42