Distributed Systems
Distributed computing is a field of computer science that studies distributed systems. A distributed system is a system whose components are located on different networked computers, which then communicate and coordinate their actions by passing messages to each other. The components interact with each other in order to achieve a common goal. Three significant characteristics of distributed systems are: concurrency of components, lack of a global clock, and independent failure of components. Examples of distributed systems vary from SOA-based systems to massively multiplayer online games to peer-to-peer applications.
A computer program that runs within a distributed system is called a distributed program (and distributed programming is the process of writing such programs). There are many different types of implementations for the message passing mechanism, including pure HTTP, RPC-like connectors and message queues.
A goal or challenge pursued by some computer scientists and practitioners in distributed systems is location transparency; however, this goal has fallen out of favor in industry. As distributed systems are a different concept from conventional non-distributed systems, the differences, such as network partitions, partial system failures, and partial upgrades, cannot simply be "papered over" by attempts at "transparency" (see CAP theorem).
Source: https://en.wikipedia.org/wiki/Distributed_computing
Position on the Adoption Curve
Presentations about Distributed Systems
No Microservice Is an Island
Debugging Microservices: How Google SREs Resolve Outages
Debugging Microservices: How Google SREs Resolve Outages
Chick-Fil-A: Milking the Most Out of 1000's of K8s Clusters
Chick-Fil-A: Milking the Most Out of 1000's of K8s Clusters
Forced Evolution: Shopify's Journey to Kubernetes
Complex Event Flows in Distributed Systems
Efficient Fault Tolerant Java with Aeron Clustering
Canopy: Scalable Distributed Tracing & Analysis @Facebook
Canopy: Scalable Distributed Tracing & Analysis @Facebook
Modeling the Real World With Elixir/OTP
Next Gen Networking Infrastructure With Rust
Large Scale Architectures Panel
Large Scale Architectures Panel
Large Scale Architectures Panel
Large Scale Architectures Panel
Large Scale Architectures Panel
Large Scale Architectures Panel
Large Scale Architectures Panel
Heretical Resilience: To Repair is Human
Help! I Accidentally Distributed My System!
Help! I Accidentally Distributed My System!
Platforms at Twilio: Unlocking Developer Effectiveness
Interviews
Debugging Microservices: How Google SREs Resolve Outages
What is the work that you do today as a Google SRE?
Adam: I work for a Google DevOps team that takes care of Monarch. Monarch is a very large time series database used for querying and metrics collection. Monarch is roughly the internal equivalent of combining Prometheus, Grafana, and Graphite from the open source world. Monarch also adds to that stack all of Stackdriver and provides the backend for a lot of our cloud signals product. My role is an SRE-SWE which means I'm involved in the software engineering side as well. So a lot of my time is spent taking apart Monarch and putting it back together more durably and more reliably. Durability is especially important because Monarch is a globally distributed system (it runs in every single availability zone).
Can you give me an idea of the scope and size we’re talking about with Monarch?
Adam: I can’t be specific, but it’s very large in terms of both QPS and resources. The quantity of data per stream is extremely variable in size, from periodically receiving one byte, to receiving a constant stream of high-cardinality data. The same applies to the query side, where some queries need only fetch a single stream, and some need to fetch and aggregate a lot of them. Some consumers are doing ad hoc queries, and other teams are doing a tremendous number of queries per second to inform their actual customer facing products. Without Monarch, we have no monitoring or alerting, so it’s a critical system.
See more interviews
