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

Recommend


More recommend