Changing application demands: What developers need to know

Changingapplicationdemands

What developers need to know

Arun Gupta, @arungupta Red Hat

Arun Gupta Director, Developer Advocacy

@arungupta blog.arungupta.me [email protected]

Monolith Application

UI Database

Business Logic


UI Database

Business Logic

HTMLHTMLHTML

CSSCSS

HTMLHTMLCDIHTMLHTMLREST

HTMLHTMLJSF

HTMLHTMLJPA Cache

DB


UI Database

Business Logic

HTMLHTMLHTML

CSSCSS

HTMLHTMLCDIHTMLHTMLREST

HTMLHTMLJSF

HTMLHTMLJPALoad

BalancerCache

DB


EARWAR

LoadBalancer WARWAR

JARJARJARJAR


EARWAR

LoadBalancer WARWAR

JARJARJARJAR

Cache

DB

Advantages of Monolith Application


• Typically packaged in a single .ear



• Easy to test (all required services are up)



• Easy to test (all required services are up)

• Simple to develop

Monolith ApplicationUI Database

Business Logic

HTMLHTML

HTMLHTML HTMLHTML HTMLHTML

HTMLHTML

Version 1


Business Logic

HTMLHTML


HTMLHTML

Version 1

UI Database

Business Logic

HTMLHTML


HTMLHTML

Version 2


Business Logic

HTMLHTML


HTMLHTML

Version 1

UI Database

Business Logic

HTMLHTML


HTMLHTML

Version 2

UI Database

Business Logic

HTMLHTML


HTMLHTML

Version 3


Business Logic

HTMLHTML


HTMLHTML

Version 1

UI Database

Business Logic

HTMLHTML


HTMLHTML

Version 2

UI Database

Business Logic

HTMLHTML


HTMLHTML

Version 3

UI Database

Business Logic

HTMLHTML


HTMLHTML

Version 4

Disadvantages of Monolith Application


• Difficult to deploy and maintain



• Obstacle to frequent deployments



• Obstacle to frequent deployments

• Makes it difficult to try out new technologies/framework

http://akfpartners.com/techblog/2008/05/08/splitting-applications-or-services-for-scale/

–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

http://martinfowler.com/articles/microservices.html

UI

Business Logic

Persistence

Characteristics of microservices

👱 🙍🙍👱👱

👱 🙍🙍👱👱

👱 🙍🙍👱👱

UI

Business Logic

Persistence

Orders

Shipping

Catalog

Characteristics of microservices

👱 🙍🙍👱👱

👱 🙍🙍👱👱

👱 🙍🙍👱👱

–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

http://www.melconway.com/Home/Committees_Paper.html

Teams around business capability

Orders

👱 🙍🙍👱👱

Shipping

👱 🙍🙍👱👱

Catalog

👱 🙍🙍👱👱

Characteristics

Explicitly Published interfaceCharacteristics

Independently replaceable and upgradeable

Characteristics

Characteristics

“you build it, you run it!”

With great power, comes great

responsibility

Characteristics

Designed for failure

Fault tolerance is a requirement, not a feature

http://techblog.netflix.com/2012/02/fault-tolerance-in-high-volume.html

Characteristics

Characteristics

100% automatedCharacteristics

Sync or Async MessagingCharacteristics

REST vs Pub/Sub

Queue

P1

P2

P3

P4

C1

C2

C3

GET

PUT

POST

DELETE

Characteristics

“Smart endpoints Dumb pipes”

Characteristics

Strategies for decomposing


• Verb or usecase - e.g. Checkout UI



• Noun - e.g. Catalog product service



• Noun - e.g. Catalog product service

• Single Responsible Principle - e.g. Unix utilities

Service A

Towards microservices

EARWARWAR

WAR

JARJARJARJAR

Service A


EARWAR DBWAR

WAR

JARJARJARJAR

DBCache

Service A


EARWAR DB

LoadBalancer WAR

WAR

JARJARJARJAR

DBCache

Service C

WAR

Service B

WAR

Aggregator Pattern #1Service A

WAR

Service C

WAR

Service B

WAR

Aggregator Pattern #1

DBCache

Service A

WARDBCache

DBCache

Service C

WAR

Service B

WAR


DBCache

Service A

WARDBCache

DBCacheAggregator

LoadBalancer

Aggregator

Service C

WAR

Service B

WAR


DBCache

Service A

WARDBCache

DBCacheAggregator

LoadBalancer

Service C

WAR

Service B

WAR

Proxy Pattern #1.5

DBCache

Service A

WARDBCache

DBCacheProxy

LoadBalancer

Chained Pattern #2

Service A

WAR

DBCache

LoadBalancer

Chained Pattern #2

Service A

WAR

DBCache

LoadBalancer

Service B

WAR

DBCache

Chained Pattern #2

Service A

WAR

DBCache

LoadBalancer

Service B

WAR

DBCache

Service C

WAR

DBCache

Branch Pattern #3

Service A

WAR

DBCache

LoadBalancer

Branch Pattern #3

Service A

WAR

DBCache

LoadBalancer Service B

WAR

DBCache

Branch Pattern #3

Service A

WAR

DBCache

LoadBalancer Service B

WAR

DBCache

Service D

WAR

DBCache

Service C

WAR

DBCache

Shared Resources #4Service B

WAR

DBCache

Service C

WAR

Service D

WAR

DBCache

Service A

WAR

DBCache

LoadBalancer

Async Messaging #5Service B

WAR

DBCache

Service C

WAR

Service D

WAR

DBCache

Queue

DBCache

Service A

WAR

DBCache

LoadBalancer

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







• Eliminates any long-term commitment to a technology stack

• Freedom of choice of technology, tools, frameworks

“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

Drawbacks of microservices


• Additional complexity of distributed systems



• Significant operational complexity, need high-level of automation




• Rollout plan to coordinate deployments




• Rollout plan to coordinate deployments

• Slower ROI, to begin with

“Devs” job is to add new features“Ops” job is to keep the site stable and fast

35

“Ops” job is NOT to keep the site stable and fast

36


“Ops” job is to enable business

36


“Ops” job is to enable business

And so is “devs”

36

“Dev” “Ops”

37

What is DevOps?It’s

DevOps!

It’s DevOps!

It’s DevOps!

It’s DevOps!

It’s DevOps!

It’s DevOps!

https://sites.google.com/a/jezhumble.net/devops-manifesto/

Is DevOps for you?

https://puppetlabs.com/wp-content/uploads/2013/03/2013-state-of-devops-report.pdf

https://puppetlabs.com/wp-content/uploads/2013/03/2013-state-of-devops-report.pdf

Five “C”s of DevOps

Five “C”s of DevOps• Collaboration between “dev” and “ops”


• Culture


• Culture

• Code everything - application and configuration


• Culture


• Consistency - automation over documentation


• Culture


• Consistency - automation over documentation

• Continuous delivery

Collaboration• “Dev”

• Engineering

• Test

• Product management

• “Ops”

• System administrators

• Operations staff

• DBAs

• Network engineers

• Security professionals

Culture

Culture

• Respect other’s expertise, opinions, responsibilities

Culture


• Trust: Ops to think like devs, devs to think like ops

Culture



• Leads to transparency

Culture




• Don’t ignore failure, build joint recovery plans

Culture




• Don’t ignore failure, build joint recovery plans

• Amplify feedback loops

http://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickr



“Treat people warmly, issues coldly!”


Code everything• Application code

• Build scripts

• Database schema

• Configuration files

• IDE configurations

• Infrastructure

• Deployment scripts

• Test code and scripts

• Provisioning scripts

• Monitoring

• Logging

• …

“Never send a human to do a machine’s job”

Consistency

Consistency• Automation over documentation


• RepeatabilityDev

Test

Prod


• Repeatability

• Push-button deploymentsDev

Test

Prod


• Repeatability

• Push-button deployments

• Managing environments

Dev

Test

Prod

Manage environments• Cloud computing: PaaS, OpenShift, …

• Virtualization: Virtual Box, Vagrant, …

• Containers: Docker, Rocket, …

• App server: JBoss EAP, Tomcat, …

• Configuration tools: Puppet, Chef, Ansible, Salt, ...

• Orchestration: Kubernetes, Swarm, …

Continuous Delivery

Continuous Delivery• Agile Manifesto


• Continuous Integration



• Fail fast and recover




• Self service




• Self service

• 100% Automation




• Self service

• 100% Automation

• Proactive monitoring and metrics

BuildTest

Deploy

Continuous Integration

BuildTest

Deploy


Release

Build

Test

Deploy

ManualAcceptance

Continuous Delivery

BuildTest

Deploy


Release

Build

Test

Deploy

ManualAcceptance

Continuous Delivery

Release

Build

Test

Deploy

Continuous Deployment

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

Deployment Pipeline

“End-to-end automation of build, deploy,

test, and release process”

jboss.org

http://jboss.org

Changing application demands: What developers need to know

Software

Transcript of Changing application demands: What developers need to know