2. Hometown: Shiraz, Iran
Company: kCura
What I do: DevOps Engineer
Fun Fact: I have watched all the
episodes of the TV
series more than 20 times!
Saba Jamalian
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.
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
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
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
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
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
Applications that are not born in the Cloud
Bring them onto the Service Fabric
Service Fabric versions them
You get failover for free
Nanoservices are too fine-grained. The overhead (communication, maintenance, test, etc) is more than its utility
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
