Betting on Software Architecture as Code a note on hypothesis-driven - - PowerPoint PPT Presentation
Betting on Software Architecture as Code a note on hypothesis-driven architecture James Lewis : @boicy Betting on Software Architecture as Code Software architecture is those decisions which are both important and hard to change Martin
a note on hypothesis-driven architecture
James Lewis : @boicy
“Software architecture is those decisions which are both important and hard to change”
Martin Fowler* * but may have been said earlier by Ralph Johnson (or even by someone in this room!)
“Software architecture is those decisions which are both important and hard to change”
Martin Fowler* * but may have been said earlier by Ralph Johnson (or even by someone in this room!)
Programming language Domain Application Protocol Process Boundaries Integration protocol Hardware Environment Deployment Topology
What happens if these properties become easy to change?
“Software architecture is those decisions which are both important and hard to change”
Martin Fowler* * but may have been said earlier by Ralph Johnson (or even by someone in this room!)
Programming language Domain Application Protocol Process Boundaries Integration protocol Hardware Environment Deployment Topology
How do we usually make decisions about these things?
based on experience based on gut feel and often times up front
Can we make decisions more systematically?
and what would that look like?
more cheaply
History
The lawful good product owners of the publishing house had long lived in awe and fear of their publishing systems. In awe, for they had made a tremendous amount of Gold, but in fear of the time taken to change them, their slowness and their fragility. A messenger was sent to fetch help from a distant land famed for it’s mighty wizards. You have taken up the challenge…
link to close link hello close
1.
You must save the product owners by rebuilding their website. You start off the project. In the course of discussions you discover that your goals are three fold:
An Enterprise Architect approaches and addresses you. You may use:
Summon Walking Skeleton
turn to 4 Analysis Paralysis turn to 3
If you have none of these you will have to draw your sword and fight (turn to 178)
link to close link hello close
CFR maturity model
We’ve never heard of this…
We know what it is but don’t have any understanding of the requirements for the project
We have defined specific requirements related to this risk / area
We are able to give numbers, or other specific information that enables us to measure if we are fulfilling the requirements
We can demonstrate to you through automated / manual tests or otherwise that we have satisfied the requirements for this area of risk
CFR maturity model
High Low Low High Impact Maturity I like to have this as a BVC on the wall (postits natch)
Akamai AWS DAYTON Article Store S3 Article Rendering Preference Service Usage Service Entitlements Customer Related Content Recommendations science/article/pii/ <id> Session Usage A&E Chief Scopus HPCC PDF Store Content Metadata FAST search Search REST REST REST REST REST REST REST SOAP REST ASYNC REST REST REST REST REST REST REST REST
We started off thinking it would look a bit like this
1.
You must save the product owners by rebuilding their website. You start off the project. In the course of discussions you discover that your goals are three fold:
An Enterprise Architect approaches and addresses you. You may use:
Summon Walking Skeleton
turn to 4 Analysis Paralysis turn to 3
If you have none of these you will have to draw your sword and fight (turn to 178)
link to close link hello close
3.
You cast Analysis Paralysis at the Enterprise Architect. “Foolish young adventurer” says the architect, “we follow the evolutionary school of architecture and we shall have none of the lawful-evil ways of waterfall”. The last thing you see before everything goes dark is the architect incanting in a strange voice. You have died. Turn to page 1.
link to close link hello close
1.
You must save the product owners by rebuilding their website. You start off the project. In the course of discussions you discover that your goals are three fold:
An Enterprise Architect approaches and addresses you. You may use:
Summon Walking Skeleton
turn to 4 Analysis Paralysis turn to 3
If you have none of these you will have to draw your sword and fight (turn to 178)
link to close link hello close
4.
Your walking skeleton coalesces in a cloud of noxious gasses and solidifies as a java dropwizard application. You reach into your backpack and deploy the content store. Your walking skeleton reaches out it’s skeletal arms and grabs armfuls of raw xml. Would you like to:
S3
Transform the xml inside the skeleton turn to 6 Use a magic box turn to 5
link to close link hello close
monolithic MVC
transformations and rendering happen in process distributed system Transform content within the walking skeleton create another service to transform content
Option Option Option $ $ $ Evolutionary Architecture allows us to place small bets and then re- evaluate our decisions based on outcomes Option Option Option $ $$$$$$$$$ $ Up front design “bets the house”. It collapses the options by presupposing the answer (and that there is an answer)
Back to 1961…
What did the Gantt chart for the Apollo moon landing program look like?
Design Saturn V Build Saturn V
Launch
Land
Tea and biscuits*
Zoom through space
May 25th, 1961 18th July, 1969
*blocks not to scale apart from tea and biscuits
What did the Gantt chart for the Apollo moon landing program look like?
President Kennedy’s speech tea and biscuits
Can humans survive in space for long enough to get to the moon (and back!)? Can we dock a spacecraft with another? Can we even get to the moon? How do we get the returning spacecraft to land at a pre selected location? What the heck are we going to find when we are there? Is it safe to land on the surface?
Ranger 1, launched 23 August 1961, lunar prototype, launch failure Ranger 2, launched 18 November 1961, lunar prototype, launch failure Ranger 3, launched 26 January 1962, lunar probe, spacecraft failed, missed Moon Ranger 4, launched 23 April 1962, lunar probe, spacecraft failed, impact Ranger 5, launched 18 October 1962, lunar probe, spacecraft failed, missed Ranger 6, launched 30 January 1964, lunar probe, impact, cameras failed Ranger 7, Impacted Moon 31 July 1964 at 13:25:49 UT Ranger 8, Impacted Moon 20 February 1965 at 09:57:37 UT Ranger 9, Impacted Moon 24 March 1965 at 14:08:20 UT Ranger missions (1961 - 1965) Can we even get to the moon?
Gemini missions (1962 - 1966) How long can humans survive in space? Can we dock one spacecraft with another? How do we get the returning spacecraft to land at a pre selected location?
Surveyor missions (1962 - 1966) Is it safe to land on the surface?
What did the Gant chart* for the Apollo moon landing programme look like?
Design Saturn V Build Saturn V
Launch
Land
Tea and biscuits
Zoom through space
May 25th, 1961 18th July, 1969
*blocks not to scale X
Back to 1945…
“He (General Groves) had to begin building before he knew precisely what to build. He worked from the general to particular, from outline to detail.”
gaseous diffusion EM separation
Forward to 2011…
How to land on Mars? How to test
What do these great endeavours have in common? High Risk (losing people, losing a war, losing a billion dollar lander) Putting a person on the moon (and getting them home!): Multiple parallel streams of work, rapid experimentation to solve individually identified problems Hard to test (don’t want to lose people, can’t use redundancy, new science) Curiosity: Simulations, Models Manhattan: Concurrent set based engineering, working with imperfect information, simulations, models (monte carlo came from Los Alamos)
to overcome seemingly insurmountable obstacles they created options and ran experiments
All of these are examples of creating options placing bets for only the money we can afford to lose which is a great risk reduction technique But it actually gets better than that. Because options have value
Black–Scholes 𝜏 term is volatility - traders like volatility
‘10 ‘11 ‘12 ‘13 ‘14 ‘15 ‘16
DVCS JS as a first class language CD, EA, ED, build pipelines Google Wave Git in trial Clojure, Scala Neo4J, Mongo, Triple Stores CD, EA, ED, Polyglot dev Azure off Hold Visualisation & metrics NoSql JVM as a Platform Using basic web techniques effectively Diversity and depth in Cloud Focus on CD and tools to deliver it New approaches to BI Simple techniques for performance testing Better tools for dev and test of Mobile Smaller, simpler faster applications and services Increasing diversification and rigour in browser based languages Treat all code with respect (from UI to tests) Continued development of SQL alts Data persistence done right Reproducible environments Simple Architectures Accessible analytics Mobile (!) Infrastructure as code Lightweight options for analytics Applying proven practices to areas that missed them Falling boundaries and perimeterless enterprise Merging of Physical and Digital The JS juggxrnaught rolls on Privacy and big data Early warning and recovery in prod Churn in the JS world Conway’s Law Microservices and the rise of the API Redecentralisation Devs focus on security minded tooling Next gen data platforms gain traction (ML) Explosive growth in the Devops arena Security struggles continue in the enterprise A new wave of openness at Microsoft Innovation in architectures (ms and cloud native) Security is everybody’s problem JS tooling settles to merely chaotic Microservices and related tools continue to gain in popularity Docker incites container explosion Over Reactive? DOCKER! DOCKER! DOCKER! Parsing the PaaS puzzle OSS as a virtuous by product
‘17
Microservices as programming model Intelligent Empowerment Holistic effect of team structure AR and VR easing to mainstream Conversational UI and natural language Intelligence as a Service Developer experience as differentiator Rise of the Platforms Pervasive Python
So by creating options we not only reduce risk but also take advantage of volitility
5.
You throw the magic box in between the walking skeleton and the content store. A villager approaches and exclaims: “this beautiful content I see in front
time to get here” You must somehow make the content arrive faster. If you have a http cache in your inventory, you may use it now.
S3
Cache in between S3 and content turn to 10
content
Cache in between skeleton and content turn to 33
link to close link hello close
ESI / Templating
Computationally expensive service
XML in S3 Xslt
0.8 seconds for first byte 1.5 seconds for page load
Page Load (sec) 10 20 30 40 Initial observations 1 35
0.8 seconds for first byte 1.5 seconds for page load
ESI / Templating
Computationally expensive service
XML in S3 Xslt
We’ve detected performance problems
ESI / Templating
Computationally expensive service
XML in S3 Xslt
ESI / Templating
Computationally expensive service
XML in S3 Xslt
Page Load (secs)
Cache misses predominate
Page Load (secs)
Cache hits predominate
There are only two hard things in Computer Science: cache invalidation and naming things.
Bonus Joke
There are only two hard things in messaging:
a note on hypothesis-driven architecture
a note on hypothesis-driven architecture
“In general, we look for a new law by the following process: First we guess it; then we compute the consequences of the guess to see what would be implied if this law that we guessed is right; then we compare the result of the computation to nature, with experiment or experience, compare it directly with
it is wrong. In that simple statement is the key to science. It does not make any difference how beautiful your guess is, it does not make any difference how smart you are, who made the guess, or what his name is — if it disagrees with experiment, it is wrong”
How do we decide what bets to place?
Compute implications Compare with Nature Draw conclusion Observe nature Make a guess
Compute implications Compare with Nature Draw conclusion Observe nature Make a guess
Observe metrics Measure results Was I right? Make a small change Guess
Compute implications Compare with Nature Draw conclusion Observe nature Make a guess
Lightweight probes Ability to quickly deploy small changes Observable systems A brain
practices that enable small bets* *not exhaustive
Instrumentation Telemetry Visualisation Alerting Predictive alerting
Our code and hardware describes what it’s doing We have a way of gathering the data from our services We can meaningfully visualise our systems behaviour We can take action based on this information We can predict in advance when something may go wrong
credit: Dan North
Service Service request latency downstream dependencies OS metrics health request tracing
Codahale Metrics Dropwizard Tenacity Circuit Breakers Breaker Box Yammer Chaos Monkey
Safely and sustainably reduce lead time to value
Compute implications Compare with Nature Draw conclusion Observe nature Make a guess
https://puppet.com/resources/whitepaper/state-of-devops-report
https://puppet.com/resources/whitepaper/state-of-devops-report
ApacheBench
ab -n 100 -c 10 “http://sciencesite.com/articles/9dfa1ae0-6ba5-4f2f-…”
Siege Vegeta
echo "GET http://sciencesite.com/“ | vegeta attack -duration=60s -rate=10
Cloud native infrastructure as code
Other techniques are incredibly useful for these experiments Canary Releases
Other techniques are incredibly useful for these experiments Phoenix environments svc svc svc svc svc svc svc svc prod prod Canary Releases
Other techniques useful patterns Canary Releases Phoenix environments Blue / Green deploys
Production != Live Canary Releases Phoenix environments Blue / Green deploys
Compute implications Compare with Nature Draw conclusion Observe nature Make a guess
Lightweight probes Ability to quickly deploy small changes Good monitoring A brain
Page Load (sec) 10 20 30 40 Initial observations 1 35
0.8 seconds for first byte 1.5 seconds for page load
Option: Add CPU Option: Cache S3 content Option: Cache Service content
Compute implications Compare with Nature Draw conclusion Observe nature Make a guess XSLT can be expensive - maybe we are CPU bound Increasing the # of CPU’s could help
Page load (sec) 10 20 30 40 After adding more CPU’s 1 2 35 6
Second Guess: Moving compute to the data
Page load (sec) 10 20 30 40 Move closer to the data 1 2 3 35 6 4
Third Guess: Transformations are slow and could be optimised
Page load (sec) 10 20 30 40 Tune xslt transforms 1 2 3 4 35 6 4 3.5
Final Guess: And, cache
ESI / Templating
Computationally expensive service
XML in S3 Xslt
Page load (sec) 10 20 30 40 After adding a cache 1 2 3 4 5 35 6 4 3.5 0.2
Do we add a cache? create another service to transform content
saves the fetch from S3 saves the xslt transform time saves the fetch from S3 Cache in front of content service Cache in front of S3
150.
Content trickles into the store. You keep up by listening for the new content and casting “wget” on the cache to keep it refreshed. New types of content appears - content the villagers have never seen
is unable to combat. Every time the structure of the content changes, the cache must be
grows until it is the size of the Great Wahui of Berathorob. It is no longer possible to refresh it. Latency increases.
link to close link hello close
You have died. Turn to page 1.
Cache in front of S3 Cache in front of content service
10.
The cache causes the content load times to drop from 300ms to 150ms. The villager says “this wonderful content is now arriving more swiftly than even the knight-messengers of the Empress”. The villagers are happy but all too soon, all is not well for the content has a long tail. You must work out how to refresh the content when it changes. You can either:
Refresh the content when it appears from the ether turn to 150 Trust that it will be fast enough on first view turn to 22
link to close link hello close
4.
Your walking skeleton coalesces in a cloud of noxious gasses and solidifies as a java dropwizard application. You reach into your backpack and deploy the S3 content store. Your walking skeleton reaches out it’s skeletal arms and grabs armfuls of raw xml. Would you like to:
Transform the xml inside the skeleton turn to 6 Use a magic box turn to 5
Real Options, Small Bets
rapidly change all the things
Cloud Native, CD for infra
run experiments
lightweight probes for fun and profit
instrumentation, telemetry, visualisation
Evolutionary Architecture keeps our options open Continuous Delivery, lean product engineering and Infrastructure as Code reduce the amount of money we need to place a bet (so we can place more) Lightweight experiments allow us to make guesses and test our hypotheses
James Lewis : @boicy
GNU Terry Pratchett