architectural design patterns for cloud computing
play

Architectural Design Patterns for Cloud Computing Rajesh Venkatesan - PowerPoint PPT Presentation

Architectural Design Patterns for Cloud Computing Rajesh Venkatesan Senior Architect, HCL Technologies rajeshvn@hcl.com Cloud Computing NIST Definition Provision without human On-demand interaction self-service SaaS Accessible via


  1. Architectural Design Patterns for Cloud Computing Rajesh Venkatesan Senior Architect, HCL Technologies rajeshvn@hcl.com

  2. Cloud Computing – NIST Definition • Provision without human On-demand interaction self-service SaaS • Accessible via the internet Broad network • Across heterogeneous platforms access PaaS • Multi Tenant Resource • Location Independence pooling • Dynamic Provisioning and IaaS Release Rapid elasticity • Seemingly Unlimited • Usage is measured Measured • Is monitored, controlled and service reported 2

  3. Business Requirements for the cloud applications Can I keep the cost of adding a customer near Can my Can I quickly zero? partners build have trial additional instances for offerings? customers? Can I have a Can I bill only solution that is based on what completely customer uses. secure? Cloud Architecture Can I have just Can I afford to in time not know when infrastructure my service will capabilities? go viral? Can I Enterprise/ Can I shutdown modularize and Common Concern unused sell based on instances? customers need? ISV Concern Can my Customers Can I quickly aggregate purchase and services? get access to services? 3

  4. Architectural Tenets Elasticity Scalability Availability Interoperability Multi Tenancy Security 4

  5. Architectural Pattern – Loose Coupling  The fewer assumptions that a component makes of its environment, the looser it is coupled.  Location, Availability abstraction  Example  All types of messaging. Cons Pros 5

  6. Architectural Pattern – Stateless Design  State Implications  Components that have heavy in-memory state are near impossible to scale.  Failure of the component translates failure of multiple requests.  Additional nodes do not solve this problem since state is lost.  Stateless Design  Move state to a centralized persistent store. Keep components stateless. Cons Pros 6

  7. Architectural Pattern - Auto Scale  Elasticity is a primary feature of the cloud.  Applications must take advantage of this feature.  Monitor load and adjust number of instances.  Scale Down is as important as Scale Up Cons Pros 7

  8. Architectural Pattern – Partition Tolerance  Brewer’s CAP Theorem.  Basically Available, Soft State and Eventually Consistency Consistent (BASE)  Some state can be reflected late.  Enables Availability and compromises on Consistency.  Design to take advantage of moving out “eventually Partition Availability consistent” data. Tolerance Choose Two • Seamless Scale • Complex Programming Model 8

  9. Architectural Pattern – Failure Tolerance  Assume everything will fail.  With loose coupling and stateless design, failure tolerance is easy to build.  Architecture must assume an application will function with minimal impact if parts of it fail.  Functional Decomposition and Physical Deployment Decoupling will limit failure to parts of system.  The cloud will enable recovery very quickly because of its very nature of instant replenishment. 9

  10. Architectural Pattern – Choice of Storage The type of storage affects COST Data Classifications:  Persistent Data – Standard Persistent Storage (File)  Simple Data – Key Value Pair, Data Structure, JSON.  Static Distribution Data - CDN  RDBMS – Standard Relational Data Choose the right storage  Use Content Delivery Networks for Static Distributable Content  Use Standard Persistent Storage for storing files  Use Key Value Pair Databases for Storing Indexes, Shared State (Session) and any data for quick retrieval  Use RDBMS for Relational Data 10

  11. Architectural Pattern – Multi-Tenancy  Multi Tenant Efficiency lowers the cost of adding a customer.  Various Levels  IaaS – Multi Tenant Virtualized Infrastructure (AWS, Rackspace etc) [TENANT=Compute, Storage, Network]  PaaS – Multi Tenant Application Infrastructure (Google App Engine, Azure, force.com etc) [Tenant=Application]  SaaS – Multi Tenant Application (Most SaaS Applications including Salesforce.com, Google Apps etc) [Tenant=Customer]  “ Building Multi Tenant Java Applications “, Silicon India Java vs Conference – Aug 2011  Concern spans across architecture. Cons Pros 11

  12. Architectural Pattern – Standard Integration  Not a strict cloud concern, but more significant for cloud applications.  Once applications move out of premise, integration becomes a key concern.  Standard based integration facilitates secure access to applications.  Standards  Identity (SAML/OpenID/oAuth)  API (REST/SOAP/WSRP/JSR 168) vs Cons Pros 12

  13. Architecture Pattern - Security  Abstracted very efficiently by IaaS Providers.  Multi Tenant IaaS is highly secure. Infrastructure Infrastructure  Secure Access to instance Security Security  Open Needed Ports Only  Keep Certificates Safe  All Inbound and Outbound interface points must be secured by default. (SSL) Security  Address Security Threats [OWASP Top Ten] Application  Use Identity and Access Management Services where Application Data available Security Security Security  Know your standards  SAML/OpenID for Identity Delegation  oAuth for API Access  Data at rest  Use tenant specific encryption when required. Decouple encryption awareness from the data layer allowing data leaks to still be harmless.  TradeOffs  Database functions cannot be applied on encrypted fields Data Security  Performance  Data in transit  Use Secure means of transfer (https) and add authentication/ authorization layer on top.  Use In Wire Encryption for highly critical data

  14. PaaS – Complexity Abstraction  Most PaaS abstract out a lot of complexity  They also implicitly force good design.  Almost all PaaS provide consistent availability of data.  Programming to PaaS enforces most of the design principles including  Stateless Design – Instances can be taken off anytime. Loose Coupling – Cost kicks in for additional  usage.  Auto Scale – Ability to configure scaling thresholds.  Partition Tolerance – Most functions like queues and data stores forces consumers to program to their model.  Identity – Most PaaS provide support for SAML/OpenID (as SP and IdP)  Some PaaS support Multi Tenancy 14

  15. Cloud - Application Fitment Profile Cloud Scale/Parallel Computing Elastic Short Recurring Life time Peripheral Applications (CRM, Security, Communication) Mobile, Tablet, Point Device Based 15

  16. References  Architectural Design Patterns for the cloud [http://www.slideshare.net/AmazonWebServices/aws- architectingjvariafinal]  Windows Azure Design Patterns [http://www.slideshare.net/dpallmann/windows-azure-design-patterns]  Cloud Computing Patterns [http://cloudcomputingpatterns.org/]  Open Security Architecture [http://www.opensecurityarchitecture.org/cms/library/patternlandscape/251- pattern-cloudcomputing]  Mapping Applications to the Cloud [http://msdn.microsoft.com/en-us/library/dd430340.aspx]  Patterns For High Availability, Scalability, And Computing Power With Windows Azure[http://msdn.microsoft.com/en-us/magazine/dd727504.aspx] 16

  17. Questions? 17

Download Presentation
Download Policy: The content available on the website is offered to you 'AS IS' for your personal information and use only. It cannot be commercialized, licensed, or distributed on other websites without prior consent from the author. To download a presentation, simply click this link. If you encounter any difficulties during the download process, it's possible that the publisher has removed the file from their server.

Recommend


More recommend