Infrastructure less development with Azure Service Fabric

Editor's Notes

1. Who is kCura? We’re a fast-growing Chicago-based software company, tackling big data challenges for users spanning the globe. What do we do? We’re the developers of the e-discovery software, Relativity, which is used for managing large volumes of electronic evidence during litigation and investigations. Statistics to use: If you’d like to speak about the size of the Relativity Community: More than 130,000 active users More than 11,000 unique organizations using Relativity 218 enterprise clients 127 channel partners Used by 99 of the Am Law 100 and 197 of the Am Law 200. Used by 70 of the Fortune 100 If you’d like to speak about the large volumes of electronic data managed in Relativity: There are 67 billion files under management in Relativity. Largest case to date involves 750 million documents.   If you’d like to speak about the international growth of Relativity: 127 of our clients are international. Relativity is being used in 43 countries.
2. Microservices… with Microsoft’s perspective, aka Azure Service Fabric Development on top of Azure Service Fabric without worrying about a reliable and scalable infrastructure A live demo of how Azure Service Fabric provides resiliency and scalablity
3. Traditional Software Architecture (Lasagna) Monolithic Tightly coupled components Not flexible Difficult to change Requires extensive integration test Not scalable Distributed environment? Services Oriented Architecture (Pie) Autonomous components Loosely coupled components To some extend scalable Yet: Highly dependable components Synchronous communication Distributed environment? Cloud? Microservices (Cupcakes) Decoupled components Asynchronous Communication Scalable and flexible For distributed environments Built for the Cloud, Born in the Cloud Continuous delivery
4. Concurrent execution of all components Runs on a distributed environment Each component can upgrade independently Each component can scale up or out independently Failure is isolated in each service Services can become resilient Services are isolated all the way to the hardware (virtualization, containers) Services act on their own; autonomous
5. The concept of Reliability Resiliency: Service stays on even when its environment fails Availability: Service is replicated in the cluster Consistency: Data integration between replicas are guaranteed Concurrency: Services run together yet independently (turn based) Asynchronous communication –> Decoupled Compute is separate from Data (State) Stateful: keeps data using Reliable Collections – As much as memory permits Stateless: No data storage
6. Actors Stateless or Stateful Internal to fabric Messaging model Activate/Deactivate as needed State per Id Services Stateless or Stateful Can expose web endpoints Linear model Constantly available Shared state
7. Applications that are not born in the Cloud Bring them onto the Service Fabric Service Fabric versions them You get failover for free
8. Nanoservices are too fine-grained. The overhead (communication, maintenance, test, etc) is more than its utility
9. The concept of Reliability Resiliency: Service stays on even when its environment fails Availability: Service is replicated in the cluster Consistency: Data integration between replicas are guaranteed Concurrency: Services run together yet independently (turn based) Asynchronous communication –> Decoupled Compute is separate from Data (State) Stateful: keeps data using Reliable Collections – As much as memory permits Stateless: No data storage