Artwork

Content provided by Herding Code. All podcast content including episodes, graphics, and podcast descriptions are uploaded and provided directly by Herding Code or their podcast platform partner. If you believe someone is using your copyrighted work without your permission, you can follow the process outlined here https://player.fm/legal.
Player FM - Podcast App
Go offline with the Player FM app!

Herding Code 210: Ian Cooper on Microservices and the Brighter library

 
Share
 

Archived series ("Non-canonical URL" status)

Replaced by: Herding Code

When? This feed was archived on November 08, 2016 18:09 (8y ago). Last successful fetch was on November 08, 2016 18:16 (8y ago)

Why? Non-canonical URL status. A duplicate series with a more standard URL was identified.

What now? If you were subscribed to this series when it was replaced, you will now be subscribed to the replacement series. This series will no longer be checked for updates. If you believe this to be in error, please check if the publisher's feed link below is valid and contact support to request the feed be restored or if you have any other concerns about this.

Manage episode 165428973 series 1305861
Content provided by Herding Code. All podcast content including episodes, graphics, and podcast descriptions are uploaded and provided directly by Herding Code or their podcast platform partner. If you believe someone is using your copyrighted work without your permission, you can follow the process outlined here https://player.fm/legal.

While at NDC Oslo, K Scott and Jon talked to Ian Cooper about Microservices and using the Brighter library for Command Dispatcher / Command Processor patterns.

Download / Listen: Herding Code 210: Ian Cooper on Microservices and the Brighter library

http://herdingcode.com/wp-content/uploads/HerdingCode-0210-Ian-Cooper.mp3

Show Notes:

  • Why Microservices?
    • (0:48) Ian explains that "micro" doesn’t imply number of lines of code but "A bounded concept/business capability within your Domain" (put forth by Martin Fowler and James Lewis)
    • (1:20) Ian talks about breaking the domain problem down further and further for simpler testing, better fault tolerance and incremental releases.
    • (2:20) "If you can’t QA everything you need to be able to monitor and respond to issues rapidly."
    • (2:42) Scott Allen asks if Devops is a driver for Microservices rather than physical deployment or team size.
    • (3:00) Ian talks about the scale limits of developers and teams and how component based architectures.
  • Have we been here before?
    • (4:00) Ian talks about how Microservices is the next generation of component-based architectures after DCOM, CORBA, SOA and the importance of understanding what worked, what didn’t and why.
    • (4:49) Asking a component for a cup of tea vs telling something how to make tea highlighting the difference between Microservices vs RPC. RPC was very coupled to behavior which lead to fragile APIs.
  • Finding the "micro" sweet spot
    • (5:50) Jon asks how you manage the complexity of orchestrating many smaller pieces.
    • (6:15) Ian advises against going too small – Nanoservices – where the overhead of a service overshadows the utility value of it.
    • (6:30) "It’s really hard to get a feel in a new domain of where those points are that you can slice effectively" – one solution is to start exploring the domain in a traditional monolithic way and to break the parts apart at the seems to get the tradeoff right.
  • Tooling and support
    • (7:06) Jon asks what a good way to manage these services including profiling and monitoring.
    • (7:20) Ian recommends some tools to help:
      • New Relic for introspective monitoring and diagnostics.
      • Logstash or Splunk for log analysis and the usefulness of adding a GUID to a request that flows through messages and logs to correlate the activity.
      • Zookeeper or Consul for service registration and discovery.
    • (8:28) Scott Allen and Ian talk about how Microservices take forward SOA principles such as autonomous services, not sharing types and stable interfaces.
    • (9:00) Scott Allen asks what options for communications between the services are and Ian compares HTTP, Sockets and message queues like RabbitMQ.
  • Ian’s Brighter .NET lightweight Microservices project
    • (10:20) Basic two parts of Brighter are:
      • Command Dispatcher/Processor – Maps a command to a processor with a pipeline where you can insert orthogonal operations like logging and monitoring
      • Task Queue – Allows some commands will be handled asynchronously elsewhere
    • Very simple for the developer – just write a command and a handler.
    • Easy to embed in your existing Windows service if using something like Topshelf.
    • Provides timeouts, retries and a circuit breaker inspired by Netflix’s Hystrix in a declarative manner.
    • (12:45) Scott Allen clarifies how easy it is to get two services talking to each other using this via RabbitMQ.
    • (13:00) Ian talks about future support for Azure Service Bus and the possibility of producing one for Redis – RabbitMQ and Amazon SQS are already supported.
    • (13:30) Scott Allen asks if this is used in production and Ian explains how Huddle started with using RX on the server and had difficulties managing subscriptions.
    • (14:20) Brighter is on ThoughtWorks Technology Radar and evangelized by ex-Huddlers at their new roles.
    • (14:40) Ian talks about the importance of good documentation and welcomes feedback on theirs.
    • (15:10) Ian mentions they facilitate hexagonal architecture.
    • Scott Allen asks if you can use in-process and Ian explains the subtleties
  • Wrap-up
    • (16:00) Ian’s time is sucked up by being a a new dad, congratulations!
    • (16:30) The one job of a parent is keeping children alive.
    • (16:40) Thank-you and goodbye.

Show Links:

These show notes were contributed by Damien Guard. Thanks!

  continue reading

150 episodes

Artwork
iconShare
 

Archived series ("Non-canonical URL" status)

Replaced by: Herding Code

When? This feed was archived on November 08, 2016 18:09 (8y ago). Last successful fetch was on November 08, 2016 18:16 (8y ago)

Why? Non-canonical URL status. A duplicate series with a more standard URL was identified.

What now? If you were subscribed to this series when it was replaced, you will now be subscribed to the replacement series. This series will no longer be checked for updates. If you believe this to be in error, please check if the publisher's feed link below is valid and contact support to request the feed be restored or if you have any other concerns about this.

Manage episode 165428973 series 1305861
Content provided by Herding Code. All podcast content including episodes, graphics, and podcast descriptions are uploaded and provided directly by Herding Code or their podcast platform partner. If you believe someone is using your copyrighted work without your permission, you can follow the process outlined here https://player.fm/legal.

While at NDC Oslo, K Scott and Jon talked to Ian Cooper about Microservices and using the Brighter library for Command Dispatcher / Command Processor patterns.

Download / Listen: Herding Code 210: Ian Cooper on Microservices and the Brighter library

http://herdingcode.com/wp-content/uploads/HerdingCode-0210-Ian-Cooper.mp3

Show Notes:

  • Why Microservices?
    • (0:48) Ian explains that "micro" doesn’t imply number of lines of code but "A bounded concept/business capability within your Domain" (put forth by Martin Fowler and James Lewis)
    • (1:20) Ian talks about breaking the domain problem down further and further for simpler testing, better fault tolerance and incremental releases.
    • (2:20) "If you can’t QA everything you need to be able to monitor and respond to issues rapidly."
    • (2:42) Scott Allen asks if Devops is a driver for Microservices rather than physical deployment or team size.
    • (3:00) Ian talks about the scale limits of developers and teams and how component based architectures.
  • Have we been here before?
    • (4:00) Ian talks about how Microservices is the next generation of component-based architectures after DCOM, CORBA, SOA and the importance of understanding what worked, what didn’t and why.
    • (4:49) Asking a component for a cup of tea vs telling something how to make tea highlighting the difference between Microservices vs RPC. RPC was very coupled to behavior which lead to fragile APIs.
  • Finding the "micro" sweet spot
    • (5:50) Jon asks how you manage the complexity of orchestrating many smaller pieces.
    • (6:15) Ian advises against going too small – Nanoservices – where the overhead of a service overshadows the utility value of it.
    • (6:30) "It’s really hard to get a feel in a new domain of where those points are that you can slice effectively" – one solution is to start exploring the domain in a traditional monolithic way and to break the parts apart at the seems to get the tradeoff right.
  • Tooling and support
    • (7:06) Jon asks what a good way to manage these services including profiling and monitoring.
    • (7:20) Ian recommends some tools to help:
      • New Relic for introspective monitoring and diagnostics.
      • Logstash or Splunk for log analysis and the usefulness of adding a GUID to a request that flows through messages and logs to correlate the activity.
      • Zookeeper or Consul for service registration and discovery.
    • (8:28) Scott Allen and Ian talk about how Microservices take forward SOA principles such as autonomous services, not sharing types and stable interfaces.
    • (9:00) Scott Allen asks what options for communications between the services are and Ian compares HTTP, Sockets and message queues like RabbitMQ.
  • Ian’s Brighter .NET lightweight Microservices project
    • (10:20) Basic two parts of Brighter are:
      • Command Dispatcher/Processor – Maps a command to a processor with a pipeline where you can insert orthogonal operations like logging and monitoring
      • Task Queue – Allows some commands will be handled asynchronously elsewhere
    • Very simple for the developer – just write a command and a handler.
    • Easy to embed in your existing Windows service if using something like Topshelf.
    • Provides timeouts, retries and a circuit breaker inspired by Netflix’s Hystrix in a declarative manner.
    • (12:45) Scott Allen clarifies how easy it is to get two services talking to each other using this via RabbitMQ.
    • (13:00) Ian talks about future support for Azure Service Bus and the possibility of producing one for Redis – RabbitMQ and Amazon SQS are already supported.
    • (13:30) Scott Allen asks if this is used in production and Ian explains how Huddle started with using RX on the server and had difficulties managing subscriptions.
    • (14:20) Brighter is on ThoughtWorks Technology Radar and evangelized by ex-Huddlers at their new roles.
    • (14:40) Ian talks about the importance of good documentation and welcomes feedback on theirs.
    • (15:10) Ian mentions they facilitate hexagonal architecture.
    • Scott Allen asks if you can use in-process and Ian explains the subtleties
  • Wrap-up
    • (16:00) Ian’s time is sucked up by being a a new dad, congratulations!
    • (16:30) The one job of a parent is keeping children alive.
    • (16:40) Thank-you and goodbye.

Show Links:

These show notes were contributed by Damien Guard. Thanks!

  continue reading

150 episodes

All episodes

×
 
Loading …

Welcome to Player FM!

Player FM is scanning the web for high-quality podcasts for you to enjoy right now. It's the best podcast app and works on Android, iPhone, and the web. Signup to sync subscriptions across devices.

 

Quick Reference Guide