https://pinboard.in/u:jm/public/ recent bookmarks from jm 2023-05-18T22:19:17+00:00 https://github.com/StanzaSystems/awesome-load-management jm load-shedding circuit-breakers quota-management throttling papers architecture patterns via:niallm https://pinboard.in/ https://pinboard.in/u:jm/b:250d15e46975/ 2022-03-30T22:18:54+00:00 https://github.com/resilience4j/resilience4j jm fp hystrix java fault-tolerance retries timeouts architecture patterns circuit-breakers https://pinboard.in/ https://pinboard.in/u:jm/b:3c49a9299497/ 2022-03-08T16:31:40+00:00 https://ploomber.io/blog/sql/ jm sql coding clean-code patterns data-science data-pipelines olap https://pinboard.in/ https://pinboard.in/u:jm/b:59c60e02728d/ 2016-07-15T13:36:28+00:00 http://www.michaelnygard.com/blog/2016/07/qa-instability-implies-production-instability/ jmInvariably, when I see a lot of developer effort in production support I also find an unreliable QA environment. It is both unreliable in that it is frequently not available for testing, and unreliable in the sense that the system’s behavior in QA is not a good predictor of its behavior in production. ]]> qa testing architecture patterns systems production https://pinboard.in/ https://pinboard.in/u:jm/b:0f86aee40e69/ 2015-06-23T13:17:53+00:00 https://github.com/shopify/semian jm circuit-breaker bulkhead patterns architecture microservices shopify rails ruby networking reliability fallback fail-fast https://pinboard.in/ https://pinboard.in/u:jm/b:1110a603d906/ 2015-05-06T14:59:03+00:00 http://www.slideshare.net/nathariel/patterns-for-building-resilient-and-scalable-microservices-platform-onaws-full jm deployment ops devops hailo microservices platform patterns slides https://pinboard.in/ https://pinboard.in/u:jm/b:b424fcec24ec/ 2015-01-25T09:13:41+00:00 http://www.slideshare.net/ScottWlaschin/fp-patterns-buildstufflt jm clojure fp functional patterns coding scala https://pinboard.in/ https://pinboard.in/u:jm/b:f1da1f0020cb/ 2014-10-30T13:10:33+00:00 http://blog.acolyer.org/2014/10/24/brownout-building-more-robust-cloud-applications/ jmApplications can saturate – i.e. become unable to serve users in a timely manner. Some users may experience high latencies, while others may not receive any service at all. The authors argue that it is better to downgrade the user experience and continue serving a larger number of clients with reasonable latency. "We define a cloud application as brownout compliant if it can gradually downgrade user experience to avoid saturation." This is actually very reminiscent of circuit breakers, as described in Nygard’s ‘Release It!’ and popularized by Netflix. If you’re already designing with circuit breakers, you’ve probably got all the pieces you need to add brownout support to your application relatively easily. "Our work borrows from the concept of brownout in electrical grids. Brownouts are an intentional voltage drop often used to prevent blackouts through load reduction in case of emergency. In such a situation, incandescent light bulbs dim, hence originating the term." "To lower the maintenance effort, brownouts should be automatically triggered. This enables cloud applications to rapidly and robustly avoid saturation due to unexpected environmental changes, lowering the burden on human operators." This is really similar to the Circuit Breaker pattern -- in fact it feels to me like a variation on that, driven by measured latencies of operations/requests. See also http://blog.acolyer.org/2014/10/27/improving-cloud-service-resilience-using-brownout-aware-load-balancing/ . ]]> circuit-breaker patterns brownout robustness reliability load latencies degradation https://pinboard.in/ https://pinboard.in/u:jm/b:54124e536cdb/ 2014-10-01T14:01:14+00:00 http://kellabyte.com/2012/05/30/clarifying-the-saga-pattern/ jm distributed messaging saga patterns architecture transactions distributed-transactions distcomp https://pinboard.in/ https://pinboard.in/u:jm/b:1e75f48db4f6/ 2014-08-18T23:20:01+00:00 http://ispyker.blogspot.ie/2014/08/a-netflixoss-sidecar-in-support-of-non.html jmFor what it is worth, we faced a similar challenge in earlier services (mostly due to existing C/C++ applications) and we created what was called a "sidecar".  By sidecar, what I mean is a second process on each node/instance that did Cloud Service Fabric operations on behalf of the main process (the side-managed process).  Unfortunately those sidecars all went off and created one-offs for their particular service.  In this post, I'll describe a more general sidecar that doesn't force users to have these one-offs. Sidenote:  For those not familiar with sidecars, think of the motorcycle sidecar below.  Snoopy would be the main process with Woodstock being the sidecar process.  The main work on the instance would be the motorcycle (say serving your users' REST requests).  The operational control is the sidecar (say serving health checks and management plane requests of the operational platform). ]]> netflix sidecars architecture patterns smartstack netflixoss microservices soa https://pinboard.in/ https://pinboard.in/u:jm/b:1384a64a9720/ 2014-07-28T13:02:16+00:00 http://martinfowler.com/articles/collection-pipeline/ jm martin-fowler patterns coding ruby clojure streams pipelines pipes unix lambda fp java languages https://pinboard.in/ https://pinboard.in/u:jm/b:3294217f4efc/ 2013-07-03T21:26:24+00:00 http://www.planetgeek.ch/wp-content/uploads/2013/06/Clean-Code-V2.2.pdf jm clean-code code-smells coding tdd testing continous-integration patterns pdf https://pinboard.in/ https://pinboard.in/u:jm/b:62a5e19c36ea/ 2013-04-29T15:18:38+00:00 http://martinfowler.com/bliki/TestDouble.html jmTest Double is a generic term for any case where you replace a production object for testing purposes. There are various kinds of double that Gerard lists: Dummy objects are passed around but never actually used. Usually they are just used to fill parameter lists. Fake objects actually have working implementations, but usually take some shortcut which makes them not suitable for production (an InMemoryTestDatabase is a good example). Stubs provide canned answers to calls made during the test, usually not responding at all to anything outside what's programmed in for the test. Spies are stubs that also record some information based on how they were called. One form of this might be an email service that records how many messages it was sent. Mocks are pre-programmed with expectations which form a specification of the calls they are expected to receive. They can throw an exception if they receive a call they don't expect and are checked during verification to ensure they got all the calls they were expecting. ]]> test-doubles naming patterns tdd testing mocking tests martin-fowler https://pinboard.in/ https://pinboard.in/u:jm/b:8880b63c1cea/ 2012-02-16T11:56:48+00:00 http://highlyscalable.wordpress.com/2012/02/01/mapreduce-patterns/ jm algorithms hadoop java mapreduce patterns distcomp https://pinboard.in/ https://pinboard.in/u:jm/b:cdc3829d348a/ 2011-11-23T09:52:35+00:00 http://stackoverflow.com/questions/6559308/how-does-lmaxs-disruptor-pattern-work jm via:filippo servers seda queueing concurrency disruptor patterns latency trading performance ring-buffers https://pinboard.in/ https://pinboard.in/u:jm/b:388ee9929e15/ 2011-08-28T20:26:29+00:00 http://jonasboner.com/2008/10/06/real-world-scala-dependency-injection-di.html jm scala patterns programming oo coding dependency-injection https://pinboard.in/ https://pinboard.in/u:jm/b:075c87515a54/