Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Cambridge Breakfast Seminar

363 views

Published on

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

Published in: Software
  • Be the first to like this

Cambridge Breakfast Seminar

  1. 1. Architecting for the Cloud
  2. 2. March 5, 2015 John Treadway, SVP / 617-290-3955 / John.Treadway@cloudtp.com Architecting for the Cloud
  3. 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. 4. It’s a new world for applications…
  5. 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. 6. Out with the old, in with the new… Assumptions Architecture Operations
  7. 7. 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)
  8. 8. 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
  9. 9. 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
  10. 10. At your (micro) Service.. Micro services = SOA Assemble services, not components Be asynchronous until you can’t Micro services increase agility, and complexity
  11. 11. 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
  12. 12. Resilience – when applications own it When the application owns its resilience, infrastructure can be less expensive…
  13. 13. Globally distributed Putting the application and the data where the customers live and work
  14. 14. 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
  15. 15. March 5, 2015 John Treadway, SVP / 617-290-3955 / John.Treadway@cloudtp.com Questions?
  16. 16. Architecting for the Cloud Seth Proctor, CTO @technicallyseth Confidential and Proprietary
  17. 17. What’s unique about “cloud”?
  18. 18. 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
  19. 19. Why a different architecture? Greater capacity Cost-effectiveness Higher availability and better failure- handling Lower latencies for global deployment
  20. 20. 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
  21. 21. Scaling the database is the real challenge
  22. 22. 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
  23. 23. 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
  24. 24. Side-effects Applications are tied to deployment Hence, dev-ops Complex for on-demand changes, failures More, independent pieces Harder to interpret failures Complexity
  25. 25. 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
  26. 26. 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
  27. 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-End SQL Optimizer Transaction Handling Object Caching Object Coordination Durability P
  28. 28. 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
  29. 29. 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
  30. 30. Thank you!

×