Embed Size (px)
Citation preview
Architecting for the Cloud
• Trusted advisor for enterprises moving to cloud
• 50+ Enterprise Clients – Many F250
• 150+ Engagements – All Referenceable
• Preferred AWS Partner
• Architect and developer experience >20 years
• Proprietary software to accelerate cloud adoption
Cloud Technology Partners at a Glance:
We’re the cloud application and infrastructure experts behind some
of the world’s most advanced cloud computing initiatives.
“Working with Cloud Technology
Partners helps us continually
deliver some of the most
sophisticated, dependable and
secure cloud solutions available
in the market.”
- John Igoe, VP Cloud Security &
Operations
It’s a new world for applications…
They are…
• Built to run in a single data center
• On servers you control
• And a infrastructure that you pre-provision for peak capacity
Which is expensive
• Using a centralized database
• Where availability relies on resilient infrastructure
• Often in monolithic code blocks with hard-coded
dependencies between functions
The trouble with pre-cloud applications
Out with the old, in with the new…
AssumptionsArchitectureOperations
Assumptions… what your mother said…
• Infrastructure is resilient
• Infrastructure is pre-provisioned
• Infrastructure drives scaling
• Disaster / recovery methods are sound
• Infrastructure is “variable”
• Infrastructure is elastic
• Applications drive scaling
• Continuous availability is the goal (no disaster)
Architecture is different
• Monolithic apps are not great, but they work
• Functions that are highly dependent are co-located
• Application portability is hard
• Applications are operated by I&O teams
• Micro services are they way, even if complex
• Functionality should be widely distributed
• Application portability is easy (with Docker)
• Services are operated by developers
Operations. Word.
• A VM is a VM is a VM
• Servers are pets
• BAU can work in cloud
• Applications run in a data center
• Clouds are like snowflakes
• Servers are cattle
• Most of what you do will change
• Applications span data centers, regions, borders
At your (micro) Service..
Micro services = SOA
Assemble services, not componentsBe asynchronous until you can’tMicro services increase agility, and complexity
Horizontal scaling is critical, and hard
The importance of being small
Predictability requires testing and tuning
Where is state managed
When bad things happen to good VMs
Resilience – when applications own it
When the application owns its resilience, infrastructure can be less expensive…
Globally distributed
Putting the application and the data where the customers live and work
Are…
• Built to run across data center, geographies, etc.
• On servers in the cloud
• That you provision when you need them and kill when you
don’t
• Using a distributed cloud database
• Where availability is built in
• Using micro-services, RESTful interfaces
Cloud applications
Architecting for the Cloud
Seth Proctor, CTO@technicallyseth
Confidential and Proprietary
What’s unique about “cloud”?
Cloud architecture
On-demandScale-out for capacity & availability
Public infrastructure; dynamic provisioning
FlexibleCommodity
Hybrid (public & private)
SimpleMonitoring & management
Platform APIs and automation
Resilient
Why a different architecture?
Greater capacity
Cost-effectiveness
Higher availability and better failure-handling
Lower latencies for global deployment
Challenges
Distribution brings challengesLots of failures happen with frequency
More difficult to get a global view
Security & data lifecycle is harder
Everything else about “distributed computing”
Still, we can scale most layersLoad-balancers & name services at the top
Horizontally-scaled app servers
Caches & CDNs for content
Redundant disks and object stores
Scaling the database is the real challenge
Traditional database design
RDBMS architectures start at the diskVertical scale follows
Caching helps, but often breaks consistency
HA systems become very expensive
Schema & operation is hard to evolve
Hard to harness commodity infrastructure
Not designed to scale-out
Common options
ReplicationActive-passive or (gulp) multi-master
Replicated data but visible delays & conflict
ShardingSplit one database into many sub-sets
More capacity but hard to evolve and relate
Abandon consistencyPush correctness & conflict to the application
Simpler core architecture but painful for applications and hard to reconcile failures
Side-effects
Applications are tied to deploymentHence, dev-ops
Complex for on-demand changes, failures
More, independent pieces
Harder to interpret failures
Complexity
Global deployment
Many motivationsDisaster Recovery
Lower-latency for distributed users
Data access & storage residency rules
Trade-offs between latencies and safety
Storage may be a separate concern from interaction
Approach Shared DiskShared-
Nothing/ShardedDurable
Distributed Cache
Key Idea Sharing a file system.Independent databases for disjoint subsets of data.
Replicating data in memory on-demand.
Topology
ExampleOracle RAC
DB2 Pure Scale
MySQL Clusterand most NoSQL/NewSQL
solutions
Distributed Database Designs
*Note: Most major web properties include custom-sharded MySQL or sharded PostgreSQL, including Facebook, GOOGLE, Wikipedia, Amazon, Flickr, Box.net, and Heroku.
27
Peer to Peer Architecture
P
P P
S3Disk, ...
P
P NuoDB Database Peer Process
Provisioned, Manageable Resources
Peer to Peer Communications
SQL Client
Management Client
SQL Front-EndSQL Optimizer
Transaction Handling
Object CachingObject Coordination
Durability
P
Magic Quadrant 2013
About NuoDB
Magic Quadrant 2013 & 2014
NuoDB delivers a distributed SQL database management system specifically designed for the cloud and the modern datacenter.
Magic Quadrant 2013
Summary
When architecting for the cloud..Look for distributed architectures with on-demand capabilities
Layer & abstract to support evolution and react gracefully to failures
Assume your needs will evolve; plan with scale in mind
Please try out NuoDB!http://dev.nuodb.com
Thank you!
