SOA SUCKSFIX IT WITH “MISSIONS” AND FATDB
Justin Weiler, CTO, FatCloud
AGENDA
• Challenges of building a web scale application
• Essential ingredients of any web scale application
• Shortcomings of N-Tier and SOA and the real cost of
“glue”
• “Mission” Oriented Architecture and FatDB as one solution
• Wrap-up and questions
THE PROBLEM
WHAT’S SO HARD ABOUT DOING IT RIGHT?• Configuration and Maintenance• Uniformity and Complexity• Scaling, Upgrades, and Downtime• Pivoting and Extensibility• Latency and Performance• Single Points of Failure and Bottlenecks• Fault Tolerance and High Availability
• Data Consistency• Synchronization• Legacy Integration / SQL• Portability and Lock-in• Telemetry• Security• TCO & TTM
Configuration & MaintenanceUniformity & ComplexityScaling, Upgrades & DowntimePivoting & ExtensibilityLatency & PerformanceSingle Points of Failure & BottlenecksFault Tolerance & High AvailabilityData ConsistencySynchronizationLegacy Integration / SQLPortability & Lock-inTelemetrySecurityTCO & TTM
THE ESSENTIAL INGREDIENTS• Store, retrieve, cache, and query object data• Store, retrieve, and query file data• Host synchronous business logic• Host asynchronous batch job business logic• High performance, scalable, consistent, and fault tolerant plumbing• Comprehensive management tooling• Full SQL integration• Portable• Easy to use
AN OLD ARCHITECTURE
3-Tier Monoliths and Beefy Hardware
Typically:•Rigid and Brittle•Hard to Scale•High Latency and Bottlenecks•High Hardware and Maintenance Costs•Low learning curve
PRESENTATION
LOGIC
Relational DB
WHAT IS NOSQL?A NoSQL (Not Only SQL) database provides a mechanism for storage and retrieval of data that employs less constrained consistency models than traditional relational databases. Motivations for this approach include simplicity of design, horizontal scaling and finer control over availability. (Source: Wikipedia)
• Distributed computing – scale out versus scale up• Fault tolerance through mirroring/replication• Ability to be schema-less and handle unstructured data• Eventually consistent as opposed to fully consistent• Several approaches – Key Value, Document, Graph etc
NOSQL STRENGTHS AND WEAKNESSES
StrengthMulti-node scalability
WeaknessInstantaneous data consistency
Source: Data Access for Highly-Scalable Solutions: Using SQL, NoSQL, and Polyglot Persistence
A MORE MODERN ARCHITECTUREA-La-Carte SOA with Costly Glue
Typically:• More Scalable & Flexible• Lower Upfront Costs• Low Synergy• Still Hard to Scale• Still High Latency• Impedance Mismatches• High Integration Costs• Long Learning Curve• High Maintenance Costs• PaaS Better, but Lock-In
PRESENTATION
SERVICE 2
Message Q
SERVICE 1
NoSQL
= Mongo + RabbitMQ + Hadoop + Cassandra + Memcached
Multiple GUI’sMultiple technologiesDifficult learning curveLinux is primary O/SWindows is secondaryO/S if at all
SYSTEMS INTEGRATION PAIN: TOO MANY GUI’S
RECIPE FOR EASY SCALING
•Think holistically (NoSQL is just the beginning)•Traffic and Data analysis•Test and meter•Provide ALL the essentials (NoSQL, Files, Sync, Async)
–Leverage an extensible, integrated platform–Maximize existing investments (WCF, SQL)
•Organize “missions” rather than services•Concentrate on your business logic
FATDB PLATFORM STANDARD FEATURE SETASYNC WORK QUEUE & PROCESSORSAsynchronous job processing, able to handle “big data” problems. Utilizes your business logic created as FatProcs
FILE MANAGEMENT SYSTEMFlexible storage of file-based assets across the cloudNoSQL DATABASE &
CACHEDocument or key-value store (stand-alone DB and can be easily integrated with SQL)
High performance in-memory distributed cache (IMDG)
APPLICATIONSSupport for your custom and community synchronous applications or business logic created as FatApps
CORE FOUNDATIONTransparently provides the distributed plumbing for routing, redundancy, fault tolerance, data consistency, synchronization, and service discovery
THE FATDB ARCHITECTUREMission Oriented Architecture (MOA) on an Integrated Platform
Typically:• High Scalability• High Flexibility• High Synergy• Low Latency• Low Impedance• Low Integration Costs
PRESENTATION
GROUP 2PRODUCTS
GROUP 1CONSUMERS
GROUP 3ORDERS
• Short Learning Curve• Low Maintenance Costs• Portable
MISSION = BUSINESS LOGIC + RELATED DATA
MISSION = TEMPLATE FOR EVERY SERVER
WHAT IS POLYGLOT PERSISTENCE?
Polyglot Persistence, like polyglot programming, is all about choosing the right persistence option for the task at hand. Scott Leberknight
Different databases are designed to solve different problems. Using a single database engine for all of the requirements usually leads to non- performant solutions.Martin Fowler
Polyglot Persistence is about using hybrid storage approach (RDBMS, NOSQL,BLOB,FILE) that allows you to use the best tool for the job versus being locked into one approach.FatCloud
POLYGLOT DATA STORE: SQL WITH FATDB
SQL Server
Invoice024
Invoice175
Invoice832
Invoice936
Invoice492
Invoice751
Invoice595
Invoice037
Invoice275
Invoice024
Invoice175
Invoice832
Invoice936
Invoice492
Invoice751
Invoice595
Invoice037
Invoice275
FatDB Server Cluster
Invoice832
Invoice492
Invoice751
Invoice275
Invoice037
Invoice175
Invoice024
Invoice936
Invoice595Invoice
832Invoice
492
Invoice751
Invoice275
Invoice037
Invoice175
Invoice024
Invoice936
Invoice595Invoice
832Invoice
492
Invoice751
Invoice275
Invoice037
Invoice175
Invoice024
Invoice936
Invoice595
Web / Mobile or other Client appCalls for relational and
transactional dataCalls for unstructuredand scale sensitive data
Data Driven Request Routing
SQL Server FatDB Server Cluster
Invoice024
Invoice175
Invoice832
Invoice936
Invoice492
Invoice751
Invoice595
Invoice037
Invoice275
Invoice832
Invoice492
Invoice751
Invoice275
Invoice037
Invoice175
Invoice024
Invoice936
Invoice595Invoice
832Invoice
492
Invoice751
Invoice275
Invoice037
Invoice175
Invoice024
Invoice936
Invoice595Invoice
832Invoice
492
Invoice751
Invoice275
Invoice037
Invoice175
Invoice024
Invoice936
Invoice595
Invoice024
Invoice175
Invoice832
Invoice936
Invoice492
Invoice751
Invoice595
Invoice037
Invoice275
Automate routine synchronization tasks for effortless data consistency.
1. Changes to SQL Server automatically sent to FatDB
2. Changes to FatDB automatically sent to SQL Server
SQL Write Back
Automatic Synchronization
POLYGLOT DATA STORE: SQL WITH FATDB
EXAMPLE OF A POLYGLOT DATA STORE
SQL Server
FatDB Server Cluster (In house or In cloud)
Invoice832
Invoice492
Invoice751
Invoice275
Invoice037
Invoice175
Invoice024
Invoice936
Invoice595
Invoice832
Invoice492
Invoice751
Invoice275
Invoice037
Invoice175
Invoice024
Invoice936
Invoice595
Invoice832
Invoice492
Invoice751
Invoice275
Invoice037
Invoice175
Invoice024
Invoice936
Invoice595
Invoice024
Invoice175
Invoice832
Invoice936
Invoice492
Invoice751
Invoice595
Invoice037
Invoice275
Invoice024
Invoice175
Invoice832
Invoice936
Invoice492
Invoice751
Invoice595
Invoice037
Invoice275
New Web AppMobile Clients
Legacy Apps BI & Reporting1 5
2 4
31.Legacy apps continue
unchanged updating SQL Server
2.Changes in SQL Server are transmitted to FatDB
3.FatDB is accessed by mobile, web, cloud clients delivering scale and fault tolerance
4.Updates to FatDB are transmitted back to SQL Server
5.BI and Reporting tools can continue accessing SQL Server as an accurate data repository
WHY FATDB OR A SIMILAR TECHNOLOGY?
Do you want this…
WHY FATDB OR A SIMILAR TECHNOLOGY?
• Reduces complexity• Decreases risk• Enhances flexibility
and portability• Increases
performance• Faster TTM• Leverages existing
investments• Lower TCO
PRESENTATION
GROUP 2PRODUCTS
GROUP 1CONSUMERS
GROUP 3ORDERS
…or this?
One GUIOne set of API’sEasy learning curveWindows basedManage servers,Databases, fileSystems, work queue and apps from one tool
FATDB MANAGEMENT STUDIO: A SINGLE PANE OF GLASS
KICKING THE TIRES…
• Community edition is FREE!
• Installer, tutorials, code, and whitepapers available at www.fatcloud.com
• POC program