Get Loose! Microservices and Loosely Coupled Architectures

© Electric Cloud | electric-cloud.com | @electriccloud
A DevOps.com webinar featuring Jez Humble and Anders Wallgren
Get Loose! Microservices and Loosely
Coupled Architectures

Speakers
Jez Humble
CTO, DORA. Author.
@jezhumble
Anders Wallgren
CTO, Electric Cloud
@anders_wallgren
/ @electriccloud - #ecwebinar

Agenda
• What does the 2017 State Of DevOps Report
say about high-performers and loose
coupling?
• Why are Microservices a great choice for
creating loosely coupled systems?
• What are useful strategies to decompose,
test, deploy, and release mono+micro apps,
safely.

Polling Question

Predictors of DevOps Performance
Jez Humble

Who took the survey
6

High-performing teams continue to
achieve both faster throughput and
better stability.

8

9

10

Relationship between transformational leadership and
performance
11

High performing organizations are twice as likely to
achieve or exceed goals
12
Non-commercial Goals
• Quantity of products or services
• Operating efficiency
• Customer satisfaction
• Quality of products or services
provided
• Achieving organizational and
mission goals
Commercial Goals
• Productivity
• Profitability
• Market Share
• # of customers

13
Loosely coupled architectures and
teams are the strongest predictor of
continuous delivery.

Architectural outcomes: can my team…
14
• …make large scale changes to the design of its system without the
permission of someone outside the team, or depending on other teams?
• ...complete its work without fine-grained communication and
coordination with people outside the team?
• ...deploy and release its product or service on demand, independently
of other services the product or service depends upon?
• ...do most of its testing on demand, without requiring an integrated test
environment?
• ...perform deployments during normal business hours with negligible
downtime?

Conway’s Law
“organizations which design systems … are constrained
to produce designs which are copies of the
communication structures of these organizations”

16
Lean product management drives
higher organizational performance.

Lean Product Management Practices
17
• Working in small batches
• Making the flow of work visible through the
process
• Gathering, broadcasting and implementing
customer feedback
• Ability of teams to try out new ideas and
create and update specifications during the
development process

Get your copy of the
2017 State of DevOps Report
puppet.com/state-of-devops-report

Microservices: A Primer

Microservices
A suite of services, each focused on
doing one thing well
• Running in its own process
• Exposing an API
• Independently developed
• Independently deployable
Very useful when building loosely
coupled systems.
“Gather together those
things that change for the
same reason, and separate
those things that change
for different reasons.”
– Robert Martin

What’s cool about Microservices?
Divide and conquer
complex distributed
applications
Loose coupling
Makes it easier to adopt
new technologies
Smaller more autonomous teams
are more productive – better
resource utilization

Monolithic Apps
The good, the bad, the ugly…
Pros
• Can be easier to develop
• Can be easier to test
• Can be easier to deploy
Cons
• Easier to produce spaghetti code
• Can be harder to integrate new technologies
• Can be harder to learn and understand the code
• You have to scale everything to scale anything
• Can’t deploy anything until you deploy everything

So…Was Fred Brooks Wrong?
NO, but….
A properlyconstructed
microservices architecture
makes it vastly easier to scale
teams and scale applications
https://puppetlabs.com/2015-devops-report-ppc

How do I know if Microservices are right… for me??
• If you already have solid CI, automated
testing, and automated deployment, and
you’re looking to scale, then maybe
• Don’t decompose prematurely
• Are you good at provisioning?
• Are you good at deployment?
• Are you good at monitoring?
• Do you have good domain/system
comprehension?
http://martinfowler.com/bliki/MicroservicePrerequisites.html

Design Considerations For Microservices
• Loose coupling
• A change to service A shouldn’t require a change
in service B
• Small, tightly focused API
• High cohesion
• Each service should have a specific responsibility
• Domain-specific behavior should be in one place
• If you need to change a behavior, you shouldn’t
have to change multiple services

What’s difficult about Microservices?
• Distributed Systems Are Hard
• State management – transactions, caching, and
other fun things
• Team-per-service or Silo-per-service? + Conway’s
Law
• Legacy apps: Rewrite? Ignore? Hybrid?
• Good system comprehension is key
• Your service might be small, but how large is its
deployment footprint?

Get Loose! Best Practices For
Decomposing The Monolith

Decomposing (“eroding”) the monolith
• Be Agile in your efforts. Fowler’s Strangler Pattern.
• You’ll probably get it wrong the first time.
• Look for seams – areas of code that are independent,
focused around a single business capability
• Look for areas of code that change a lot
• Don’t ignore organizational structure (Conway’s Law)
• Domain-Driven Design (Domain Contexts) are useful
• Dependency analysis tools help, but are no panacea
• Yegge's rant

Decomposing the monolith’s data
• RDBMS may well be your largest sourceof coupling
• Understand yourschema
• Foreign key constraints
• Shared mutable data
• Transactional boundaries
• Is eventual consistency OK?
• Avoid distributed transactions if possible
• Split data beforeyou split code
• Do you need an RDBMS at all or can you use NoSQL?

Does Size Matter?
• The smaller the services, the more
potential decoupling benefit
• Be warned - the smaller the services,
the more moving parts you will have
• You should be able to (re-)rewrite one
service in a “small” number of weeks
• If you can’t update a service without
changing other things, it’s too large

What about testing?
• Spend the time where you need but no
more than necessary
• Use service virtualization / stubbing /
mocking
• Consider using a single pipeline for end-
to-end tests
• Performance testing at the service level
is more important than in a monolith
• As always, flaky tests are the devil

What about environments & deployment
• Automate all the things!
• Ensure fidelity of env’s throughout the pipeline
• One service per host
o Minimize the impact of one service on others
o Minimize the impact of a host outage
• Use VMs/containers to make life easier
o Containers map very well to microservices
o “Immutable servers”
• PaaS solutions can help, but can also constrain

What about our Release Pipeline?
• Automate and Orchestrate all the things!
o Ideally, one platform for all software delivery (CD and
legacy, cloud, container)
• Govern the promotion of all the things!
o Understand pipeline and release statuses and any
dependencies or exceptions
• Make pipeline tools/environment agnostic
o Support each team’s workflow and tool chain
• One repository per service
o Independent CI and Deployment pipelines per
service

What about our Release Pipeline (cont’d)?
• Enable self-service automation
o Standardize and operationalize to reduce
onboardingtime, waiting, complexity
• Monitor early and often
o Set up alerting; trigger automatic processes
(service rollback, scaling, etc)
• Track artifacts through the pipeline
o Who checked-in the code, test coverage and
quality, environments deployed to,
configurations used, approvers,etc)
• Assure security compliance
o Include security checks, acceptance tests
o Allow for both automatic and manual approval
gates

Should I optimize for MTTR or MTBF?
• There is a point of diminishing returns with testing
(especially end-to-end testing)
• You may be better off getting really good at
remediating production problems
o Monitoring
o Very fast rollforward/rollback
o Blue/green deployments
o Canary deployments
• Not all services have the same durability
requirements

Things to look out for: Monitoring

Closing Thoughts on Loosely Coupled Systems
• It isn’t necessarily easier to do it this way…
• Services will evolve over time (you’ll split, re-merge…).
• Design for resiliency (e.g, use Hystrix from Netflix)
• Focus on centralized system visibility and reporting
• “The network is reliable” (and the rest of the 8 fallacies)
• “But my service relies on ServiceA vX -- now I’m down”
• Consider event-based techniques to decrease coupling
• Consistently log & monitor services

Thank You
Telecom/Networking
Other Systems
ISV, Internet
& Entertainment
Heavy Industry
Financial
Services
Automotive Medical Devices
Semiconductor
Aerospace /
Defense
Mobile Devices
Q&A

Resources
• http://www.infoq.com/presentations/Breaking-the-
Monolith
• http://martinfowler.com/tags/microservices.html
• http://www.amazon.com/Building-Microservices-Sam-
Newman/dp/1491950358
• http://highscalability.com/blog/2014/7/28/the-great-
microservices-vs-monolithic-apps-twitter-melee.html

Get Loose! Microservices and Loosely Coupled Architectures

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Get Loose! Microservices and Loosely Coupled Architectures

Similar to Get Loose! Microservices and Loosely Coupled Architectures (20)

More from Deborah Schalm

More from Deborah Schalm (20)

Recently uploaded

Recently uploaded (20)

Get Loose! Microservices and Loosely Coupled Architectures