Pat Helland (Salesforce)
Applications have had an interesting evolution as they have moved into the distributed and scalable world. Similarly, storage and its cousin databases have changed side by side with applications. Many times, the semantics, performance, and failure models of storage and applications do a subtle dance as they change in support of changing business requirements and environmental challenges. Adding scale to the mix has really stirred things up. This article looks at some of these issues and their impact on systems.
Before database transactions, there were complexities in updating data, especially if failures happened. This held true even though the systems were centralized and avoided the complexities presented by distribution. Database transactions dramatically simplified the life of application developers. It was great while it lasted…
As solutions scaled beyond a single database, life got ever more challenging. First, we tried to make multiple databases look like one database. Then, we were hooking multiple applications together using SOA (service-oriented architecture). In SOA, each service had its own discrete database with its own transactions but used messaging to coordinate across boundaries. Soon, we were using microservices, each of which likely did not have its own data but reached directly to a distributed store shared across many separate services. This scaled better—if you got the implementation right.
Different types of distributed stores offer various average speeds, variation in responsiveness, capacity, availability, and durability. Diverse application patterns use the stored data for distinct purposes. They provide various guarantees to their users based largely on their use of storage. These different guarantees from the app sometimes show variations in what the users see in semantics, response time, durability, and more. While these can be surprising, it may be OK. What matters is the fulfillment of the business needs and clarity of expectations.
This article provides a partial taxonomy of diverse storage solutions available over a distributed cluster. Part of this is an exploration of the interactions among different features of a store. The article then considers how distinct application patterns have grown over time to leverage these stores and the business requirements they meet. This may have surprising implications.
Pat Helland has been working in distributed systems, databases, transaction processing, scalable systems, and fault tolerance since 1978. For most of the 1980s, Pat worked at Tandem Computers as the Chief Architect for TMF (Transaction Monitoring Facility), the transaction and recovery engine under NonStop SQL. After 3+ years designing a Cache Coherent Non-Uniform Memory Multiprocessor for HaL Computers (a subsidiary of Fujitsu), Pat moved to the Seattle area to work at Microsoft in 1994. There he was the architect for Microsoft Transaction Server, Distributed Transaction Coordinator, and a high performance messaging system called SQL Service Broker, which ships with SQL Server. From[masked], he was at Amazon working on the product catalog and other distributed systems projects including contributing to the original design for Dynamo. After returning to Microsoft in 2007, Pat worked on a number of projects including Cosmos, the scalable “Big Data” plumbing behind Bing. While working on Cosmos, Pat architected both a project to integrate database techniques into the massively parallel computations as well as a very high-throughput event processing engine. Since early 2012, Pat has worked at Salesforce.com in San Francisco. He is focusing on multi-tenanted database systems, scalable reliable infrastructure for storage, and software defined networking.