SlideShare a Scribd company logo
Cloud Architecture Best practices
Omid Vahdaty, Cloud Architect
Generic Architecture questions:
● When would you cloudify?
○ opex
○ capacity unclear
○ Elasticity
○ Agility in development
Generic Architecture questions:
● When not to cloudify?
○ Network latency
○ Long terms costs
○ Building datacenter is your business
○ Where vendor lockin is important. (offloading terabytes from Amazon??)
○ The architecture of your app is not a match to the clouds best practices.
○ Regulation?
○ Performance considerations. e.g SQream.
Generic Architecture questions:
● When would you normalize tables?
○ eliminate redundant data, utilize space efficiently and reduce update
errors.
○ in situations where we are storing immutable data such as financial
transactions or a particular day's price list.
Generic Architecture questions:
● When NOT to NORMALIZE ?
○ Could you denormalize your schema to create flatter data structures that
are easier to scale?
○ When Multiple Joins are Needed to Produce a Commonly Accessed
View
○ decided to go with database partitioning/sharding then you will likely end
up resorting to denormalization
○ Normalization saves space, but space is cheap!
○ Normalization simplifies updates, but reads are more common!
○ Performance, performance, Performance
Generic Architecture questions:
● NoSql advantages?
○ Non-relational and schema-less data model
○ Low latency and high performance
○ Highly scalable
○ SQL queries are not well suited for the object
oriented data structures that are used in most
applications now.
○ Some application operations require multiple
and/or very complex queries. In that case, data
mapping and query generation complexity raises
too much and becomes difficult to maintain
Generally speaking - a good architecture?
● stable / HA / DR / graceful failure
● Structure - start with skeleton, and be able to add future components.
● Loosely coupled
● Low complexity on components
● Passes all basic tests
● Use Cases matches Tradeoff of architecture (e.g scale out VS. scale up) - i.e
each architecture has advantage and disadvantage
● Performance aspects.
● Maintenance aspects
Generally speaking - a good architecture?
● Documented
● Decoupling storage and compute
● API, Services - not Servers.(PaaS VS. Iaas. )
● TCO
● Hardware considerations
● Network considerations- AWS VS IBM - no money on private network.
● Security considerations
Cloud Architecture Best Practices
● Scale out, Stateless, Need a dispatcher !
■ Pull - Asynchronous event-driven workloads do not require a load
balancing solution because you can implement a pull model instead.
In a pull model, tasks that need to be performed or data that need to
be processed could be stored as messages in a queue using
Amazon Simple Queue Service (Amazon SQS) or as a streaming
data solution like Amazon Kinesis.
■ Push ( like elastic load balancer or route 53 -)
Cloud Architecture Best Practices
● Scale out, Making it stateless
○ web applications can use HTTP cookies to store information about a session at the client’s
browser (e.g., items in the shopping cart). The browser passes that information back to the
server at each subsequent request so that the application does not need to store it. However,
there are two drawbacks with this approach.
■ First, the content of the HTTP cookies can be tampered with at the
client side, so you should always treat them as untrusted data that
needs to be validated.
■ Second, HTTP cookies are transmitted with every request, which
means that you should keep their size to a minimum (to avoid
unnecessary latency).
Cloud Architecture Best Practices
● Scale out, Making it stateless
○ Consider storing a unique session identifier in a HTTP cookie and storing
more detailed user session information server-side. Most programming
platforms provide a native session management mechanism that works
this way, however this is often stored on the local file system by default.
This would result in a stateful architecture. A common solution to this
problem is to store user session information in a database. Amazon
DynamoDB is a great choice due to its scalability, high availability, and
durability characteristics.
Cloud Architecture Best Practices
● Scale out, Making it stateless
○ Other scenarios require storage of larger files (e.g., user uploads, interim
results of batch processes, etc.). By placing those files in a shared
storage layer like Amazon S3 or Amazon Elastic File System (Amazon
EFS) you can avoid the introduction of stateful components. Another
example is that of a complex multistep workflow where you need to track
the current state of each execution.
Cloud Architecture Best Practices
● Scaleout, Stateful
○ by definition, databases are stateful
○ “Sticky sessions for HTTP/s” - You might still be able to scale those components horizontally
by distributing load to multiple nodes with “session affinity.” In this model, you bind all the
transactions of a session to a specific compute resource. You should be aware of the
limitations of this model. Existing sessions do not directly benefit from the introduction of newly
launched compute nodes. More importantly, session affinity cannot be guaranteed. For
example, when a node is terminated or becomes unavailable, users bound to it will be
disconnected and experience a loss of session-specific data (e.g., anything that is not stored
in a shared resource like S3, EFS, a database, etc.).
Cloud Architecture Best Practices
● Elastic resources
○ Kill unused resources
○ Don't use fixed IP unless a must
○ Immutable infrastructure pattern. With this approach a server, once
launched, is never updated throughout its lifetime. Instead, when there is
a problem or a need for an update the server is replaced with a new
one that has the latest configuration. In this way, resources are
always in a consistent (and tested) state and rollbacks become easier to
perform.
○ Bootstrapping
Cloud Architecture Best Practices
● Elastic resources
○ When you launch an AWS resource like an Amazon EC2 instance or
Amazon Relational Database (Amazon RDS) DB instance, you start with
a default configuration. You can then execute automated bootstrapping
actions. That is, scripts that install software or copy data to bring that
resource to a particular state. You can parameterize configuration details
that vary between different environments (e.g., production, test, etc.) so
that the same scripts can be reused without modifications.
Cloud Architecture Best Practices
● Elastic resources
○ AMI Images - faster start times and removes dependencies to
configuration services or third-party repositories. This is important in
auto-scaled environments
○ Convert vmware to ami
○ AWS Elastic Beanstalk and the Amazon EC2 Container Service (Amazon
ECS) support Docker and enable you to deploy and manage multiple
Docker containers across a cluster of Amazon EC2 instances.
Cloud Architecture Best Practices
● Elastic resources
○ AWS Elastic Beanstalk follows the hybrid model. It provides
preconfigured run time environments (each initiated from its own AMI)
but allows you to run bootstrap actions (through configuration files called
.ebextensions 11) and configure environment variables to parameterize
the environment differences.
○ Infrastructure as code (cloud Formations): Write code to set up new
environments - and keep it versioned.
Cloud Architecture Best Practices
● Automation
○ BeansTalk - just add code, scaling, resource are taken care
of automatically
○ EC2 auto recovery - coupled with cloud watch - restore to
specific state
○ AutoScaling
○ Amazon CloudWatch Alarms with SNS, Those Amazon
SNS messages can automatically kick off the execution of a
subscribed AWS Lambda function, enqueue a notification
message to an Amazon SQS queue, or perform a POST
request to an HTTP/S endpoint
Cloud Architecture Best Practices
● Automation
○ AWS OpsWorks Lifecycle events: AWS OpsWorks
supports continuous configuration through lifecycle events
that automatically update your instances configuration to
adapt to environment changes. These events can be used to
trigger Chef recipes on each instance to perform specific
configuration task
○ AWS Lambda Scheduled events: These events allow you
to create a Lambda function and direct AWS Lambda to
execute it on a regular schedule.
Cloud Architecture Best Practices
● API :
○ support backwards compatibility for rollback scenarios.
○ Remeber: services - not servers!
○ Auto scaling included
○ Multi AZ redundancy included
Cloud Architecture Best Practices
● Loose coupling - As application complexity
increases, a desirable attribute of an IT system is
that it can be broken into smaller, loosely coupled
component. services are meant to be loosely
coupled, they should be able to be consumed
without prior knowledge of their network topology
details. Loose coupling is a crucial element if you
want to take advantage of the elasticity of cloud
computing where new resources can be launched
or terminated at any point in time. Service
discovery while maintaining Loose coupling:
Cloud Architecture Best Practices
● Loose coupling Service discovery while
maintaining Loose coupling:
○ service discovery via Elastic Load Balancing service.
Because each load balancer gets its own hostname you now
have the ability to consume a service through a stable
endpoint. This can be combined with DNS and private Amazon
Route53 zones, so that even the particular load balancer’s
endpoint can be abstracted and modified at any point in time.
○ use a service registration and discovery method to allow
retrieval of the endpoint IP addresses and port number of
any given service. Because service discovery becomes the
glue between the components, it is important that it is highly
available and reliable
Cloud Architecture Best Practices
● Loose coupling Service discovery while
maintaining Loose coupling:
○ Asynchronous integrations - This model is suitable
for any interaction that does not need an immediate
response and where an acknowledgement that a
request has been registered will suffice. It involves
one component that generates events and another that
consumes them. The two components do not integrate
through direct point-to point interaction but usually
through an intermediate durable storage layer (e.g., an
Amazon SQS queue or a streaming data platform like
Amazon Kinesis
Cloud Architecture Best Practices
● Loose coupling Service discovery while maintaining Loose
coupling:
○ Asynchronous integrations - This approach decouples the two components and
introduces additional resiliency. So, for example, if a process that is reading messages
from the queue fails, messages can still be added to the queue to be processed when
the system recovers. It also allows you to protect a less scalable backend service from
front end spikes and find the right tradeoff between cost and processing lag. For
example, you can decide that you don’t need to scale your database to accommodate
for an occasional peak of write queries as long as you eventually process those
queries asynchronously with some delay. Finally, by moving slow operations off of
interactive request paths you can also improve the end-user experience.
Cloud Architecture Best Practices
● Loose coupling Service discovery while maintaining Loose coupling:
○ Graceful failure - Another way to increase loose coupling is to build applications in such a way
that they handle component failure in a graceful manner. You can identify ways to reduce the
impact to your end users and increase your ability to make progress on your offline procedures,
even in the event of some component failure. in practice A request that fails can be retried with
an exponential backoff and Jitter strategy or it could be stored in a queue for later processing. For
front-end interfaces, it might be possible to provide alternative or cached content instead of failing
completely when, for example, your database server becomes unavailable. The Amazon Route
53 DNS failover feature also gives you the ability to monitor your website and automatically route
your visitors to a backup site if your primary site becomes unavailable. You can host your backup
site as a static website on Amazon S3 or as a separate dynamic environment.
Cloud Architecture Best Practices: Serverless
● Serverless architecture (AWS API gateway + lambda)
○ AWS Lambda allows you to write code functions, called handlers, which will execute when
triggered by an event.
○ Immediate benefits: easy to maintain, decoupled, and scalable
■ No operating systems to choose, secure, patch, or manage.
■ No servers to right size, monitor, or scale out.
■ No risk to your cost by over-provisioning.
■ No performance impact by under-provisioning.
Cloud Architecture Best Practices: Serverless
● Serverless architecture (AWS API gateway + lambda)
○ Optimizations
■ Includes by design, cloudFront in the BE to cache static requests
■ Lower latency
■ Protection against DDoS
○ You can improve the performance of specific API requests by using
Amazon API Gateway to store responses in an optional in-memory
cache. This not only provides performance benefits for repeated API
requests, but it also reduces backend executions, which can reduce
your overall cost.
Cloud Architecture Best Practices: Databases
● If your application primarily indexes and queries data with no
need for joins or complex transactions (especially if you
expect a write throughput beyond the constraints of a single
instance) consider a NoSQL database instead.
● If you have large binary files (audio, video, and image), it
will be more efficient to store the actual files in the Amazon
Simple Storage Service (Amazon S3) and only hold the
metadata for the files in your database.
Cloud Architecture Best Practices: Databases
● Use read replicas to increase read performance
● Use aurora instead of mysql
● If your schema cannot be denormalized consider a relational database
instead of noSQL
Cloud Architecture Best Practices: HA
● You should aim to build as much automation as possible in both detecting and reacting to failure.
You can use services like ELB and Amazon Route53 to configure health checks and mask failure by
routing traffic to healthy endpoints. In addition, Auto Scaling can be configured to automatically
replace unhealthy nodes. You can also replace unhealthy nodes using the Amazon EC2 auto
recovery feature or services such as AWS OpsWorks and AWS Elastic Beanstalk
● Asynchronous replication decouples the primary node from its replicas at the expense of introducing
replication lag. This means that changes performed on the primary node are not immediately
reflected on its replicas. Asynchronous replicas are used to horizontally scale the system’s read
capacity for queries that can tolerate that replication lag. It can also be used to increase data
durability when some loss of recent transactions can be tolerated during a failover.
Cloud Architecture Best Practices: HA
● Quorum-based replication combines synchronous and asynchronous
replication to overcome the challenges of large-scale distributed database
systems. Replication to multiple nodes can be managed by defining a
minimum number of nodes that must participate in a successful write
operation
Cloud Architecture Best Practices: DR
● Because of the long distance between the two data centers, latency makes it
impractical to maintain synchronous cross-datacenter copies of the data. As a
result, a failover will most certainly lead to data loss or a very costly data
recovery process.
● Each Availability Zone is engineered to be isolated from failures in other
Availability Zones. An Availability Zone is a data center. Availability Zones
within a region provide inexpensive, low-latency network connectivity to other
zones in the same region
● In fact, many of the higher level services on AWS are inherently designed
according to the Multi-AZ principle
Cloud Architecture Best Practices: DR
● Because of the long distance between the two data centers, latency makes it
impractical to maintain synchronous cross-datacenter copies of the data. As a
result, a failover will most certainly lead to data loss or a very costly data
recovery process.
● Each Availability Zone is engineered to be isolated from failures in other
Availability Zones. An Availability Zone is a data center. Availability Zones
within a region provide inexpensive, low-latency network connectivity to other
zones in the same region
● In fact, many of the higher level services on AWS are inherently designed
according to the Multi-AZ principle
Cloud Architecture Best Practices: cost reduction
● User serverless when possible - don't pay for idle.
● Monitoring size of compute
● Turn off unused workloads
● Auto scaling
● Purchasing options - reserved etc.
● Applications can be designed so that they store and retrieve information from fast, managed, in-
memory caches
● Edge caching - cloudFront (CDN), S3
Stay in touch...
● Omid Vahdaty
● +972-54-2384178

More Related Content

Viewers also liked (19)

PPTX
Enterprise Cloud Architecture Best Practices
David Veksler
 
PDF
Cloud Architecture
Arief Gunawan
 
PDF
Cloud Architecture Tutorial - Running in the Cloud (3of3)
Adrian Cockcroft
 
PDF
A cloud readiness assessment framework
Carlo Colicchio
 
PDF
Enterprise Cloud Operating Model Design
Joseph Schwartz
 
PDF
Cloud Migration Cookbook: A Guide To Moving Your Apps To The Cloud
New Relic
 
PDF
InterCloud Global Cloud
Theintercloud
 
PDF
Big Data Fundamentals
rjain51
 
PDF
Intro to Big Data
Quang Nguyen
 
PPTX
Azure Machine Learning
Chase Aucoin
 
PDF
What does Bob really want? Recommenders in the Cloud
Olivia Klose
 
PPTX
Microsoft's New Platform
John Rymer
 
PPTX
Nuts and bolts of running a popular site in the aws cloud
David Veksler
 
PDF
c-quilibrium R forecasting integration
AE - architects for business and ict
 
PPTX
PostgreSQL - Object Relational Database
Mubashar Iqbal
 
PPT
Enhancing Hong Kong's Competitiveness Through Data Center and Cloud Computing...
Charles Mok
 
PPTX
China Cloud Computing Presentation
Bo Hershey
 
PPTX
Deployment Automation on OpenStack with TOSCA and Cloudify
Cloudify Community
 
PPTX
Auto scaling websites in the cloud
David Veksler
 
Enterprise Cloud Architecture Best Practices
David Veksler
 
Cloud Architecture
Arief Gunawan
 
Cloud Architecture Tutorial - Running in the Cloud (3of3)
Adrian Cockcroft
 
A cloud readiness assessment framework
Carlo Colicchio
 
Enterprise Cloud Operating Model Design
Joseph Schwartz
 
Cloud Migration Cookbook: A Guide To Moving Your Apps To The Cloud
New Relic
 
InterCloud Global Cloud
Theintercloud
 
Big Data Fundamentals
rjain51
 
Intro to Big Data
Quang Nguyen
 
Azure Machine Learning
Chase Aucoin
 
What does Bob really want? Recommenders in the Cloud
Olivia Klose
 
Microsoft's New Platform
John Rymer
 
Nuts and bolts of running a popular site in the aws cloud
David Veksler
 
c-quilibrium R forecasting integration
AE - architects for business and ict
 
PostgreSQL - Object Relational Database
Mubashar Iqbal
 
Enhancing Hong Kong's Competitiveness Through Data Center and Cloud Computing...
Charles Mok
 
China Cloud Computing Presentation
Bo Hershey
 
Deployment Automation on OpenStack with TOSCA and Cloudify
Cloudify Community
 
Auto scaling websites in the cloud
David Veksler
 

Similar to Cloud Architecture best practices (20)

PDF
CloudCamp Athens presentation: Introduction to cloud computing
Fotis Stamatelopoulos
 
PDF
pertemuan-2-introduction-to-cloud.pdf
MohdLee3
 
PPTX
Big Data on Cloud Native Platform
Sunil Govindan
 
PPTX
Big Data on Cloud Native Platform
Sunil Govindan
 
PDF
Public Cloud Workshop
Amer Ather
 
PDF
Cloud-based Energy Efficient Software
Fotis Stamatelopoulos
 
PDF
Cloud comparison - AWS vs Azure vs Google
Patrick Pierson
 
PPTX
Amazon Web Services lection 6
Binary Studio
 
PPTX
Dbms
vatsaanadi
 
PPTX
Building a Just-in-Time Application Stack for Analysts
Avere Systems
 
PPTX
Introduction to amazon web services for developers
Ciklum Ukraine
 
PPTX
Ghost Environment
PratipD
 
PDF
Architecting applications in the AWS cloud
Cloud Genius
 
PDF
Study Notes - Architecting for the cloud (AWS Best Practices, Feb 2016)
Rick Hwang
 
PDF
Building Scalable Cloud Applications - Presentation at VCCF 2012
Fotis Stamatelopoulos
 
PDF
[WSO2Con Asia 2018] Architecting for Container-native Environments
WSO2
 
PDF
The future of serverless is STATE!
Ryan Knight
 
PPTX
AWS Cloud Computing Tech Talks By Halieb Andemichael
Halieb Andemichael
 
PPTX
Cloud computing benefits
Madhukumar Vattipulusu
 
PDF
AnyMind Group Tech Talk - Microservices architecture with AWS
Nhân Nguyễn
 
CloudCamp Athens presentation: Introduction to cloud computing
Fotis Stamatelopoulos
 
pertemuan-2-introduction-to-cloud.pdf
MohdLee3
 
Big Data on Cloud Native Platform
Sunil Govindan
 
Big Data on Cloud Native Platform
Sunil Govindan
 
Public Cloud Workshop
Amer Ather
 
Cloud-based Energy Efficient Software
Fotis Stamatelopoulos
 
Cloud comparison - AWS vs Azure vs Google
Patrick Pierson
 
Amazon Web Services lection 6
Binary Studio
 
Building a Just-in-Time Application Stack for Analysts
Avere Systems
 
Introduction to amazon web services for developers
Ciklum Ukraine
 
Ghost Environment
PratipD
 
Architecting applications in the AWS cloud
Cloud Genius
 
Study Notes - Architecting for the cloud (AWS Best Practices, Feb 2016)
Rick Hwang
 
Building Scalable Cloud Applications - Presentation at VCCF 2012
Fotis Stamatelopoulos
 
[WSO2Con Asia 2018] Architecting for Container-native Environments
WSO2
 
The future of serverless is STATE!
Ryan Knight
 
AWS Cloud Computing Tech Talks By Halieb Andemichael
Halieb Andemichael
 
Cloud computing benefits
Madhukumar Vattipulusu
 
AnyMind Group Tech Talk - Microservices architecture with AWS
Nhân Nguyễn
 
Ad

More from Omid Vahdaty (20)

PDF
Data Pipline Observability meetup
Omid Vahdaty
 
PPTX
Couchbase Data Platform | Big Data Demystified
Omid Vahdaty
 
PPTX
Machine Learning Essentials Demystified part2 | Big Data Demystified
Omid Vahdaty
 
PPTX
Machine Learning Essentials Demystified part1 | Big Data Demystified
Omid Vahdaty
 
PPTX
The technology of fake news between a new front and a new frontier | Big Dat...
Omid Vahdaty
 
PPTX
Big Data in 200 km/h | AWS Big Data Demystified #1.3
Omid Vahdaty
 
PDF
Making your analytics talk business | Big Data Demystified
Omid Vahdaty
 
PPTX
BI STRATEGY FROM A BIRD'S EYE VIEW (How to become a trusted advisor) | Omri H...
Omid Vahdaty
 
PPTX
AI and Big Data in Health Sector Opportunities and challenges | Big Data Demy...
Omid Vahdaty
 
PDF
Aerospike meetup july 2019 | Big Data Demystified
Omid Vahdaty
 
PPTX
ALIGNING YOUR BI OPERATIONS WITH YOUR CUSTOMERS' UNSPOKEN NEEDS, by Eyal Stei...
Omid Vahdaty
 
PPTX
AWS Big Data Demystified #1.2 | Big Data architecture lessons learned
Omid Vahdaty
 
PPTX
AWS big-data-demystified #1.1 | Big Data Architecture Lessons Learned | English
Omid Vahdaty
 
PPTX
AWS Big Data Demystified #4 data governance demystified [security, networ...
Omid Vahdaty
 
PPTX
AWS Big Data Demystified #3 | Zeppelin + spark sql, jdbc + thrift, ganglia, r...
Omid Vahdaty
 
PPTX
AWS Big Data Demystified #2 | Athena, Spectrum, Emr, Hive
Omid Vahdaty
 
PPTX
Amazon aws big data demystified | Introduction to streaming and messaging flu...
Omid Vahdaty
 
PPTX
AWS Big Data Demystified #1: Big data architecture lessons learned
Omid Vahdaty
 
PPTX
Emr spark tuning demystified
Omid Vahdaty
 
PPTX
Emr zeppelin & Livy demystified
Omid Vahdaty
 
Data Pipline Observability meetup
Omid Vahdaty
 
Couchbase Data Platform | Big Data Demystified
Omid Vahdaty
 
Machine Learning Essentials Demystified part2 | Big Data Demystified
Omid Vahdaty
 
Machine Learning Essentials Demystified part1 | Big Data Demystified
Omid Vahdaty
 
The technology of fake news between a new front and a new frontier | Big Dat...
Omid Vahdaty
 
Big Data in 200 km/h | AWS Big Data Demystified #1.3
Omid Vahdaty
 
Making your analytics talk business | Big Data Demystified
Omid Vahdaty
 
BI STRATEGY FROM A BIRD'S EYE VIEW (How to become a trusted advisor) | Omri H...
Omid Vahdaty
 
AI and Big Data in Health Sector Opportunities and challenges | Big Data Demy...
Omid Vahdaty
 
Aerospike meetup july 2019 | Big Data Demystified
Omid Vahdaty
 
ALIGNING YOUR BI OPERATIONS WITH YOUR CUSTOMERS' UNSPOKEN NEEDS, by Eyal Stei...
Omid Vahdaty
 
AWS Big Data Demystified #1.2 | Big Data architecture lessons learned
Omid Vahdaty
 
AWS big-data-demystified #1.1 | Big Data Architecture Lessons Learned | English
Omid Vahdaty
 
AWS Big Data Demystified #4 data governance demystified [security, networ...
Omid Vahdaty
 
AWS Big Data Demystified #3 | Zeppelin + spark sql, jdbc + thrift, ganglia, r...
Omid Vahdaty
 
AWS Big Data Demystified #2 | Athena, Spectrum, Emr, Hive
Omid Vahdaty
 
Amazon aws big data demystified | Introduction to streaming and messaging flu...
Omid Vahdaty
 
AWS Big Data Demystified #1: Big data architecture lessons learned
Omid Vahdaty
 
Emr spark tuning demystified
Omid Vahdaty
 
Emr zeppelin & Livy demystified
Omid Vahdaty
 
Ad

Recently uploaded (20)

PDF
67243-Cooling and Heating & Calculation.pdf
DHAKA POLYTECHNIC
 
PPTX
cybersecurityandthe importance of the that
JayachanduHNJc
 
PDF
Construction of a Thermal Vacuum Chamber for Environment Test of Triple CubeS...
2208441
 
PPTX
Chapter_Seven_Construction_Reliability_Elective_III_Msc CM
SubashKumarBhattarai
 
PDF
SG1-ALM-MS-EL-30-0008 (00) MS - Isolators and disconnecting switches.pdf
djiceramil
 
PPTX
ENSA_Module_7.pptx_wide_area_network_concepts
RanaMukherjee24
 
PDF
4 Tier Teamcenter Installation part1.pdf
VnyKumar1
 
PPTX
quantum computing transition from classical mechanics.pptx
gvlbcy
 
PPTX
Introduction to Fluid and Thermal Engineering
Avesahemad Husainy
 
PDF
20ME702-Mechatronics-UNIT-1,UNIT-2,UNIT-3,UNIT-4,UNIT-5, 2025-2026
Mohanumar S
 
PPTX
Basics of Auto Computer Aided Drafting .pptx
Krunal Thanki
 
PPTX
Precedence and Associativity in C prog. language
Mahendra Dheer
 
PPTX
Water resources Engineering GIS KRT.pptx
Krunal Thanki
 
PDF
EVS+PRESENTATIONS EVS+PRESENTATIONS like
saiyedaqib429
 
PPTX
business incubation centre aaaaaaaaaaaaaa
hodeeesite4
 
PDF
勉強会資料_An Image is Worth More Than 16x16 Patches
NABLAS株式会社
 
PDF
Biodegradable Plastics: Innovations and Market Potential (www.kiu.ac.ug)
publication11
 
PDF
Advanced LangChain & RAG: Building a Financial AI Assistant with Real-Time Data
Soufiane Sejjari
 
DOCX
SAR - EEEfdfdsdasdsdasdasdasdasdasdasdasda.docx
Kanimozhi676285
 
PPTX
MSME 4.0 Template idea hackathon pdf to understand
alaudeenaarish
 
67243-Cooling and Heating & Calculation.pdf
DHAKA POLYTECHNIC
 
cybersecurityandthe importance of the that
JayachanduHNJc
 
Construction of a Thermal Vacuum Chamber for Environment Test of Triple CubeS...
2208441
 
Chapter_Seven_Construction_Reliability_Elective_III_Msc CM
SubashKumarBhattarai
 
SG1-ALM-MS-EL-30-0008 (00) MS - Isolators and disconnecting switches.pdf
djiceramil
 
ENSA_Module_7.pptx_wide_area_network_concepts
RanaMukherjee24
 
4 Tier Teamcenter Installation part1.pdf
VnyKumar1
 
quantum computing transition from classical mechanics.pptx
gvlbcy
 
Introduction to Fluid and Thermal Engineering
Avesahemad Husainy
 
20ME702-Mechatronics-UNIT-1,UNIT-2,UNIT-3,UNIT-4,UNIT-5, 2025-2026
Mohanumar S
 
Basics of Auto Computer Aided Drafting .pptx
Krunal Thanki
 
Precedence and Associativity in C prog. language
Mahendra Dheer
 
Water resources Engineering GIS KRT.pptx
Krunal Thanki
 
EVS+PRESENTATIONS EVS+PRESENTATIONS like
saiyedaqib429
 
business incubation centre aaaaaaaaaaaaaa
hodeeesite4
 
勉強会資料_An Image is Worth More Than 16x16 Patches
NABLAS株式会社
 
Biodegradable Plastics: Innovations and Market Potential (www.kiu.ac.ug)
publication11
 
Advanced LangChain & RAG: Building a Financial AI Assistant with Real-Time Data
Soufiane Sejjari
 
SAR - EEEfdfdsdasdsdasdasdasdasdasdasdasda.docx
Kanimozhi676285
 
MSME 4.0 Template idea hackathon pdf to understand
alaudeenaarish
 

Cloud Architecture best practices

  • 1. Cloud Architecture Best practices Omid Vahdaty, Cloud Architect
  • 2. Generic Architecture questions: ● When would you cloudify? ○ opex ○ capacity unclear ○ Elasticity ○ Agility in development
  • 3. Generic Architecture questions: ● When not to cloudify? ○ Network latency ○ Long terms costs ○ Building datacenter is your business ○ Where vendor lockin is important. (offloading terabytes from Amazon??) ○ The architecture of your app is not a match to the clouds best practices. ○ Regulation? ○ Performance considerations. e.g SQream.
  • 4. Generic Architecture questions: ● When would you normalize tables? ○ eliminate redundant data, utilize space efficiently and reduce update errors. ○ in situations where we are storing immutable data such as financial transactions or a particular day's price list.
  • 5. Generic Architecture questions: ● When NOT to NORMALIZE ? ○ Could you denormalize your schema to create flatter data structures that are easier to scale? ○ When Multiple Joins are Needed to Produce a Commonly Accessed View ○ decided to go with database partitioning/sharding then you will likely end up resorting to denormalization ○ Normalization saves space, but space is cheap! ○ Normalization simplifies updates, but reads are more common! ○ Performance, performance, Performance
  • 6. Generic Architecture questions: ● NoSql advantages? ○ Non-relational and schema-less data model ○ Low latency and high performance ○ Highly scalable ○ SQL queries are not well suited for the object oriented data structures that are used in most applications now. ○ Some application operations require multiple and/or very complex queries. In that case, data mapping and query generation complexity raises too much and becomes difficult to maintain
  • 7. Generally speaking - a good architecture? ● stable / HA / DR / graceful failure ● Structure - start with skeleton, and be able to add future components. ● Loosely coupled ● Low complexity on components ● Passes all basic tests ● Use Cases matches Tradeoff of architecture (e.g scale out VS. scale up) - i.e each architecture has advantage and disadvantage ● Performance aspects. ● Maintenance aspects
  • 8. Generally speaking - a good architecture? ● Documented ● Decoupling storage and compute ● API, Services - not Servers.(PaaS VS. Iaas. ) ● TCO ● Hardware considerations ● Network considerations- AWS VS IBM - no money on private network. ● Security considerations
  • 9. Cloud Architecture Best Practices ● Scale out, Stateless, Need a dispatcher ! ■ Pull - Asynchronous event-driven workloads do not require a load balancing solution because you can implement a pull model instead. In a pull model, tasks that need to be performed or data that need to be processed could be stored as messages in a queue using Amazon Simple Queue Service (Amazon SQS) or as a streaming data solution like Amazon Kinesis. ■ Push ( like elastic load balancer or route 53 -)
  • 10. Cloud Architecture Best Practices ● Scale out, Making it stateless ○ web applications can use HTTP cookies to store information about a session at the client’s browser (e.g., items in the shopping cart). The browser passes that information back to the server at each subsequent request so that the application does not need to store it. However, there are two drawbacks with this approach. ■ First, the content of the HTTP cookies can be tampered with at the client side, so you should always treat them as untrusted data that needs to be validated. ■ Second, HTTP cookies are transmitted with every request, which means that you should keep their size to a minimum (to avoid unnecessary latency).
  • 11. Cloud Architecture Best Practices ● Scale out, Making it stateless ○ Consider storing a unique session identifier in a HTTP cookie and storing more detailed user session information server-side. Most programming platforms provide a native session management mechanism that works this way, however this is often stored on the local file system by default. This would result in a stateful architecture. A common solution to this problem is to store user session information in a database. Amazon DynamoDB is a great choice due to its scalability, high availability, and durability characteristics.
  • 12. Cloud Architecture Best Practices ● Scale out, Making it stateless ○ Other scenarios require storage of larger files (e.g., user uploads, interim results of batch processes, etc.). By placing those files in a shared storage layer like Amazon S3 or Amazon Elastic File System (Amazon EFS) you can avoid the introduction of stateful components. Another example is that of a complex multistep workflow where you need to track the current state of each execution.
  • 13. Cloud Architecture Best Practices ● Scaleout, Stateful ○ by definition, databases are stateful ○ “Sticky sessions for HTTP/s” - You might still be able to scale those components horizontally by distributing load to multiple nodes with “session affinity.” In this model, you bind all the transactions of a session to a specific compute resource. You should be aware of the limitations of this model. Existing sessions do not directly benefit from the introduction of newly launched compute nodes. More importantly, session affinity cannot be guaranteed. For example, when a node is terminated or becomes unavailable, users bound to it will be disconnected and experience a loss of session-specific data (e.g., anything that is not stored in a shared resource like S3, EFS, a database, etc.).
  • 14. Cloud Architecture Best Practices ● Elastic resources ○ Kill unused resources ○ Don't use fixed IP unless a must ○ Immutable infrastructure pattern. With this approach a server, once launched, is never updated throughout its lifetime. Instead, when there is a problem or a need for an update the server is replaced with a new one that has the latest configuration. In this way, resources are always in a consistent (and tested) state and rollbacks become easier to perform. ○ Bootstrapping
  • 15. Cloud Architecture Best Practices ● Elastic resources ○ When you launch an AWS resource like an Amazon EC2 instance or Amazon Relational Database (Amazon RDS) DB instance, you start with a default configuration. You can then execute automated bootstrapping actions. That is, scripts that install software or copy data to bring that resource to a particular state. You can parameterize configuration details that vary between different environments (e.g., production, test, etc.) so that the same scripts can be reused without modifications.
  • 16. Cloud Architecture Best Practices ● Elastic resources ○ AMI Images - faster start times and removes dependencies to configuration services or third-party repositories. This is important in auto-scaled environments ○ Convert vmware to ami ○ AWS Elastic Beanstalk and the Amazon EC2 Container Service (Amazon ECS) support Docker and enable you to deploy and manage multiple Docker containers across a cluster of Amazon EC2 instances.
  • 17. Cloud Architecture Best Practices ● Elastic resources ○ AWS Elastic Beanstalk follows the hybrid model. It provides preconfigured run time environments (each initiated from its own AMI) but allows you to run bootstrap actions (through configuration files called .ebextensions 11) and configure environment variables to parameterize the environment differences. ○ Infrastructure as code (cloud Formations): Write code to set up new environments - and keep it versioned.
  • 18. Cloud Architecture Best Practices ● Automation ○ BeansTalk - just add code, scaling, resource are taken care of automatically ○ EC2 auto recovery - coupled with cloud watch - restore to specific state ○ AutoScaling ○ Amazon CloudWatch Alarms with SNS, Those Amazon SNS messages can automatically kick off the execution of a subscribed AWS Lambda function, enqueue a notification message to an Amazon SQS queue, or perform a POST request to an HTTP/S endpoint
  • 19. Cloud Architecture Best Practices ● Automation ○ AWS OpsWorks Lifecycle events: AWS OpsWorks supports continuous configuration through lifecycle events that automatically update your instances configuration to adapt to environment changes. These events can be used to trigger Chef recipes on each instance to perform specific configuration task ○ AWS Lambda Scheduled events: These events allow you to create a Lambda function and direct AWS Lambda to execute it on a regular schedule.
  • 20. Cloud Architecture Best Practices ● API : ○ support backwards compatibility for rollback scenarios. ○ Remeber: services - not servers! ○ Auto scaling included ○ Multi AZ redundancy included
  • 21. Cloud Architecture Best Practices ● Loose coupling - As application complexity increases, a desirable attribute of an IT system is that it can be broken into smaller, loosely coupled component. services are meant to be loosely coupled, they should be able to be consumed without prior knowledge of their network topology details. Loose coupling is a crucial element if you want to take advantage of the elasticity of cloud computing where new resources can be launched or terminated at any point in time. Service discovery while maintaining Loose coupling:
  • 22. Cloud Architecture Best Practices ● Loose coupling Service discovery while maintaining Loose coupling: ○ service discovery via Elastic Load Balancing service. Because each load balancer gets its own hostname you now have the ability to consume a service through a stable endpoint. This can be combined with DNS and private Amazon Route53 zones, so that even the particular load balancer’s endpoint can be abstracted and modified at any point in time. ○ use a service registration and discovery method to allow retrieval of the endpoint IP addresses and port number of any given service. Because service discovery becomes the glue between the components, it is important that it is highly available and reliable
  • 23. Cloud Architecture Best Practices ● Loose coupling Service discovery while maintaining Loose coupling: ○ Asynchronous integrations - This model is suitable for any interaction that does not need an immediate response and where an acknowledgement that a request has been registered will suffice. It involves one component that generates events and another that consumes them. The two components do not integrate through direct point-to point interaction but usually through an intermediate durable storage layer (e.g., an Amazon SQS queue or a streaming data platform like Amazon Kinesis
  • 24. Cloud Architecture Best Practices ● Loose coupling Service discovery while maintaining Loose coupling: ○ Asynchronous integrations - This approach decouples the two components and introduces additional resiliency. So, for example, if a process that is reading messages from the queue fails, messages can still be added to the queue to be processed when the system recovers. It also allows you to protect a less scalable backend service from front end spikes and find the right tradeoff between cost and processing lag. For example, you can decide that you don’t need to scale your database to accommodate for an occasional peak of write queries as long as you eventually process those queries asynchronously with some delay. Finally, by moving slow operations off of interactive request paths you can also improve the end-user experience.
  • 25. Cloud Architecture Best Practices ● Loose coupling Service discovery while maintaining Loose coupling: ○ Graceful failure - Another way to increase loose coupling is to build applications in such a way that they handle component failure in a graceful manner. You can identify ways to reduce the impact to your end users and increase your ability to make progress on your offline procedures, even in the event of some component failure. in practice A request that fails can be retried with an exponential backoff and Jitter strategy or it could be stored in a queue for later processing. For front-end interfaces, it might be possible to provide alternative or cached content instead of failing completely when, for example, your database server becomes unavailable. The Amazon Route 53 DNS failover feature also gives you the ability to monitor your website and automatically route your visitors to a backup site if your primary site becomes unavailable. You can host your backup site as a static website on Amazon S3 or as a separate dynamic environment.
  • 26. Cloud Architecture Best Practices: Serverless ● Serverless architecture (AWS API gateway + lambda) ○ AWS Lambda allows you to write code functions, called handlers, which will execute when triggered by an event. ○ Immediate benefits: easy to maintain, decoupled, and scalable ■ No operating systems to choose, secure, patch, or manage. ■ No servers to right size, monitor, or scale out. ■ No risk to your cost by over-provisioning. ■ No performance impact by under-provisioning.
  • 27. Cloud Architecture Best Practices: Serverless ● Serverless architecture (AWS API gateway + lambda) ○ Optimizations ■ Includes by design, cloudFront in the BE to cache static requests ■ Lower latency ■ Protection against DDoS ○ You can improve the performance of specific API requests by using Amazon API Gateway to store responses in an optional in-memory cache. This not only provides performance benefits for repeated API requests, but it also reduces backend executions, which can reduce your overall cost.
  • 28. Cloud Architecture Best Practices: Databases ● If your application primarily indexes and queries data with no need for joins or complex transactions (especially if you expect a write throughput beyond the constraints of a single instance) consider a NoSQL database instead. ● If you have large binary files (audio, video, and image), it will be more efficient to store the actual files in the Amazon Simple Storage Service (Amazon S3) and only hold the metadata for the files in your database.
  • 29. Cloud Architecture Best Practices: Databases ● Use read replicas to increase read performance ● Use aurora instead of mysql ● If your schema cannot be denormalized consider a relational database instead of noSQL
  • 30. Cloud Architecture Best Practices: HA ● You should aim to build as much automation as possible in both detecting and reacting to failure. You can use services like ELB and Amazon Route53 to configure health checks and mask failure by routing traffic to healthy endpoints. In addition, Auto Scaling can be configured to automatically replace unhealthy nodes. You can also replace unhealthy nodes using the Amazon EC2 auto recovery feature or services such as AWS OpsWorks and AWS Elastic Beanstalk ● Asynchronous replication decouples the primary node from its replicas at the expense of introducing replication lag. This means that changes performed on the primary node are not immediately reflected on its replicas. Asynchronous replicas are used to horizontally scale the system’s read capacity for queries that can tolerate that replication lag. It can also be used to increase data durability when some loss of recent transactions can be tolerated during a failover.
  • 31. Cloud Architecture Best Practices: HA ● Quorum-based replication combines synchronous and asynchronous replication to overcome the challenges of large-scale distributed database systems. Replication to multiple nodes can be managed by defining a minimum number of nodes that must participate in a successful write operation
  • 32. Cloud Architecture Best Practices: DR ● Because of the long distance between the two data centers, latency makes it impractical to maintain synchronous cross-datacenter copies of the data. As a result, a failover will most certainly lead to data loss or a very costly data recovery process. ● Each Availability Zone is engineered to be isolated from failures in other Availability Zones. An Availability Zone is a data center. Availability Zones within a region provide inexpensive, low-latency network connectivity to other zones in the same region ● In fact, many of the higher level services on AWS are inherently designed according to the Multi-AZ principle
  • 33. Cloud Architecture Best Practices: DR ● Because of the long distance between the two data centers, latency makes it impractical to maintain synchronous cross-datacenter copies of the data. As a result, a failover will most certainly lead to data loss or a very costly data recovery process. ● Each Availability Zone is engineered to be isolated from failures in other Availability Zones. An Availability Zone is a data center. Availability Zones within a region provide inexpensive, low-latency network connectivity to other zones in the same region ● In fact, many of the higher level services on AWS are inherently designed according to the Multi-AZ principle
  • 34. Cloud Architecture Best Practices: cost reduction ● User serverless when possible - don't pay for idle. ● Monitoring size of compute ● Turn off unused workloads ● Auto scaling ● Purchasing options - reserved etc. ● Applications can be designed so that they store and retrieve information from fast, managed, in- memory caches ● Edge caching - cloudFront (CDN), S3
  • 35. Stay in touch... ● Omid Vahdaty ● +972-54-2384178