Architecture 101 for Mobile Backend Developers on Azure
This is a presentation I did for Xamarin Istanbul Meetup group summarizing some architecture options, matching Azure services and products that mobile projects might incorporate as part of their back-end development effort.
Portability between cloud and on-premises, and between cloud platforms. • Easy to end up with a middle tier that just does CRUD operations on the database, adding extra latency without doing any useful work.
than infrastructure as a service (IaaS). • Relatively simple architecture that is easy to understand. • Easy to deploy and manage. • Clear separation of concerns. • The front end is decoupled from the worker using asynchronous messaging. • The front end and the worker can be scaled independently. • Without careful design, the front end and the worker can become large, monolithic components that are difficult to maintain and update.
which can be managed by a small development team. • Services are responsible for persisting their own data or external state. This differs from the traditional model, where a separate data layer handles data persistence. • Services communicate with each other by using well-defined APIs. Internal implementation details of each service are hidden from other services. • Services don’t need to share the same tech stack, libraries or frameworks.
in a queue for asynchronous processing, rather than being processed synchronously. • Queries never modify the database. A query returns a DTO that does not encapsulate any domain knowledge. • When the read and write workloads are asymmetrical. • Apply CQRS only to those subsystems where • there is clear value in separating reads / writes.
Complex event processing, such as pattern matching or aggregation over time windows. • Producers and consumers are decoupled. • Highly scalable and distributed. • Processing events in order or exactly once. Are you idempotent?
Cache / Cosmos DB (Key/Value) • Document and Graph (CosmosDB) • Column Family (HBase in HDInsight) • Search Engine Database (Azure Search) • Time Series Database (Time Series Insights) • Object Storage (Blobs)
schemas are required and enforced. • Many-to-many relationships between data entities in the database. • Constraints are defined in the schema and imposed on any data in the database. • Data requires high integrity. Indexes and relationships need to be maintained accurately.
schemas are required and enforced. • Many-to-many relationships between data entities in the database. • Constraints are defined in the schema and imposed on any data in the database. • Data requires high integrity. Indexes and relationships need to be maintained accurately.
• Insert and update operations are common. Both the creation of new records and updates to existing data happen regularly. • No object-relational impedance mismatch. Documents can better match the object structures used in application code. • Optimistic concurrency is more commonly used. • Each document type can use its own schema. • Individual documents are retrieved and written as a single block. • Document data is semi-structured, meaning that data types of each field are not strictly defined.
using a single ID key, like a dictionary. • Massively scalable. • No joins, lock or unions are required. • No aggregation mechanisms are used. • Data size tends to be large. • Each key is associated with a single value, which is an unmanaged data BLOB. • There is no schema enforcement. • No relationships between entities.
complex, involving many hops between related data items. • The relationship between data items are dynamic and change over time. • Relationships between objects are first-class citizens, without requiring foreign-keys and joins to traverse. • Data is comprised of nodes and relationships. • Relationships are just as important as nodes and are exposed directly in the query language. • Composite objects, such as a person with multiple phone numbers, tend to be broken into separate, smaller nodes, combined with traversable relationships.
services. • Queries are ad hoc and can be complex. • Requires aggregation. • Full text search is required. • Ad hoc self-service query is required. • Data analysis with index on all fields is required.
are writes. • Records are generally appended sequentially in time order. • Updates are rare. • Deletes occur in bulk and are made to contiguous blocks or records. • Read req • A time stamp that is used as the primary key and sorting mechanism. • Measurements from the entry or descriptions of what the entry represents.uests can be larger than available memory.
resource-intensive tasks • Use built-in autoscaling features • Clients/consumers of a service should support transient fault handling and retry. • For long-running tasks, consider breaking up the work, using checkpoints or the Pipes and Filters pattern. • Put work items in a queue so that another instance can pick up the work, if an instance is removed in the middle of processing.
to synchronise state • Consider patterns such as CQRS and event sourcing • Design idempotent operations. • Use asynchronous parallel processing • Use optimistic concurrency when possible
daronyondem
yabakokobayashi
kutsushitaneko
coosuke
nenonaninu
matthewlujp
iidaxs
taichinakamura
tsukuha
oguressive
fujisawaryohei
fujiwara3
ytaka23
brad_frost
philnash
garrettdimon
paulrobertlloyd
thekraken
dougneiner
holman
danielanewman
skipperchong
mclloyd
mongodb
chrislema
