Due to the demands of our hyper-connected, Internet-driven economy, users expect speedy delivery of new features, highly engaging personalized user experiences, and smooth, streamlined performance. The result is that best practices for application development and architecture are rapidly changing.
Traditional approaches to development are no longer competitive, with the new focus on simplicity, usability, and large-scale DevOps agility. In order to thrive, development teams must adjust to deliver high-quality applications fast.
This keynote will discuss:
The traditional monolith application vs. the modern application.
Architectural considerations for the modern application.
How trends such as DevOps and microservices affect application design.
Tools, technologies, and techniques for building modern applications.
Session at the IndicThreads.com Confence held in Pune, India on 27-28 Feb 2015
http://www.indicthreads.com
http://pune15.indicthreads.com
19. Disadvantages of
Monolith Application
• Difficult to deploy and maintain
• Obstacle to frequent deployments
20. Disadvantages of
Monolith Application
• Difficult to deploy and maintain
• Obstacle to frequent deployments
• Makes it difficult to try out new technologies/
framework
22. –Martin Fowler
“building applications as suites of services. As well as
the fact that services are independently deployable
and scalable, each service also provides a firm module
boundary, even allowing for different services to be
written in different programming languages. They can
also be managed by different teams”
http://martinfowler.com/articles/microservices.html
28. –Melvin Conway
“Any organization that designs a system
(defined more broadly here than just information
systems) will inevitably produce a design
whose structure is a copy of the
organization's communication structure.”
http://www.melconway.com/Home/Committees_Paper.html
33. “you build it, you run it!”
With great
power, comes great
responsibility
Characteristics
34. Designed for failure
Fault tolerance is a requirement, not a feature
http://techblog.netflix.com/2012/02/fault-tolerance-in-high-volume.html
Characteristics
44. Strategies for decomposing
• Verb or usecase - e.g. Checkout UI
• Noun - e.g. Catalog product service
• Single Responsible Principle - e.g. Unix utilities
69. Advantages of
microservices
• Easier to develop, understand, maintain
• Starts faster than a monolith, speeds up deployments
• Local change can be easily deployed, great enabler of CD
70. Advantages of
microservices
• Easier to develop, understand, maintain
• Starts faster than a monolith, speeds up deployments
• Local change can be easily deployed, great enabler of CD
• Each service can scale on X- and Y-axis
71. Advantages of
microservices
• Easier to develop, understand, maintain
• Starts faster than a monolith, speeds up deployments
• Local change can be easily deployed, great enabler of CD
• Each service can scale on X- and Y-axis
• Improves fault isolation
72. Advantages of
microservices
• Easier to develop, understand, maintain
• Starts faster than a monolith, speeds up deployments
• Local change can be easily deployed, great enabler of CD
• Each service can scale on X- and Y-axis
• Improves fault isolation
• Eliminates any long-term commitment to a technology stack
73. Advantages of
microservices
• Easier to develop, understand, maintain
• Starts faster than a monolith, speeds up deployments
• Local change can be easily deployed, great enabler of CD
• Each service can scale on X- and Y-axis
• Improves fault isolation
• Eliminates any long-term commitment to a technology stack
• Freedom of choice of technology, tools, frameworks
74. “If you can't build a [well-structured]
monolith, what makes you think
microservices are the answer?”
http://www.codingthearchitecture.com/2014/07/06/distributed_big_balls_of_mud.html
77. Drawbacks of microservices
• Additional complexity of distributed systems
• Significant operational complexity, need high-level
of automation
78. Drawbacks of microservices
• Additional complexity of distributed systems
• Significant operational complexity, need high-level
of automation
• Rollout plan to coordinate deployments
79. Drawbacks of microservices
• Additional complexity of distributed systems
• Significant operational complexity, need high-level
of automation
• Rollout plan to coordinate deployments
• Slower ROI, to begin with
80.
81. “Devs” job is to add new features
“Ops” job is to keep the site stable and fast
35
82. “Ops” job is NOT to keep the site stable and fast
36
83. “Ops” job is NOT to keep the site stable and fast
“Ops” job is to enable business
36
84. “Ops” job is NOT to keep the site stable and fast
“Ops” job is to enable business
And so is “devs”
36
95. Five “C”s of DevOps
• Collaboration between “dev” and “ops”
96. Five “C”s of DevOps
• Collaboration between “dev” and “ops”
• Culture
97. Five “C”s of DevOps
• Collaboration between “dev” and “ops”
• Culture
• Code everything - application and configuration
98. Five “C”s of DevOps
• Collaboration between “dev” and “ops”
• Culture
• Code everything - application and configuration
• Consistency - automation over documentation
99. Five “C”s of DevOps
• Collaboration between “dev” and “ops”
• Culture
• Code everything - application and configuration
• Consistency - automation over documentation
• Continuous delivery
130. Initial Managed Defined
Quantitatively
Managed
Optimizing
Culture &
Organization
• Teams organized
based on platform/
technology
• Defined and
documented
processes
• One backlog per
team
• Adopt agile
methodologies
• Remove team
boundaries
• Extended team
collaboration
• Remove boundary dev/
ops
• Common process for all
changes
• Cross-team continuous
improvement
• Teams responsible all the way to
production
• Cross functional teams
Build & Deploy
• Centralized version
control
• Automated build
scripts
• No management of
artifacts
• Manual deployment
• Environments are
manually provisioned
• Polling CI builds
• Any build can be
re-created from
source control
• Management of
build artifacts
• Automated
deployment scripts
• Automated
provisioning of
environments
• Commit hook CI builds
• Build fails if quality is not
met (code analysis,
performance, etc.)
• Push button deployment
and release of any
releasable artifact to any
environment
• Standard deployment
process for all
environments
• Team priorities keeping
codebase deployable over
doing new work
• Builds are not left broken
• Orchestrated deployments
• Blue Green Deployments
• Zero touch Continuous
Deployments
Release
• Infrequent and
unreliable releases
• Manual process
• Painful infrequent
but reliable
releases
• Infrequent but fully
automated and reliable
releases in any
environment
• Frequent fully automated
releases
• Deployment disconnected from
release
• Canary releases
• No rollbacks, always roll
forward
Data
Management
• Data migrations are
performed manually,
no scripts
• Data migrations
using versioned
scripts, performed
manually
• Automated and
versioned changes to
datastores
• Changes to datastores
automatically performed as part
of the deployment process
• Automatic datastore
changes and rollbacks
tested with every
deployment
Test &
Verification
• Automated unit tests
• Separate test
environment
• Automatic
Integration Tests
• Static code
analysis
• Test coverage
analysis
• Automatic functional
tests
• Manual performance/
security tests
• Fully automatic acceptance
tests
• Automatic performance/security
tests
• Manual exploratory testing
based on risk based testing
analysis
• Verify expected business
value
• Defects found and fixed
immediately (roll forward)
Information &
Reporting
• Baseline process
metrics
• Manual reporting
• Visible to report
runner
• Measure the
process
• Automatic reporting
• Visible to team
• Automatic generation of
release notes
• Pipeline traceability
• Reporting history
• Visible to cross-silo
• Report trend analysis
• Real time graphs on deployment
pipeline metrics
• Dynamic self-service of
information
• Customizable dashboards
• Cross-reference across
organizational boundaries