• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Decomposing applications for deployability and scalability #gluecon
 

Decomposing applications for deployability and scalability #gluecon

on

  • 12,034 views

Today, there are several trends that are forcing application architectures to evolve. Users expect a rich, interactive and dynamic user experience on a wide variety of clients including mobile ...

Today, there are several trends that are forcing application architectures to evolve. Users expect a rich, interactive and dynamic user experience on a wide variety of clients including mobile devices. Applications must be highly scalable, highly available and run on cloud environments. Organizations often want to frequently roll out updates, even multiple times a day. Consequently, it’s no longer adequate to develop simple, monolithic web applications that serve up HTML to desktop browsers.

In this talk we describe the limitations of a monolithic architecture. You will learn how to use the scale cube to decompose your application into a set of narrowly focused, independently deployable back-end services and an HTML 5 client. We will also discuss the role of technologies such as NodeJS and AMQP brokers. You will learn how a modern PaaS such as Cloud Foundry simplifies the development and deployment of this style of application.

Read articles based on the presentation here: http://plainoldobjects.com/2012/05/31/decomposing-applications-for-deployability-and-scalability-part-1/

Statistics

Views

Total Views
12,034
Views on SlideShare
2,416
Embed Views
9,618

Actions

Likes
4
Downloads
56
Comments
1

8 Embeds 9,618

http://www.javamexico.org 8581
http://plainoldobjects.com 974
http://storify.com 34
http://plainoldobjects.wordpress.com 22
http://us-w1.rockmelt.com 3
https://twitter.com 2
http://nodeslide.herokuapp.com 1
http://translate.googleusercontent.com 1
More...

Accessibility

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel

11 of 1 previous next

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
  • Read articles based on the presentation here: http://plainoldobjects.com/2012/05/31/decomposing-applications-for-deployability-and-scalability-part-1/
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Decomposing applications for deployability and scalability #gluecon Decomposing applications for deployability and scalability #gluecon Presentation Transcript

    • Decomposing applications fordeployability and scalability Chris Richardson Author of POJOs in Action Founder of the original CloudFoundry.com @crichardson crichardson@vmware.com 1
    • Presentation goal How decomposing applications improves deployability and scalability and How Cloud Foundry helps 2
    • About Chris 3
    • (About Chris) 4
    • About Chris() 5
    • About Chris 6
    • About Chris http://www.theregister.co.uk/2009/08/19/springsource_cloud_foundry/ 7
    • vmc push About-Chris Developer Advocate for CloudFoundry.comSignup at http://cloudfoundry.com Promo code: Gluecon12 8
    • Agenda The (sometimes evil) monolith Decomposing applications into services How do services communicate? Presentation layer design How Cloud Foundry helps 9
    • Let’s imagine you are building an e- commerce application 10
    • Traditional web application architecture WAR StoreFrontUI Accounting Service MySQL Browser Apache InventoryService Database Shipping ServiceSimple to Tomcat develop test deploy scale 11
    • But there are problems 12
    • Users expect a rich, dynamic andinteractive experience on mobiledevices and desktop h oug d en oo ’t g HTTP Request e isn r ctu Java Web Browser e hit HTML/Javascript Application c I ar ty le U s Old Real-time web ≅ NodeJS 13
    • Obstacle to frequent deployments Need to redeploy everything to change one component Interrupts long running background (e.g. Quartz) jobs Increases risk of failure Fear of change Updates will happen less often e.g. Makes A/B testing UI really difficult 14
    • Large application Slow IDESlow start times for web container 15
    • Scaling development WAR StoreFrontUI Accounting Scalable != InventoryService development Shipping Forces teams to synchronize development efforts Teams need to coordinate updates 16
    • Long-term commitment to a single technology stack Let’s suppose you go with the JVM • Some polyglot support • Many (but not all) JVM languages interoperate easily • e.g. Scala, Groovy modules within a Java application • But you can’t use non-JVM languages Application depends on a particular: • Framework - e.g. Spring or Java EE • Container - e.g. Tomcat Switching technology stack touches entire application • Painful • Rarely done 17
    • Agenda The (sometimes evil) monolith Decomposing applications into services How do services communicate? Presentation layer design How Cloud Foundry helps 18
    • 3 dimensions to scalingY axis -functionaldecompositionScale by s ngsplitting ila g n hi g s oni rtdifferent things iti rt im pa ta in da ittl s- sp i ax by Z ale X axis - horizontal duplication Sc Scale by cloning 19
    • Y axis scaling - functional partitioning Splits monolithic application into a set of services Each service implements a set of related functionality Partitioning schemes: • Partition functionality by noun or by verb • Single Responsibility Principle • Unix utilities - do one focussed thing well 20
    • Y axis scaling - application level billing web application Accounting Service Store front web application inventory web application Store Front InventoryService shipping web application ShippingServiceApply X axis cloning and/or Z axis partitioning to each service 21
    • Real world examples http://techblog.netflix.com/ Between 100-150 services are accessed to build a page. http://highscalability.com/amazon-architecture http://www.addsimplicity.com/downloads/ eBaySDForum2006-11-29.pdf http://queue.acm.org/detail.cfm?id=1394128 22
    • There are drawbacks Complexity: • Architectural • Development • Deployment • Application management Deciding when to use it • In the beginning: you don’t need it and it will slow you down • When you do need it: refactoring existing code is painful See Steve Yegge’s Google Platforms Rant re Amazon.com 23
    • But there are many benefits Scales development: focussed two pizza devops teams Deploy services independently Scale services independently Improves fault isolation Enforces well defined interfaces between components Eliminates long-term commitment to a single technology stack Modular, polyglot applications 24
    • Two levels of architecture System level • Defines the inter-service glue: interfaces and communication mechanisms • Slow changing Versus Service level • Defines the internal architecture of each service • Far fewer constraints on technology • Each service could use a different technology stack • Rapid evolving 25
    • If services are small... Regularly rewrite using a better technology stack Pick the best developers rather than best <pick a language> developers polyglot culture Adapt system to changing requirements and better technology without a total rewrite Fred George “Developer Anarchy” 26
    • Moreover: you are not the same you ... Cell lifetimes: Can we build software • hours - some white blood cells systems with these characteristics? • days - stomach lining cells • years - bone cells Too much technical debt • lifetime - brain cells component death? 50 to 70 billion of your cells die each day Yet you (the system) remains intact http://dreamsongs.com/Files/ DesignBeyondHumanAbilitiesSimp.pdf http://dreamsongs.com/Files/WhitherSoftware.pdf 27
    • Agenda The (sometimes evil) monolith Decomposing applications into services How do services communicate? Presentation layer design How Cloud Foundry helps 28
    • Inter-service communication options Multiple collaborating services need a communication mechanism Many choices: • Synchronous asynchronous • Transports: HTTP, AMQP, ... • Formats: JSON, XML, Protocol Buffers, Thrift, ... • Even via the database Distributed application error handling strategies Asynchronous is preferred JSON is fashionable but binary format is more efficient 29
    • Asynchronous message-based communication wgrus-billing.war Accounting Servicewgrus-store.war RabbitMQ wgrus-inventory.war StoreFrontUI (Message MySQL Broker) Widget InventoryService wgrus-inventory.war InventoryService 30
    • Benefits and drawbacks Benefits • Decouples caller from server • Caller unaware of server’s coordinates (URL) • Message broker buffers message when server is down/slow Drawbacks • Additional complexity of message broker • RPC using messaging is more complex 31
    • Writing code that calls services 32
    • Composable futures Problem: • Service A needs to call services B and C and then D • Makes sense to call B and C parallel • Yet most concurrency APIs are low-level, error-prone etc Solution: • Use Akka composable futures = really nice abstraction val futureB = callB() Two calls execute in parallel val futureC = callC() val futureD = for { b <- futureB.mapTo[SomeType] c <- futureC.mapTo[SomeType] d <- callD(b, c) And then invokes D } yield d val result = Await.result(futureD, 1 second). asInstanceOf[SomeOtherType] Get the result of D http://doc.akka.io/docs/akka/2.0.1/scala/futures.html http://en.wikipedia.org/wiki/Futures_and_promises 33
    • Spring Integration Builds on Spring framework Implements EAI patterns = high-level of abstraction for building message based applications Provides the building blocks for a pipes and filters architecture • Pipes = message channels • Filters = endpoints that filter, transform, route messages and integrate with external messaging infrastructure Enables development of components that are • loosely coupled • insulated from underlying messaging infrastructure 34
    • Handling failure Errors happen (especially in distributed systems) Use timeouts and retries • Never wait forever • Some errors are transient so retry Use per-dependency bounded thread pool with bounded queue • Limits number of outstanding requests • Fails fast if service is slow or down Use circuit breaker • High rate of errors stop calling temporarily • Avoids calling service that has issues On failure • Returned cached or default data • Invoke custom error handler http://techblog.netflix.com/2012/02/fault-tolerance-in-high-volume.html 35
    • Agenda The (sometimes evil) monolith Decomposing applications into services How do services communicate? Presentation layer design How Cloud Foundry helps 36
    • Modular applicationChoice of presentation layer technology + Redeploy UI frequently/independently 37
    • NodeJS is the fashionable technologyMany JavaScript client frameworks have a NodeJS counterparte.g. socket.io 38
    • NodeJS isn’t the only game in town JVM-based http://vertx.io/ 39
    • A modern web application Service 1 RESTful WS Node JSBrowser HTML 5 Server Application Application Service 2 Events Socket.io Socket.io client server ... 40
    • NodeJS - using RESTful WS and AMQP REST ServiceRESTRequests Node JS Events socket.io AMQP AMQP RabbitMQ Service 41
    • Updating the UI is easy Update the UI independently of rest of system Easily run A/B tests Enables fast iteration of the UI http://theleanstartup.com/principles 42
    • But coordination with backend changes required Let’s imagine that you are deploying an advanced search feature: • Enhancements to search service • Enhancements to UI Before • Deploy new war Now: • Some coordination required • Deploy updated backend service • Deploy updated NodeJS and browser code • Enable feature using feature switch 43
    • Agenda The (sometimes evil) monolith Decomposing applications into services How do services communicate? Presentation layer design How Cloud Foundry helps 44
    • Traditional tools: monolithic applications 45
    • Developing modular apps is more difficult Many more moving parts to manage • Platform services: SQL, NoSQL, RabbitMQ • Application services: your code Who is going to setup the environments: • the developer sandbox? • ... • QA environments? But Cloud Foundry helps... 46
    • Easy polyglot application deployment and service provisioning OSS community vFabricPostgres Ap p lica Data Private   o Services Clouds   n  S erv ice  In vFabric ter fac RabbitMQTM Msg Public e Services Clouds Micro Other Clouds Services Additional partners services …
    • Creating a platform service instance$ vmc create-service mysql --name mysql1Creating Service: OK$ vmc services......=========== Provisioned Services ============+-------------+---------+| Name | Service |+-------------+---------+| mysql1 | mysql |+-------------+---------+
    • Multi-application manifest - part 1 --- applications: inventory/target: Path to application name: inventory url: cer-inventory.chrisr.cloudfoundry.me framework: name: spring info: mem: 512M description: Java SpringSource Spring Application exec: mem: 512M instances: 1 services: Required platform services si-rabbit: type: :rabbitmq si-mongo: type: :mongodb si-redis: type: :redis 49
    • Multi-application manifest - part 2 store/target: Path to application name: store url: cer-store.chrisr.cloudfoundry.me framework: name: spring info: mem: 512M description: Java SpringSource Spring Application exec: mem: 512M instances: 1 services: Required platform services si-mongo: type: :mongodb si-rabbit: type: :rabbitmq 50
    • One command to create platform services and deployapplication $ vmc push Would you like to deploy from the current directory? [Yn]: Pushing application inventory... Creating Application: OK Creating Service [si-rabbit]: OK Binding Service [si-rabbit]: OK Creating Service [si-mongo]: OK Binding Service [si-mongo]: OK Creating Service [si-redis]: OK Binding Service [si-redis]: OK Uploading Application: Checking for available resources: OK Processing resources: OK Packing application: OK vmc push: Uploading (12K): OK Push Status: OK •Reads the manifest file Staging Application inventory: OK Starting Application inventory: OK •Creates the required platform services Pushing application store... Creating Application: OK •Deploys all the applications Binding Service [si-mongo]: OK Binding Service [si-rabbit]: OK Uploading Application: Checking for available resources: OK Processing resources: OK Packing application: OK Uploading (5K): OK Push Status: OK Staging Application store: OK 51 Starting Application store: ...
    • Micro Cloud Foundry: new developer sandbox App Instances Services Open source Platform as a Service project 10.04 A PaaS packaged as a VMware Virtual Machine Use as a developer sandbox • Use the services from Junit integration tests • Deploy your application for functional testing • Remote debugging from STS 52
    • Using Caldecott…$ vmc tunnel1: mysql-135e02: mysql1Which service to tunnel to?: 2Password: ********Stopping Application: OKRedeploying tunnel application caldecott.Uploading Application: Checking for available resources: OK Packing application: OK Uploading (1K): OKPush Status: OKBinding Service [mysql1]: OKStaging Application: OKStarting Application: OKGetting tunnel connection info: OKService connection info: username : uMe6Apgw00AhS password : pKcD76PcZR7GZ name : d7cb8afb52f084f3d9bdc269e7d99ab50Starting tunnel to mysql1 on port 10000.1: none2: mysqlWhich client would you like to start?: 2
    • …Using CaldecottLaunching mysql --protocol=TCP --host=localhost --port=10000 -- user=uMe6Apgw00AhS --password=pKcD76PcZR7GZ d7cb8afb52f084f3d9bdc269e7d99ab50Welcome to the MySQL monitor. Commands end with ; or g.Your MySQL connection id is 10944342Server version: 5.1.54-rel12.5 Percona Server with XtraDB (GPL), Release 12.5, Revision 188Copyright (c) 2000, 2011, Oracle and/or its affiliates. All rights reserved.Oracle is a registered trademark of Oracle Corporation and/or itsaffiliates. Other names may be trademarks of their respectiveowners.Type help; or h for help. Type c to clear the current input statement.mysql>
    • Running JUnit test with Caldecott Configure your test code to use port + connection info 55
    • Summary Monolithic applications are simple to develop and deploy BUT applying the scale cube Decomposes your application into services Enables scaling for transactions and data volumes Tackles application complexity Enables scaling for development Enables frequent, independent deployments Make it easy to leverage other technologies AND Cloud Foundry simplifies the development and deployment of modular, service-based applications 56
    • @crichardson crichardson@vmware.com Questions?www.cloudfoundry.com promo code Gluecon12