cambridge breakfast seminar

Architecting for the Cloud

March 5, 2015

John Treadway, SVP / 617-290-3955 / John.Treadway@cloudtp.com

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

March 5, 2015

John Treadway, SVP / 617-290-3955 / John.Treadway@cloudtp.com

Questions?

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!