During the “Architecting for the Cloud” breakfast seminar where we discussed the requirements of modern cloud-based applications and how to overcome the confinement of traditional on-premises infrastructure.
We heard from data management practitioners and cloud strategists about how organizations are meeting the challenges associated with building new or migrating existing applications to the cloud.
Finally, we discussed how the right cloud-based architecture can:
- Handle rapid user growth by adding new servers on demand
- Provide high performance even in the face of heavy application usage
- Offer around-the-clock resiliency and uptime
- Provide easy and fast access across multiple geographies
- Deliver cloud-enabled apps in public, private, or hybrid cloud environments
2. March 5, 2015
John Treadway, SVP / 617-290-3955 / John.Treadway@cloudtp.com
Architecting for the Cloud
3. • 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
5. 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
6.
7. Out with the old, in with the new…
Assumptions
Architecture
Operations
8. 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)
9. 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
10. 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
11. At your (micro) Service..
Micro services = SOA
Assemble services, not components
Be asynchronous until you can’t
Micro services increase agility, and complexity
12. 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
13. Resilience – when applications own it
When the application owns its
resilience, infrastructure can be
less expensive…
15. 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
16. March 5, 2015
John Treadway, SVP / 617-290-3955 / John.Treadway@cloudtp.com
Questions?
17. Architecting for the Cloud
Seth Proctor, CTO
@technicallyseth
Confidential and Proprietary
19. Cloud architecture
On-demand
Scale-out for capacity & availability
Public infrastructure; dynamic provisioning
Flexible
Commodity
Hybrid (public & private)
Simple
Monitoring & management
Platform APIs and automation
Resilient
20. Why a different architecture?
Greater capacity
Cost-effectiveness
Higher availability and better failure-
handling
Lower latencies for global
deployment
21. Challenges
Distribution brings challenges
Lots 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 layers
Load-balancers & name services at the top
Horizontally-scaled app servers
Caches & CDNs for content
Redundant disks and object stores
23. Traditional database design
RDBMS architectures start at the disk
Vertical 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
24. Common options
Replication
Active-passive or (gulp) multi-master
Replicated data but visible delays & conflict
Sharding
Split one database into many sub-sets
More capacity but hard to evolve and relate
Abandon consistency
Push correctness & conflict to the application
Simpler core architecture but painful for
applications and hard to reconcile failures
25. Side-effects
Applications are tied to deployment
Hence, dev-ops
Complex for on-demand changes, failures
More, independent pieces
Harder to interpret failures
Complexity
26. Global deployment
Many motivations
Disaster 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
27. Approach Shared Disk
Shared-
Nothing/Sharded
Durable
Distributed Cache
Key Idea Sharing a file system.
Independent databases for
disjoint subsets of data.
Replicating data in memory on-
demand.
Topology
Example
Oracle RAC
DB2 Pure Scale
MySQL Cluster
and 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
28. 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-End
SQL Optimizer
Transaction Handling
Object Caching
Object Coordination
Durability
P
29.
30.
31. 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
32. 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
Our technical founder, Jim Starkey, spent a lot of time thinking deeply about the challenges associated with traditional relational database architectures. They’ve been good at vertical scale – scaling up - but not so good at scale-out problems; the kind associated with cloud scale and webscale. And what he ended up with is a rich architecture.
What you have in front of you is a high-level and abstract that captures some of the key elements of what makes NuoDB’s architecture different.
First of all, what’s very important about NuoDB architecture is that it is a pure peer-to-peer architecture. There is no single coordinator. There is no special host. There’s no notion of some nodes being active and other nodes being passive or being read-only replicas.
From the application developer’s point of view, there’s no notion of sharding. There’s no notion of kind of explicit partition sets. It is a peer-to-peer architecture that presents what looks like a single logical database. We will talk, over the next few slides, about the advantages you get from a pure peer-to-peer architecture. But obviously, this architecture is how we can do things around horizontal scale and the agile, on-demand nature that the cloud wants.
So NuoDB is a peer network of that executable process running in multiple locations. And within that peer process the bits are there to do three different important groups of work. And NuoDB is a relational database, right? But it’s not a relational file structure. that’s what’s important about this picture.
First there is a front end, that understands the SQL dialect, understands how to talk to SQL clients, does traditional tasks like SQL optimization, and knows how to do transactional handling within the rules of atomicity, consistency, and isolation.
Then there is that the second tier, that dark gray tier, which is how the peers coordinate. The peers coordinate not in a structure that looks like SQL but something that looks more like a distributed-object system.
They represent database content or indexed data, schema data, metadata. In fact, the distributed name service that’s used to resolve these objects is itself encoded in this object scheme. So internally, we’re not sharing information about particular statements that are running or row-level information. We’re extracting it into these objects. When we talk about the durability tier, we’re really not talking about writing something to the disk that looks like a traditional database, in terms of something that’s page oriented or something that has a transaction log. What we’re really writing is essentially just a collection of these objects. And so we really look at storage as being a key/value store. In fact, when you look at our default mode, we can address just any POSIX file system whether it’s a local or remote file system.
So customers can take our product and put it in the Amazon cloud and use S3 as their durability point, if they want. Obviously, there’s also a journal to help with latency and recovery properties. But NuoDB is very flexible in terms of storage. And as a result, it’s also kind of decoupled from traditional concerns like how many IOPS can you pump through the storage layer or what you can get in terms of database performance overall.
Then when you think about schema definition - say what a table looks like - in NuoDB that is not defined by how we lay out information on disk. It’s just defined by one object out of thousands that map between that SQL representation and that internal object representation. This means you can evolve schema without having to affect the operations of your database and without having to have your application developers pay a big penalty for it. Change a column; re-name a column; etc., all easy and on the fly.
Then there’s the 3rd group of objects. As you know traditional RDBMS are hard to manage and hard to deploy. So we’ve built into NuoDB a first-class part of the system that is not about the database, not about SQL, not about the transactions, not about the contents of the database, but about the systems administration or operations experience.
That’s the management box you see here.
See the dashed boxes here. We’ve taken the cloud notion of provisioning and put it as a first-class component of the system. Essentially when you install NuoDB software for the first time, you’re not starting a database. What you’re doing is you’re provisioning a host. You’re making it available in the pool of resources for running whatever database or databases are you need.
Also any NuoDB database can be running on a heterogeneous network, of different OSs, different classes of machines. You can have one machine that’s faster or has more memory or whatever. Because the way that NuoDB load balancing works, it will just give the bigger machines more work. So it’s very much a cloud-style environment. Give us what you’re got and we’ll use it.
Hello, I am __________________. Thank you meeting with me today. Our goal in this meeting is _____________________
Let’s get started.
Here’s a quick introduction of NuoDB.
What makes us different? Geo-distribution. The unique ability to deploy a single, logical in multiple locations simultaneously. We will discuss this further in a moment.
The product has won numerous awards – over a dozen – since first becoming available in January 2013. Here’s a few.
And we have several thousand developers using our free edition. Plus…..(move to next slide)… what we call deep database DNA.