<?xml version="1.0" encoding="UTF-8"?>
 <rdf:RDF xmlns="http://purl.org/rss/1.0/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:cc="http://web.resource.org/cc/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://pinboard.in">
    <title>Pinboard (jm)</title>
    <link>https://pinboard.in/u:jm/public/</link>
    <description>recent bookmarks from jm</description>
    <items>
      <rdf:Seq>	<rdf:li rdf:resource="https://www.coinbase.com/en-fr/blog/a-postmortem-of-our-may-7-2026-outage"/>
	<rdf:li rdf:resource="https://aws.amazon.com/blogs/compute/handling-billions-of-invocations-best-practices-from-aws-lambda/?ck_subscriber_id=512829374#415:%20Google%20Takes%20Wiz%20-%2017033042"/>
	<rdf:li rdf:resource="https://byroot.github.io/ruby/performance/2025/03/04/the-pitchfork-story.html"/>
	<rdf:li rdf:resource="https://encore.dev/blog/retries"/>
	<rdf:li rdf:resource="https://answersforaws.com/blog/2024-02-29-results/"/>
	<rdf:li rdf:resource="https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/single-region-scenarios.html"/>
	<rdf:li rdf:resource="https://www.alexdebrie.com/posts/dynamodb-paper/"/>
	<rdf:li rdf:resource="https://aws.amazon.com/builders-library/using-load-shedding-to-avoid-overload/"/>
	<rdf:li rdf:resource="https://github.com/Pugmatt/BedrockConnect"/>
	<rdf:li rdf:resource="https://blog.linuxserver.io/2019/10/01/updating-and-backing-up-docker-containers-with-version-control/"/>
	<rdf:li rdf:resource="https://summitroute.github.io/aws_research/service_support.html"/>
	<rdf:li rdf:resource="https://blog.linkerd.io/2018/09/18/announcing-linkerd-2-0/"/>
	<rdf:li rdf:resource="http://www.dublincity.ie/main-menu-services-water-waste-and-environment-waste-and-recycling/bulky-household-waste-collection"/>
	<rdf:li rdf:resource="https://medium.com/@NetflixTechBlog/evolution-of-application-data-caching-from-ram-to-ssd-a33d6fa7a690"/>
	<rdf:li rdf:resource="https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/"/>
	<rdf:li rdf:resource="http://www.dwmkerr.com/the-death-of-microservice-madness-in-2018/"/>
	<rdf:li rdf:resource="https://www.reddit.com/r/aws/comments/7phlq2/best_way_designing_a_gdpr_compliant_datalake/"/>
	<rdf:li rdf:resource="https://www.webdoctor.ie/"/>
	<rdf:li rdf:resource="https://aws.amazon.com/about-aws/whats-new/2017/11/introducing-the-amazon-time-sync-service/"/>
	<rdf:li rdf:resource="https://aws.amazon.com/blogs/aws/aws-fargate/?sc_channel=sm&amp;sc_campaign=AWS_reInvent&amp;sc_publisher=TWITTER&amp;sc_country=re:Invent&amp;sc_geo=GLOBAL&amp;sc_outcome=awareness&amp;trk=sm_EC2_Container_Service_9625c5f9_Fargate_TWITTER&amp;sc_content=EC2_Container_Service_9625c5f9_Fargate&amp;sc_category=Amazon_Fargate&amp;linkId=45301695"/>
	<rdf:li rdf:resource="https://github.com/anaibol/awesome-serverless/"/>
	<rdf:li rdf:resource="https://github.com/atlassian/localstack"/>
	<rdf:li rdf:resource="http://www.airfixers.com/"/>
	<rdf:li rdf:resource="https://charity.wtf/2016/10/02/the-accidental-dba/"/>
	<rdf:li rdf:resource="http://blog.lusis.org/blog/2015/12/09/aws-apigateway-for-fun-and-profit/"/>
	<rdf:li rdf:resource="https://medium.com/@AdamRNeary/a-gulp-workflow-for-amazon-lambda-61c2afd723b6#.nbn3nuamp"/>
	<rdf:li rdf:resource="http://blog.cask.co/2015/12/introducing-netty-http-from-cask/"/>
	<rdf:li rdf:resource="https://github.com/facebook/wangle/blob/master/wangle/concurrent/Codel.h"/>
	<rdf:li rdf:resource="http://john-sheehan.com/blog/ultimate-api-webhook-backend-service-debugging-testing-monitoring-and-discovery-tools-list"/>
	<rdf:li rdf:resource="https://hassle.com"/>
	<rdf:li rdf:resource="http://arnon.me/2014/03/services-microservices-nanoservices/"/>
	<rdf:li rdf:resource="http://literateprogrammer.blogspot.co.uk/2014/03/the-microservice-declaration-of.html"/>
	<rdf:li rdf:resource="http://static.googleusercontent.com/media/research.google.com/en//pubs/archive/36356.pdf"/>
	<rdf:li rdf:resource="http://www.nickhunn.com/smart-metering-is-fcuked/"/>
	<rdf:li rdf:resource="http://nerds.airbnb.com/smartstack-service-discovery-cloud/"/>
	<rdf:li rdf:resource="https://github.com/GeneralElectric/snowizard"/>
	<rdf:li rdf:resource="https://speakerdeck.com/mza/latencys-worst-nightmare-performance-tuning-tips-and-tricks"/>
	<rdf:li rdf:resource="https://github.com/infochimps-labs/ironfan/wiki/walkthrough-web"/>
	<rdf:li rdf:resource="http://smarden.org/runit/index.html"/>
	<rdf:li rdf:resource="http://perspectives.mvdirona.com/2011/03/26/PrioritizingPrinciplasInOnDesigningAndDeployingInternetScaleServices.aspx"/>
	<rdf:li rdf:resource="http://arstechnica.com/business/data-centers/2010/02/what-second-life-can-teach-all-companies-about-scaling-web-apps.ars/4"/>
      </rdf:Seq>
    </items>
  </channel><item rdf:about="https://www.coinbase.com/en-fr/blog/a-postmortem-of-our-may-7-2026-outage">
    <title>More on the Coinbase 07-05-2026 outage</title>
    <dc:date>2026-06-03T09:26:47+00:00</dc:date>
    <link>https://www.coinbase.com/en-fr/blog/a-postmortem-of-our-may-7-2026-outage</link>
    <dc:creator>jm</dc:creator><description><![CDATA[More on the Coinbase 07-05-2026 outage, caused by a "thermal event" in AWS us-east-1 and its impact on the suppposedly multi-AZ Managed Kafka product:

<blockquote>AWS's managed Kafka service failed silently. A significant portion of our event-streaming infrastructure runs on MSK, AWS's managed Kafka offering. The architectural promise of a managed Kafka service is that when individual brokers go down, the service automatically reelects partition leaders and continues to serve traffic out of the remaining brokers. The loss of an entire zone should result in reduced capacity, not unavailability.

That is not what happened and this extended the outage.

A defect in the AWS MSK control plane prevented automatic partition-leader reelection. Two of our MSK clusters became stuck in a "healing" state with producers unable to write. The cascading effect blocked our fee service, which blocked quoting, which is why most customers experienced this incident as broken trades and quotes rather than as a Kafka outage. Adjacent systems, including portions of our ledger pipeline, payments, and several data pipelines, were affected the same way. Additionally, one of our Kafka clusters was set up in a 2-AZ configuration that increased the blast radius and recovery time, but the MSK control plane defect impacted 2-AZ and 3-AZ Kafka clusters similarly.

We worked the recovery in real time with AWS engineering, ultimately performing manual partition reassignments at 3:00 AM ET to migrate topics off the impaired brokers. Priority-zero and priority-one topics were back to full availability by 9:30 AM ET. The remainder cleared by 2:00 PM ET.</blockquote>

In fairness, they also had a single-AZ point of failure in their architecture which they also describe there, but still, not great performance from MSK.  Disappointing.
]]></description>
<dc:subject>msk reliability multi-az aws services kafka resiliency outages post-mortems postmortems coinbase</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:7124695a3aec/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:msk"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:reliability"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:multi-az"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:services"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:kafka"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:resiliency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:outages"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:post-mortems"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:postmortems"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coinbase"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://aws.amazon.com/blogs/compute/handling-billions-of-invocations-best-practices-from-aws-lambda/?ck_subscriber_id=512829374#415:%20Google%20Takes%20Wiz%20-%2017033042">
    <title>Handling billions of invocations – best practices from AWS Lambda</title>
    <dc:date>2025-03-24T15:10:54+00:00</dc:date>
    <link>https://aws.amazon.com/blogs/compute/handling-billions-of-invocations-best-practices-from-aws-lambda/?ck_subscriber_id=512829374#415:%20Google%20Takes%20Wiz%20-%2017033042</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Good write-up on how to horizontally scale a multi-tenant async API service, from AWS. I particularly found this shuffle-sharding-based technique to be an excellent idea:

<blockquote>Drawing inspiration from the “The Power of Two Random Choices” paper, the Lambda team explored the shuffle-sharding technique for its asynchronous invocations processing. Using this technique, you shuffle-shard tenants into several randomly assigned queues. Upon receiving an asynchronous invocation, you place the message in the queue with the smallest backlog to optimize load distribution. This approach helps to minimize the likelihood of assigning tenants to a busy queue. [....]

The shuffle-sharding technique proved remarkably effective. By distributing tenants across shards, the approach ensures that only a very small subset of tenants could be affected by a noisy neighbor. The potential impact is also minimized since each affected tenant maintains access to unaffected queues. As your workloads grow, increasing the number of queues enhances resilience and further reduces the probability of multiple tenants being assigned to the same shard. This significantly lowers the risk of a single point of failure, making shuffle sharding a robust strategy for workload isolation and fault tolerance.</blockquote>

Automated Isolation, covered in the next section, is also a neat trick.  (via Last Week In AWS)]]></description>
<dc:subject>via:lwia sharding architecture services horizontal-scaling shuffle-sharding algorithms load-balancing async queues aws multitenant</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:b407ba9caf17/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:lwia"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sharding"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:services"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:horizontal-scaling"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:shuffle-sharding"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:algorithms"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:load-balancing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:async"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:queues"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:multitenant"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://byroot.github.io/ruby/performance/2025/03/04/the-pitchfork-story.html">
    <title>Pitchfork</title>
    <dc:date>2025-03-21T10:30:41+00:00</dc:date>
    <link>https://byroot.github.io/ruby/performance/2025/03/04/the-pitchfork-story.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[An amazing journey through Ruby heap memory optimization, from one of the experts at Shopify, who are heavy users of Rails.  Using cleverly-timed fork(2) usage, it's possible to optimize memory usage in a Rails app and discard a lot of performance/heap overhead caused by lazy loading and poorly-timed in-memory caching.

This very much reminds me of optimising similar issues in Perl-land, back in the day -- and really helps me appreciate how easy the modern JVM world has it, in comparison.  There's a lot of complaints to be made about the complexity of optimising JVM garbage collection settings, but this kind of problem is malleable there without a fundamental architectural rewrite like this approach.]]></description>
<dc:subject>ruby performance optimisation optimization heap memory fork forking http services servers monolith rails gc</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:2839524a8511/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ruby"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimisation"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:heap"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:memory"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:fork"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:forking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:http"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:services"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:servers"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:monolith"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:rails"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gc"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://encore.dev/blog/retries">
    <title>Retries, illustrated</title>
    <dc:date>2024-07-10T22:46:42+00:00</dc:date>
    <link>https://encore.dev/blog/retries</link>
    <dc:creator>jm</dc:creator><description><![CDATA["An interactive study of common retry methods" -- basically graphical, interactive demos of retry patterns, backoff, and jittering]]></description>
<dc:subject>retries retrying backoff jitter networking soa services interactive demos</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:25d687fb2382/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:retries"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:retrying"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:backoff"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jitter"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:soa"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:services"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:interactive"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:demos"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://answersforaws.com/blog/2024-02-29-results/">
    <title>Answers for AWS survey results for 2024</title>
    <dc:date>2024-03-04T10:28:26+00:00</dc:date>
    <link>https://answersforaws.com/blog/2024-02-29-results/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[This is actually really useful data about which AWS services are good and which ones suck, as of right now.
Some highlights:

- Simple Queue Service (SQS) is the most loved AWS service with an overall positive/negative split of 98% [SNS also scoring very well].
- GitHub Actions wins every metric in the CI/CD category.
- OpenAI has taken the top usage spot away from Amazon Sagemaker in the AI & Machine Learning category [no surprises there].
- ECS continues its reign as the most used container service.
- DynamoDB's dominance over the NoSQL DBs continues for the second year running.
- The most polarizing service is CloudFormation - 30% would not use it ever again, while 56% would.]]></description>
<dc:subject>aws services ops infrastructure architecture sqs sns dynamodb github-actions ecs via:lastweekinaws</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:04ea95c6ae80/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:services"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:infrastructure"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sqs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sns"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:dynamodb"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:github-actions"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ecs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:lastweekinaws"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/single-region-scenarios.html">
    <title>AWS Reliability Pillar Single-Region scenarios</title>
    <dc:date>2023-10-12T13:29:48+00:00</dc:date>
    <link>https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/single-region-scenarios.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[I hadn't read these before; these are good example service setups from the AWS Well-Architected Framework, for 3 single-AZ availability goals (99%, 99.9%, and 99.99%), and multi-region high availability (5 9s with a recovery time under 1 minute).  Pretty consistent with realistic real-world usage.  (via Brian Scanlan)]]></description>
<dc:subject>via:singer aws reliability architecture availability uptime services ops high-availability</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:f9f9b0a1c1c2/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:singer"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:reliability"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:availability"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:uptime"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:services"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:high-availability"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.alexdebrie.com/posts/dynamodb-paper/">
    <title>Key Takeaways from the DynamoDB Paper</title>
    <dc:date>2022-08-08T10:21:17+00:00</dc:date>
    <link>https://www.alexdebrie.com/posts/dynamodb-paper/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Alex DeBrie's commentary on the "10 years of DynamoDB" paper published recently by AWS.  Together with Marc Brooker's commentary (at https://brooker.co.za/blog/2022/07/12/dynamodb.html), this is a good review.]]></description>
<dc:subject>scalability scaling dynamodb aws storage services architecture</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:3f183f470778/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scalability"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scaling"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:dynamodb"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:storage"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:services"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:architecture"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://aws.amazon.com/builders-library/using-load-shedding-to-avoid-overload/">
    <title>Using load shedding to avoid overload</title>
    <dc:date>2021-10-12T12:10:25+00:00</dc:date>
    <link>https://aws.amazon.com/builders-library/using-load-shedding-to-avoid-overload/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[decent writeup from Lambda's David Yanacek]]></description>
<dc:subject>error-handling distributed-systems http aws services soa david-yanacek load load-shedding uptime reliability</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:c8ea792bb37a/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:error-handling"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:distributed-systems"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:http"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:services"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:soa"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:david-yanacek"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:load"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:load-shedding"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:uptime"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:reliability"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/Pugmatt/BedrockConnect">
    <title>Pugmatt/BedrockConnect: Join any Minecraft server IP on Xbox One, Nintendo Switch, and PS4</title>
    <dc:date>2020-04-22T22:02:21+00:00</dc:date>
    <link>https://github.com/Pugmatt/BedrockConnect</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Nicely done -- this works! By setting the DNS server list in the console to use "104.238.130.180" as the primary DNS, this will intercept lookups for the hardcoded set of Bedrock servers, and redirect them to their own Bedrock-protocol server, which simply offers a more customisable list of servers, potentially including your own.]]></description>
<dc:subject>minecraft bedrock hacks interop services xbox ps4 nintendo-switch cross-play</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:1ae566b031a8/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:minecraft"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:bedrock"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hacks"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:interop"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:services"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:xbox"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ps4"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:nintendo-switch"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cross-play"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://blog.linuxserver.io/2019/10/01/updating-and-backing-up-docker-containers-with-version-control/">
    <title>Updating and Backing Up Docker Containers With Version Control</title>
    <dc:date>2019-10-02T15:57:31+00:00</dc:date>
    <link>https://blog.linuxserver.io/2019/10/01/updating-and-backing-up-docker-containers-with-version-control/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Version controlling Docker-based service upgrades; assuming all the service state is in a /config or /data app-data directory, this is a nice approach.  Linuxserver.IO are impressive in how well they have thought out the use of Docker containers as a server deployment system for small-scale, home use]]></description>
<dc:subject>docker home ops services upgrades docker-compose version-control</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:0af56745e34e/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:docker"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:home"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:services"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:upgrades"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:docker-compose"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:version-control"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://summitroute.github.io/aws_research/service_support.html">
    <title>AWS Service SLAs</title>
    <dc:date>2019-01-08T12:19:42+00:00</dc:date>
    <link>https://summitroute.github.io/aws_research/service_support.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>The goal of this page is to high-light the lack of coverage AWS provides for its services across different security factors. These limitations are not well-understood by many. Further, the "Y" fields are meant to indicate that this service has any capability for the relevant factor. In many cases, this is not full coverage for the service, or there are exceptions or special cases.</blockquote>

]]></description>
<dc:subject>amazon aws services slas ops reliability</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:ccd898c6775e/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:amazon"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:services"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:slas"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:reliability"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://blog.linkerd.io/2018/09/18/announcing-linkerd-2-0/">
    <title>Linkerd 2.0</title>
    <dc:date>2018-11-26T16:08:28+00:00</dc:date>
    <link>https://blog.linkerd.io/2018/09/18/announcing-linkerd-2-0/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>The 2.0 release of Linkerd brings two very significant changes. First, we’ve completely rewritten Linkerd to be orders of magnitude faster and smaller than Linkerd 1.x. Linkerd 2.0’s data plane is comprised of ultralight Rust proxies which consume around 10mb of RSS and have a p99 latency of <1ms. Linkerd’s minimalist control plane (written in Go) is similarly designed for speed and low resource footprint.

Second, with the 2.0 release, Linkerd moves beyond the service mesh model to be something not more, but less: Linkerd 2.0 at its core is a service sidecar, running on a single service without requiring cluster-wide installation. This means that if you’re a developer or service owner who doesn’t have access to the whole Kubernetes cluster, you can run Linkerd on your service and get:

Instant Grafana dashboards of your service’s success rates, latencies, and throughput;
A topology graph of incoming and outgoing dependencies;
A live view of requests being made to your service;
Improved, latency-aware load balancing;
… and much more.
</blockquote>

]]></description>
<dc:subject>linkerd mesh networking services architecture sidecars</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:1d41240fa54d/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linkerd"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mesh"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:services"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sidecars"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.dublincity.ie/main-menu-services-water-waste-and-environment-waste-and-recycling/bulky-household-waste-collection">
    <title>Bulky Household Waste Collection Service</title>
    <dc:date>2018-10-22T15:41:47+00:00</dc:date>
    <link>http://www.dublincity.ie/main-menu-services-water-waste-and-environment-waste-and-recycling/bulky-household-waste-collection</link>
    <dc:creator>jm</dc:creator><description><![CDATA[for e.g., doors, beds, radiators, mattresses, furniture etc. -- EUR40 per collection]]></description>
<dc:subject>waste rubbish household dublin dcc services</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:efe79ba5ed1f/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:waste"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:rubbish"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:household"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:dublin"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:dcc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:services"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://medium.com/@NetflixTechBlog/evolution-of-application-data-caching-from-ram-to-ssd-a33d6fa7a690">
    <title>Evolution of Application Data Caching : From RAM to SSD</title>
    <dc:date>2018-07-12T21:50:28+00:00</dc:date>
    <link>https://medium.com/@NetflixTechBlog/evolution-of-application-data-caching-from-ram-to-ssd-a33d6fa7a690</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>Memcached provides an external storage shim called extstore, that supports storing of data on SSD (I2) and NVMe (I3). extstore is efficient in terms of cost & storage device utilization without compromising the speed and throughput. All the metadata (key & other metadata) is stored in RAM whereas the actual data is stored on flash.</blockquote>

]]></description>
<dc:subject>memcached netflix services storage memory ssd nvme extstore caching</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:119cb46419e3/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:memcached"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:netflix"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:services"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:storage"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:memory"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ssd"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:nvme"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:extstore"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:caching"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/">
    <title>AWS Region Table</title>
    <dc:date>2018-06-06T09:32:06+00:00</dc:date>
    <link>https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[what products are available where]]></description>
<dc:subject>amazon aws regions azs services architecture ops</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:94e3251bc6d3/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:amazon"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:regions"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:azs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:services"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.dwmkerr.com/the-death-of-microservice-madness-in-2018/">
    <title>The Death of Microservice Madness in 2018</title>
    <dc:date>2018-01-15T11:23:58+00:00</dc:date>
    <link>http://www.dwmkerr.com/the-death-of-microservice-madness-in-2018/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Quite a good set of potential gotchas, which I've run into myself, including:

'Real world systems often have poorly defined boundaries'
'The complexities of state are often ignored'
'The complexitities of communication are often ignored'
'Versioning can be hard'
'Microservices can be monoliths in disguise']]></description>
<dc:subject>architecture devops microservices services soa coding monoliths state systems</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:0f831a39dc8a/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:devops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:microservices"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:services"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:soa"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coding"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:monoliths"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:state"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:systems"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.reddit.com/r/aws/comments/7phlq2/best_way_designing_a_gdpr_compliant_datalake/">
    <title>Best way designing a GDPR compliant datalake using AWS services : aws</title>
    <dc:date>2018-01-11T17:23:49+00:00</dc:date>
    <link>https://www.reddit.com/r/aws/comments/7phlq2/best_way_designing_a_gdpr_compliant_datalake/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[interesting thread at Reddit]]></description>
<dc:subject>gdpr reddit aws tips design services ops</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:740cf65fe3c8/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gdpr"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:reddit"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tips"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:services"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.webdoctor.ie/">
    <title>Webdoctor.ie</title>
    <dc:date>2018-01-03T10:55:38+00:00</dc:date>
    <link>https://www.webdoctor.ie/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[An online doctor appointment -- you fill out a questionnaire, are interviewed via VC, and receive any prescription you need.  Recommended by devxda on the ITC slack]]></description>
<dc:subject>doctor medicine ireland services health</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:7839bb86c629/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:doctor"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:medicine"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ireland"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:services"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:health"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://aws.amazon.com/about-aws/whats-new/2017/11/introducing-the-amazon-time-sync-service/">
    <title>Introducing the Amazon Time Sync Service</title>
    <dc:date>2017-11-30T10:36:11+00:00</dc:date>
    <link>https://aws.amazon.com/about-aws/whats-new/2017/11/introducing-the-amazon-time-sync-service/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Well overdue; includes Google-style leap smearing]]></description>
<dc:subject>time-sync time aws services ntp ops</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:2a60d299c58e/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:time-sync"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:time"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:services"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ntp"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://aws.amazon.com/blogs/aws/aws-fargate/?sc_channel=sm&amp;sc_campaign=AWS_reInvent&amp;sc_publisher=TWITTER&amp;sc_country=re:Invent&amp;sc_geo=GLOBAL&amp;sc_outcome=awareness&amp;trk=sm_EC2_Container_Service_9625c5f9_Fargate_TWITTER&amp;sc_content=EC2_Container_Service_9625c5f9_Fargate&amp;sc_category=Amazon_Fargate&amp;linkId=45301695">
    <title>Introducing AWS Fargate – Run Containers without Managing Infrastructure</title>
    <dc:date>2017-11-29T17:09:02+00:00</dc:date>
    <link>https://aws.amazon.com/blogs/aws/aws-fargate/?sc_channel=sm&amp;sc_campaign=AWS_reInvent&amp;sc_publisher=TWITTER&amp;sc_country=re:Invent&amp;sc_geo=GLOBAL&amp;sc_outcome=awareness&amp;trk=sm_EC2_Container_Service_9625c5f9_Fargate_TWITTER&amp;sc_content=EC2_Container_Service_9625c5f9_Fargate&amp;sc_category=Amazon_Fargate&amp;linkId=45301695</link>
    <dc:creator>jm</dc:creator><description><![CDATA[now that's a good announcement.  Available right away running atop ECS; EKS in 2018]]></description>
<dc:subject>eks ecs fargate aws services ops containers docker</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:ea5d427cbdf3/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:eks"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ecs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:fargate"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:services"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:containers"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:docker"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/anaibol/awesome-serverless/">
    <title>anaibol/awesome-serverless: A curated list of awesome services, solutions and resources for serverless / nobackend applications.</title>
    <dc:date>2017-06-26T14:00:14+00:00</dc:date>
    <link>https://github.com/anaibol/awesome-serverless/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>A curated list of awesome services, solutions and resources for serverless / nobackend applications.</blockquote>

]]></description>
<dc:subject>serverless lambda ops devops saas services architecture lists</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:8877523021d9/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:serverless"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:lambda"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:devops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:saas"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:services"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:lists"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/atlassian/localstack">
    <title>atlassian/localstack: A fully functional local AWS cloud stack. Develop and test your cloud apps offline!</title>
    <dc:date>2017-03-20T14:25:19+00:00</dc:date>
    <link>https://github.com/atlassian/localstack</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>LocalStack provides an easy-to-use test/mocking framework for developing Cloud applications.  Currently, the focus is primarily on supporting the AWS cloud stack.

LocalStack spins up the following core Cloud APIs on your local machine:

API Gateway at http://localhost:4567;
Kinesis at http://localhost:4568;
DynamoDB at http://localhost:4569;
DynamoDB Streams at http://localhost:4570;
Elasticsearch at http://localhost:4571;
S3 at http://localhost:4572;
Firehose at http://localhost:4573;
Lambda at http://localhost:4574;
SNS at http://localhost:4575;
SQS at http://localhost:4576

Additionally, LocalStack provides a powerful set of tools to interact with the cloud services, including a fully featured KCL Kinesis client with Python binding, simple setup/teardown integration for nosetests, as well as an Environment abstraction that allows to easily switch between local and remote Cloud execution.</blockquote>

]]></description>
<dc:subject>aws emulation mocking services testing dynamodb s3</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:240a300dcd0c/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:emulation"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mocking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:services"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:testing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:dynamodb"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:s3"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.airfixers.com/">
    <title>Airfixers - Hosting without the hassle</title>
    <dc:date>2016-10-12T13:23:54+00:00</dc:date>
    <link>http://www.airfixers.com/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Full AirBnB property management service in Dublin]]></description>
<dc:subject>dublin airbnb management rental services</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:e6a3abae80e6/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:dublin"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:airbnb"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:management"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:rental"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:services"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://charity.wtf/2016/10/02/the-accidental-dba/">
    <title>Charity Majors responds to the CleverTap Mongo outage war story</title>
    <dc:date>2016-10-04T11:26:44+00:00</dc:date>
    <link>https://charity.wtf/2016/10/02/the-accidental-dba/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[This is a great blog post, spot on:

<blockquote>You can’t just go “dudes it’s faster” and jump off a cliff.  This shit is basic.  Test real production workloads. Have a rollback plan.  (Not for *10 days* … try a month or two.)</blockquote>

The only thing I'd nitpick on is that it's all very well to say "buy my book" or "come see me talk at Blahcon", but a good blog post or webpage would be thousands of times more useful.]]></description>
<dc:subject>databases stateful-services services ops mongodb charity-majors rollback state storage testing dba</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:15609640fcf7/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:databases"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:stateful-services"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:services"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mongodb"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:charity-majors"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:rollback"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:state"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:storage"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:testing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:dba"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://blog.lusis.org/blog/2015/12/09/aws-apigateway-for-fun-and-profit/">
    <title>AWS Api Gateway for Fun and Profit</title>
    <dc:date>2015-12-10T14:10:02+00:00</dc:date>
    <link>http://blog.lusis.org/blog/2015/12/09/aws-apigateway-for-fun-and-profit/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[good worked-through example of an API Gateway rewriting system]]></description>
<dc:subject>api-gateway aws api http services ops alerting alarming opsgenie signalfx</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:a5bbeed7fb8b/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:api-gateway"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:api"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:http"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:services"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:alerting"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:alarming"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:opsgenie"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:signalfx"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://medium.com/@AdamRNeary/a-gulp-workflow-for-amazon-lambda-61c2afd723b6#.nbn3nuamp">
    <title>A Gulp Workflow for Amazon Lambda</title>
    <dc:date>2015-12-07T12:04:50+00:00</dc:date>
    <link>https://medium.com/@AdamRNeary/a-gulp-workflow-for-amazon-lambda-61c2afd723b6#.nbn3nuamp</link>
    <dc:creator>jm</dc:creator><description><![CDATA['any nontrivial development of Lambda functions will require a simple, automated build/deploy process that also fills a couple of Lambda’s gaps such as the use of node modules and environment variables.'

See also https://medium.com/@AdamRNeary/developing-and-testing-amazon-lambda-functions-e590fac85df4#.mz0a4qk3j : 'I am psyched about Amazon’s new Lambda service for asynchronous task processing, but the ideal development and testing cycle is really left to the engineer. While Amazon provides a web-based console, I prefer an approach that uses Mocha. Below you will find the gritty details using Kinesis events as a sample input.'

]]></description>
<dc:subject>lambda aws services testing deployment ops mocha gulp javascript</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:04a4a810e7fd/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:lambda"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:services"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:testing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:deployment"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mocha"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gulp"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:javascript"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://blog.cask.co/2015/12/introducing-netty-http-from-cask/">
    <title>Introducing Netty-HTTP from Cask</title>
    <dc:date>2015-12-03T12:52:22+00:00</dc:date>
    <link>http://blog.cask.co/2015/12/introducing-netty-http-from-cask/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>netty-http library solves [Netty usability issues] by using JAX-RS annotations to build a HTTP path routing layer on top of netty. In addition, the library implements a guava service to manage the HTTP service. netty-http allows users of the library to just focus on writing the business logic in HTTP handlers without having to worry about the complexities of path routing or learning netty pipeline internals to build the HTTP service.</blockquote>

We've written something very similar, although I didn't even bother supporting JAX-RS annotations -- just a simple code-level DSL.]]></description>
<dc:subject>jax-rs netty http cask java services coding</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:c5c91942c05c/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jax-rs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:netty"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:http"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cask"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:services"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coding"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/facebook/wangle/blob/master/wangle/concurrent/Codel.h">
    <title>wangle/Codel.h at master · facebook/wangle</title>
    <dc:date>2015-11-04T16:28:06+00:00</dc:date>
    <link>https://github.com/facebook/wangle/blob/master/wangle/concurrent/Codel.h</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Facebook's open-source implementation of the CoDel queue management algorithm applied to server request-handling capacity in their C++ service bootstrap library, Wangle.]]></description>
<dc:subject>wangle facebook codel services capacity reliability queueing</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:646392c5785b/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:wangle"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:facebook"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:codel"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:services"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:capacity"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:reliability"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:queueing"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://john-sheehan.com/blog/ultimate-api-webhook-backend-service-debugging-testing-monitoring-and-discovery-tools-list">
    <title>60+ Tools and Services for API and Webhook Logging, Debugging, Testing, Monitoring, Documentation and Discovery</title>
    <dc:date>2014-12-04T10:04:12+00:00</dc:date>
    <link>http://john-sheehan.com/blog/ultimate-api-webhook-backend-service-debugging-testing-monitoring-and-discovery-tools-list</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Nice list -- lots of random toy services]]></description>
<dc:subject>web apis webhooks http hacking services saas</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:a4105ae0a14a/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:web"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:apis"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:webhooks"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:http"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hacking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:services"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:saas"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://hassle.com">
    <title>Hassle.com</title>
    <dc:date>2014-07-07T11:48:09+00:00</dc:date>
    <link>https://hassle.com</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Book a domestic cleaner online in 60 seconds; "like Hailo for cleaners" apparently.  Live in Dublin, London, Manchester, Birmingham and Leeds.  Use code HASSLEDUBLIN for 15% off]]></description>
<dc:subject>hailo cleaners hassle via:hailo domestic home services b2c</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:bec46a2b8077/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hailo"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cleaners"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hassle"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:hailo"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:domestic"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:home"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:services"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:b2c"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://arnon.me/2014/03/services-microservices-nanoservices/">
    <title>Microservices and nanoservices</title>
    <dc:date>2014-03-25T10:26:55+00:00</dc:date>
    <link>http://arnon.me/2014/03/services-microservices-nanoservices/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[A great reaction to Martin Fowler's "microservices" coinage, from Arnon Rotem-Gal-Oz:

'I guess it is easier to use a new name (Microservices) rather than say that this is what SOA actually meant'; 'these are the very principles of SOA before vendors pushed the [ESB] in the middle.'

Others have also chosen to define microservices slightly differently, as a service written in 10-100 LOC.   Arnon's reaction:

“Nanoservice is an antipattern where a service is too fine-grained. A nanoservice is a service whose overhead (communications, maintenance, and so on) outweighs its utility.”

Having dealt with maintaining an over-fine-grained SOA stack in Amazon, I can only agree with this definition; it's easy to make things too fine-grained and create a raft of distributed-computing bugs and deployment/management complexity where there is no need to do so.]]></description>
<dc:subject>architecture antipatterns nanoservices microservices soa services design esb</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:a19528e98dbf/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:antipatterns"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:nanoservices"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:microservices"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:soa"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:services"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:esb"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://literateprogrammer.blogspot.co.uk/2014/03/the-microservice-declaration-of.html">
    <title>The Microservice Declaration of Independence</title>
    <dc:date>2014-03-20T15:19:10+00:00</dc:date>
    <link>http://literateprogrammer.blogspot.co.uk/2014/03/the-microservice-declaration-of.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA["Microservices" seems to be yet another term for SOA; small, decoupled, independently-deployed services, with well-defined public HTTP APIs. Pretty much all the services I've worked on over the past few years have been built in this style. Still, let's keep an eye on this concept anyway.

Another definition seems to be a more FP-style one: http://www.slideshare.net/michaelneale/microservices-and-functional-programming -- where the "microservice" does one narrowly-defined thing, and that alone.]]></description>
<dc:subject>microservices soa architecture handwaving http services web deployment</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:3c13e569ef49/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:microservices"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:soa"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:handwaving"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:http"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:services"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:web"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:deployment"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://static.googleusercontent.com/media/research.google.com/en//pubs/archive/36356.pdf">
    <title>&quot;Dapper, a Large-Scale Distributed Systems Tracing Infrastructure&quot; [PDF]</title>
    <dc:date>2014-03-10T12:07:09+00:00</dc:date>
    <link>http://static.googleusercontent.com/media/research.google.com/en//pubs/archive/36356.pdf</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Google paper describing the infrastructure they've built for cross-service request tracing (ie. "tracer requests"). Features: low code changes required (since they've built it into the internal protobuf libs), low performance impact, sampling, deployment across the ~entire production fleet, output visibility in minutes, and has been live in production for over 2 years.  Excellent read]]></description>
<dc:subject>dapper tracing http services soa google papers request-tracing tracers protobuf devops</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:7c7dff9b9866/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:dapper"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tracing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:http"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:services"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:soa"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:papers"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:request-tracing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tracers"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:protobuf"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:devops"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.nickhunn.com/smart-metering-is-fcuked/">
    <title>Smart Metering in the UK is FCUKED</title>
    <dc:date>2013-12-07T21:02:00+00:00</dc:date>
    <link>http://www.nickhunn.com/smart-metering-is-fcuked/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>Most utilities don’t want smart metering.  In fact they seem to have used the wrong dictionary.  It is difficult to find anything smart about the UK deployment, until you realise that the utilities use smart in the sense of “it hurts”.  They consider they have a perfectly adequate business model which has no need for new technology.  In many Government meetings, their reluctant support seems to be a veneer for the hope that it will all end in disaster, letting them go back to the world they know, of inflated bills and demands for money with menaces. [...]

Even when smart meters are deployed, there is no evidence that any utility will use the resulting data to transform their business, rather than persecute the consumer.  At a recent US conference a senior executive for a US utility which had deployed smart meters, stated that their main benefit was “to give them more evidence to blame the customer”.  That’s a good description of the attitude displayed by our utilities.</blockquote>

]]></description>
<dc:subject>smart-metering energy utilities uk services metering consumer</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:62a961d0f3e3/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:smart-metering"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:energy"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:utilities"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:uk"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:services"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:metering"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:consumer"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://nerds.airbnb.com/smartstack-service-discovery-cloud/">
    <title>Airbnb's Smartstack</title>
    <dc:date>2013-10-23T21:35:04+00:00</dc:date>
    <link>http://nerds.airbnb.com/smartstack-service-discovery-cloud/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Service discovery a la Airbnb -- Nerve and Synapse: two external daemons that run on each node, Nerve to manage registration in Zookeeper, and Synapse to generate a haproxy configuration file from that, running on each host, allowing connections to all other hosts.
]]></description>
<dc:subject>haproxy services ops load-balancing service-discovery nerve synapse airbnb</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:ee71b29b1825/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:haproxy"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:services"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:load-balancing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:service-discovery"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:nerve"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:synapse"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:airbnb"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/GeneralElectric/snowizard">
    <title>Snowizard</title>
    <dc:date>2013-08-21T21:25:34+00:00</dc:date>
    <link>https://github.com/GeneralElectric/snowizard</link>
    <dc:creator>jm</dc:creator><description><![CDATA['a Java port of Twitter's Snowflake thrift service presented as an HTTP-based Dropwizard service'.

<blockquote>an HTTP-based service for generating unique ID numbers at high scale with some simple guarantees.  supports returning ID numbers as: JSON and JSONP; Google's Protocol Buffers; Plain text.

At GE, we were more interested in the uncoordinated aspects of Snowflake than its throughput requirements, so HTTP was fine for our needs. We also exposed the core of Snowflake as an embeddable module so it can be directly integrated into our applications. We don't have the guarantees that the Snowflake-Zookeeper integration was providing, but that was also acceptable to us. In places where we really needed high throughput, we leveraged the snowizard-core embeddable module directly.</blockquote>

Odd OSS license, though -- BSDish?]]></description>
<dc:subject>java open-source ids soa services snowflake http</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:2cdc8b3567a7/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:open-source"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ids"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:soa"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:services"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:snowflake"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:http"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://speakerdeck.com/mza/latencys-worst-nightmare-performance-tuning-tips-and-tricks">
    <title>Latency's Worst Nightmare: Performance Tuning Tips and Tricks [slides]</title>
    <dc:date>2013-04-19T20:27:52+00:00</dc:date>
    <link>https://speakerdeck.com/mza/latencys-worst-nightmare-performance-tuning-tips-and-tricks</link>
    <dc:creator>jm</dc:creator><description><![CDATA[the basics of running a service stack (web, app servers, data stores) on AWS.  some good benchmark figures in the final slides]]></description>
<dc:subject>benchmarks aws ec2 ebs piops services scaling scalability presentations</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:0dad472cef4b/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:benchmarks"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ec2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ebs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:piops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:services"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scaling"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scalability"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:presentations"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/infochimps-labs/ironfan/wiki/walkthrough-web">
    <title>Ironfan</title>
    <dc:date>2013-01-27T21:11:16+00:00</dc:date>
    <link>https://github.com/infochimps-labs/ironfan/wiki/walkthrough-web</link>
    <dc:creator>jm</dc:creator><description><![CDATA['an expressive toolset for constructing scalable, resilient [service] architectures. It works in the cloud, in the data center, and on your laptop, and it makes your system diagram visible and inevitable. Inevitable systems coordinate automatically to interconnect, removing the hassle of manual configuration of connection points (and the associated danger of human error).'  Looks like a pretty neat cluster deployment tool; driven from a single configuration file, using Chef, integrating closely with AWS and providing many useful additional features]]></description>
<dc:subject>chef deployment clusters knife services aws ec2 ops ironfan demo</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:ed73e23aae92/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:chef"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:deployment"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:clusters"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:knife"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:services"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ec2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ironfan"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:demo"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://smarden.org/runit/index.html">
    <title>runit</title>
    <dc:date>2013-01-24T21:05:51+00:00</dc:date>
    <link>http://smarden.org/runit/index.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA['a UNIX init scheme with service supervision' - philosophically similar to daemontools, widely packaged, LSB init.d-script-compliant, BSD-licensed]]></description>
<dc:subject>daemon supervision services unix lsb server ops</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:c5a9592af5d4/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:daemon"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:supervision"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:services"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:unix"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:lsb"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:server"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://perspectives.mvdirona.com/2011/03/26/PrioritizingPrinciplasInOnDesigningAndDeployingInternetScaleServices.aspx">
    <title>Brad Porter's top five principles from &quot;On Designing and Deploying Internet-Scale Services&quot;</title>
    <dc:date>2011-03-27T22:47:53+00:00</dc:date>
    <link>http://perspectives.mvdirona.com/2011/03/26/PrioritizingPrinciplasInOnDesigningAndDeployingInternetScaleServices.aspx</link>
    <dc:creator>jm</dc:creator><description><![CDATA[still fantastic advice, even after 4 years.  I think it's time for a re-read]]></description>
<dc:subject>internet software james-hamilton design architecture coding advice services scaling reliability</dc:subject>
<dc:identifier>https://pinboard.in/u:jm/b:aae2778d4b3c/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:internet"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:software"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:james-hamilton"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:design"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coding"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:advice"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:services"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scaling"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:reliability"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://arstechnica.com/business/data-centers/2010/02/what-second-life-can-teach-all-companies-about-scaling-web-apps.ars/4">
    <title>What Second Life can teach your datacenter about scaling Web apps</title>
    <dc:date>2010-02-03T12:33:37+00:00</dc:date>
    <link>http://arstechnica.com/business/data-centers/2010/02/what-second-life-can-teach-all-companies-about-scaling-web-apps.ars/4</link>
    <dc:creator>jm</dc:creator><description><![CDATA[good scaling advice from Linden Labs' Ian Wilkes (who doesn't seem to have a blog, sadly)]]></description>
<dc:subject>linden ian-wilkes scaling datacenters scalability deployment ops services</dc:subject>
<dc:identifier>https://pinboard.in/u:jm/b:29fd0403ad9b/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linden"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ian-wilkes"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scaling"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:datacenters"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scalability"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:deployment"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:services"/>
</rdf:Bag></taxo:topics>
</item>
</rdf:RDF>