Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (7)
Similar to Infrastructure less development with Azure Service Fabric
Similar to Infrastructure less development with Azure Service Fabric (20)
Recently uploaded
Recently uploaded (20)
Infrastructure less development with Azure Service Fabric
- 1. 6/7/2016© kCura LLC. All rights reserved. Infrastructure-less Development with Azure Service Fabric Saba Jamalian
- 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
- 3. © kCura LLC. All rights reserved. e-Discovery Used to search, analyze, and act on data to tell the story of a case quickly and easily during litigation and investigation About Us Chicago-based e-discovery software company
- 4. © kCura LLC. All rights reserved. • Introduction to Microservices • Exploring "infrastructure-less development" with Azure Service Fabric What You’ll Learn Google’s search trend for “microservices”
- 5. © kCura LLC. All rights reserved. Microservices
- 6. © kCura LLC. All rights reserved. Traditional Software Architecture Services Oriented Architecture Microservices Component Interactions Tightly coupled Loosely coupled Decoupled Flexibility and Scalability Too difficult High Sky is the limit DevOps Friendly No Yes if designed with DevOps considerations Yes Distributed Environment Not considered Supported Born in the Cloud Communication Synchronous Asynchronous/ Synchronous Asynchronous The Evolution of Software Architecture 1990’s 2000's Now
- 7. © kCura LLC. All rights reserved. Highly decoupled services with isolated scope of responsibility that asynchronously communicate with each other. • Components – Concurrent execution – Independent upgrades – Independent scaling • Services – Isolated failure – Resilience – Isolated all the way to the hardware – Autonomous • Distributed environment Microservices Definition
- 8. © kCura LLC. All rights reserved. on the topic of UNIX philosophy Douglas McEllroy “Write programs that do one thing and do it well. Write programs to work together.”
- 9. © kCura LLC. All rights reserved. Scaling Models Scaling Monolithic Applications Scaling Microservices
- 10. © kCura LLC. All rights reserved. – Shorter time to market – Modular, therefore: • Replaceable • Independent development • Explicit interfaces for communication – Wider variety of technologies • Independent technology stack – Isolated Failure & Resiliency – CD/CI and DevOps – Legacy applications – Difficult configuration management – Who calls who? – Security risk in communication – Bottlenecked by network performance – Managing transactions – Compatibility of the services Microservices Pros and Cons Advantages Challenges
- 11. © kCura LLC. All rights reserved. Infrastructure-less Development Replication Resiliency Fail-over Data consistency Easy Deployment Elasticity Isolation
- 12. © kCura LLC. All rights reserved. Azure Service Fabric
- 13. © kCura LLC. All rights reserved. • Microsoft PaaS • Provides an abstraction for microservices architecture • Distributed service platform Azure Service Fabric
- 14. © kCura LLC. All rights reserved. Azure Service Fabric vs. Azure Cloud Services Image courtesy of MSDN
- 15. © kCura LLC. All rights reserved. Service Fabric Application Model Collection of Reliable Actors and Services
- 16. © kCura LLC. All rights reserved. Applications on Azure Service Fabric Application A Application B R B T P S Service Fabric Virtual Machines
- 17. © kCura LLC. All rights reserved. Let’s see it in action!
- 18. © kCura LLC. All rights reserved. Demo
- 19. © kCura LLC. All rights reserved. Azure Service Fabric Deployable everywhere: Development Machine Physical Cluster Virtual Cluster
- 20. © kCura LLC. All rights reserved. Actors • Stateless or Stateful • Internal to fabric • Messaging model • Activate/Deactivate as needed • State per Id Reliable Actors and Services • Stateless or Stateful • Can expose web endpoints • Linear model • Constantly available • Shared state Services
- 21. © kCura LLC. All rights reserved. • Bring in applications not born in the Cloud • Versioned by Service Fabric • Free fail-over Guest Executables on Service Fabric
- 22. © kCura LLC. All rights reserved. • Current State: – Microsoft recently announced General Availability – You can deploy Service Fabric clusters via Azure Portal and ARM – Deploy cluster on-premises • Future State: – Support for Linux – Support for Docker & Windows Containers – Support for Java Future of Service Fabric
- 23. © kCura LLC. All rights reserved. Our Experience at kCura • Avoid nanoservices • Think about dependencies • Design communication patterns • Log and monitor • Document contracts and interfaces
- 24. © kCura LLC. All rights reserved. Conclusion
- 25. © kCura LLC. All rights reserved. Questions?
Editor's Notes
- 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