Building Highly Scalable Apps On Bluemix
•Download as PPTX, PDF•
2 likes•1,648 views
Horizontal scalability cannot be an afterthought, it must be part of your design and implementation. This deck contains patterns you can use while building your application to make sure your application will scale flawlessly in the cloud.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (16)
Similar to Building Highly Scalable Apps On Bluemix
Similar to Building Highly Scalable Apps On Bluemix (20)
More from Ryan Baxter
Recently uploaded
Recently uploaded (20)
Building Highly Scalable Apps On Bluemix
- 1. Building Highly Scalable Applications With Bluemix By: Ryan Baxter @ryanjbaxter 08/19/2014
- 2. What is Bluemix? 1 Bluemix is a cloud- based platform for building, managing, and running applications of all types.
- 3. What does it mean to be scalable? Applications are considered scalable when additional instances can be added to accommodate a growing workload. 2
- 4. By Scaling We Are Trying To Avoid This 3
- 5. How Did We Solve This Problem Before? 4
- 6. Scaling Horizontally Is Cheaper 5
- 7. We End Up With Something Like This 6 Load Balancer
- 8. Scalability cannot be an after-thought. 7
- 9. Lessen The Load Load is the reason for scaling We can lessen the load by diverting requests elsewhere Use a content-delivery-network (CDN) for static resources Libraries like JQuery, Bootstrap, etc can be delivered to clients more efficiently via a CDN while at the same time lessening the work of your app server You can even put custom libraries on a CDN if it makes sense Make everything you can cacheable!!! 8
- 10. Does this application scale? 9 Client Side Code App REST APIs Search Twitter Streams DBaaS
- 11. Is this really better? 1010 My App 1 DBaaS Client Side Code App REST APIs Search Twitter Streams Load Balancer My App 1 Client Side Code App N REST APIs Search Twitter Streams
- 12. Smaller Is Better 11 Client Side Code App REST APIs Twitter App Twitter Streams Search App Search DBaaS
- 13. Scaling The Web App 12 Twitter App Twitter Streams Client Side Code App N REST APIs Client Side Code App REST APIs Load Balancer Search App Search DBaaS
- 14. Pub/Sub To Distribute Data 13 Twitter App Twitter Streams Pub/Sub Client Side Code App N REST APIs Client Side Code App REST APIs Load Balancer DBaaS Search Not Shown For Simplicity
- 15. What About Search? 14 Client Side Code App N REST APIs Client Side Code App REST APIs Search App Search Load Balancer DBaaS Twitter Not Shown For Simplicity
- 16. Does This Make It Better? 15 Search App Search Client Side Code App N REST APIs Client Side Code App REST APIs Search App N Search Load Balancer Load Balancer DBaaS Twitter Not Shown For Simplicity
- 17. Lets Use A Queue 16 Search Worker Search Client Side Code App N REST APIs Client Side Code App REST APIs Search Worker N Search Load Balancer Search Queue DBaaS Twitter Not Shown For Simplicity
- 18. What About The Database? Our application scales nicely, we have small modular components that focus on specific tasks However in some cases we can only respond as fast as our database operations perform We can have all the worker threads we want to handle search but if the DB is busy they can’t do much. 17
- 19. Use A Caching Service 18 Search Worker Search DBaaS Client Side Code App N REST APIs Client Side Code App REST APIs Search Worker N Search Search Queue Data Cache Twitter App Twitter Streams Pub/Sub Load Balancer
- 20. Caching Services 19 Message Queue Services Pub/Sub Services
- 21. Storing State Within The Application 20 Chat App Hi There Hi Ryan
- 22. Inconsistent State When Scaled 21 Chat App Hi There Chat App N Hi Ryan Load Balancer
- 23. Store State In A Common Store 22 Chat App My Chat App N Load Balancer Hi There Hi Ryan Data Store Chat App N
- 24. Auto-Scaling You can manually scale applications using the command line or the Bluemix UI Use the auto-scaling service to avoid having to scale manually…it’s FREE!!! Works with Java Liberty, Node.js, and Ruby runtimes Java – scale based on CPU, JVM Heap, Memory Node.js – scale based on CPU and Memory Ruby – scale based on Memory 23
- 25. DEMO 24
- 26. Additional Resources http://12factor.net/ - Great rules to follow for building scalable cloud applications http://www.amazon.co.uk/Building-Scalable-Web-Sites- Henderson/dp/0596102356 - Book on building scalable websites http://www.ibm.com/developerworks/cloud/library/cl- bluemix-node-redis-app/index.html - dW article on BlueChatter App http://developer.ibm.com/bluemix - All things Bluemix 25
- 27. Additional Resources https://www.ibm.com/developerworks/cloud/library/cl- bluemix-autoscale/ - Scaling Applications On Bluemix http://www.pivotal.io/platform-as-a-service/cloud- foundry-summit-2014 - Talks on microservices which are relevant to scalability 26
- 28. Thank you. Get Started: www.bluemix.net @IBMBluemix https://www.facebook.com/ibmbluemix
Editor's Notes
- Problems: -if one component crashes the entire instance crashes -if one compoent blocks everything else is blocked as well -probably have some data consistancy issues – twitter is streaming data to each instance
- If we break the app into individual components we can eliminate some problems -the first one being that if one component crashes everything else can still run, functionality may be decreased but we are not completely lost -can help isolate any data consistence issues when we scale
- The most common place you might first look to scale is the client side code and your rest apis. This in theory may be getting the most use. Technically you may want to also separate out rest apis as well. -we now can have a bottleneck in search -twitter streams def has an issue do to load balancer in front
- Lets introduce a service to help with twitter, We want all instances to know about the tweets coming in so we can use a pub sub model to help distribute tweets When an instance starts it subscribes to our pub sub service. Our twitter app publishes tweets to the service and the service now distributes them All instances now have the same data and we can add/subtract client side instances at will
- Search is also a problem eventualy our search “service” may get bogged down with requests and we have a bottleneck
- If we just scale the search app without any changes what may happen? It might make things better, but not really The load balancer infront of the apps is now distributing requests to the instances underneath, who says that is happening efficiently, again we can make all of them busy and completely block the apps above using the service
- What is we use a queue instead and have workers which handle doing the searches. Our apps above can put things in the queue and continue on with their work, waiting for responses to the requests they put in the queue. Worked underneath pick requests off the queue do the work and return responses. Now we can scale our worked up and down do to load in the queue