Cambridge Breakfast Seminar
•Als PPTX, PDF herunterladen•
1 gefällt mir•513 views
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
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (19)
Andere mochten auch
Andere mochten auch (18)
Ähnlich wie Cambridge Breakfast Seminar
Ähnlich wie Cambridge Breakfast Seminar (20)
Mehr von NuoDB
Mehr von NuoDB (18)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Cambridge Breakfast Seminar
- 1. Architecting for the Cloud
- 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
- 4. It’s a new world for applications…
- 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
- 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…
- 14. Globally distributed Putting the application and the data where the customers live and work
- 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
- 18. What’s unique about “cloud”?
- 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
- 22. Scaling the database is the real challenge
- 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
- 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
- 33. Thank you!
Hinweis der Redaktion
- 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.