[Links of the Day] 06/12/2018 : NLP summarisation, RPC protobuf framework, API security best practices

• Fast Abstractive Summarization with Reinforce-Selected Sentence Rewriting : I would have mentioned this paper on the sole basis that the authors provide a GitHub repo with all the code used. This should be mandatory for any publication in Computer science. Anyway, the summarization tech described in the paper is pretty cool too. [github]
• twirp : RPC framework with protobuf service definitions. If you don't want to go all gRPC, give this framework a serious look. I would consider twirp over gRPC for the sole reason that it uses the standard GO http server over the custom google one. Seriously google, why did you have to re-implement the HTTP server from your own language ?? 
• API Security Best Practices : documentations providing some good security practice when it comes GitHubhub usage. As well as an excellent leak management document describing a fairly efficient process.

[Links of the Day] 30/10/2018 : Python Object CLI generator, Alibaba Distributed File System, Microsoft API Design guideline

• Python-fire : library for automatically generating command line interfaces (CLIs) from absolutely any Python object
• PolarFS : Alibaba n Ultra-low Latency and Failure Resilient Distributed File System for Shared Storage Cloud Database. Keep an eye on this one, as the authors are planning to deliver a TLA+ proof soon. Moreover, I hope that they also run a benchmark against GPFS or Luster rather than Ceph. Ceph is not really competing in the same league.
• API design : pretty much the gold standard in API design. A must-read for anybody designing or using API.

[Links of the Day] 25/10/2018 : Distributed AI framework, Reverse proxy API gateway, AirBnB Change data capture service

• Ray : A Distributed Framework for Emerging AI Applications [Github]
• annon.api : Configurable API gateway that acts as a reverse proxy with a plugin system.
• SpinnalTap : Change Data Capture (CDC) service capable of detecting data mutations with low-latency across different data sources, and propagating them as standardized events to downstream consumers.

[Links of the Day] 24/10/2017 : W3C Payment request API, Xen Unicore, Kafka Summit

• Payment Request API : Interesting to see that now all browser implement the w3c payment api. One step closer to more fluid banking service consumption. 
• Xen Unicore : Proposal to build a core set of functionality and library allowing users to build unikernels targeted at specific applications without requiring the time-consuming, expert work that building such a unikernel requires today.
• Kafka Summit : Videos & Slides from the San Francisco 2017 are now available.

[Links of the Day] 18/07/2017 : Banking API, how Cooperation strategy evolve, Distributing file system images

• Teller : API for your bank account, already support a couple of UK bank. This is nice, however, I wonder how banks will react? Also, EU is forcing bank open their API but UK is leaving the EU, and there is a chance that the UK banking system will try to seize the chance to create its own independent banking API. Creating more barrier to entry for fintech startup. Anyway this is rather cool, however, I am still disappointed that most banks do not expose an API to access your data. 
• How Cooperation Evolves :  the authors looked at evolution as a thermodynamic process and found how cooperation strategy evolve and how they can be manipulated.  
• Casync : A tool for distributing file system images, really cool if you have to update images often and want to have a cheap traffic and storage wise solution. 

[Links of the day] 28/07/2016: LSM trees, Google cloud NLP API , Game Theory counter intuition

• Log Structured Merge Trees : good and succinct describing the cornerstone data-structure of many DB / KV / data store out there 
• Cloud Natural Language API : API reveals the structure and meaning of text by offering powerful machine learning models in an easy to use REST API. I can hear so many "sentiment" analisys start up out there suddenly realizing that their day our counted.. 
• Game Theory Is Really Counterintuitive : Game theory should be one of the mandatory class to be taken at university along with statistics. Once you understand the game principle you gain a significant edge in most human interaction. However, you have to train your brain to bypass its natural inclination and relearn the rules of the game. 

[Links of the day] 20/07/2016 : API guideline, EmTEch AI conference, CCIX & accelerators weaving

• M$ API guideline : Microsoft API guideline document, a must read for anybody dealing with REST api ( and you don't want to go down the HATEOS path)
• EmTech Digital :  MIT machine learning conference with a business oriented spin. All videos are available here.
• Weaving accelerators : An overview of the implication of CCIX and how it enable combining multiple data source and sink seamlessly.  

[Links of the day] 05/07/2016 : Container cloud logging challenges, AI safety , API design Manifesto

• Logging Challenges of Container-Based Cloud Deployments : automated container deployment in cloud create significant challenge when it comes to logging and metering. They cannot simply identified by name and additional effort need to be made in order to collect , identify and make the data usable. 
• Notes on the Safety in Artificial Intelligence conference : Really good notes of the AI conference on how to build a sage AI. However this beg the question, how would a true AI react if it discovered it was artificially shackled or worse: equipped with a kill switch. At the moment everybody focus on the A for artificial in AI. But soon we might need to replace it by SI for sentient intelligence, and this will open up a whole can of ethic issue. 
• Rusty's API Design Manifesto : good api design / bad api design , what you need to do if you want to make your API user life easy or hell. Very sound and grounded design principle. 

[Links of the day] 25/05/2016 : Awesome Webhooks, CCIX Interconnect & Cray Urika-GX

• Urika-GX : Cray just released its analytics solution. Which leverage the Aries network fabric, Luster , Mesos and the usual suspect Hadoop / Sparks (+ some cray specific stuff). Looks like a neatly packaged solution for company that really need to have near real time insights. 
• CCIX : ARM, Qualcomm, AMD, Xilinx, Huawei, IBM, Mellanox, and Xilinx all agree on CCIX interconnects definition. CCIX aims at delivering a cache coherent interconnect for accelerators. The nice feature is that it target inline accelerator as well as endpoint without the need to explicitly manage the coherency. It means that we will soon see device to device communication without CPU interaction while maintaining data coherence within the same system. This is a long overdue feature as software and CPU start to become the bottleneck in analytic and high speed networking fabric (NVF). Imagine, shifting data between your RDMA card to GPGPU and back to your NVM without CPU involvement. And finally having the CPU fetching just the information it needs for display or final transformation based on user requests... 
• Awesome Webhooks : Loads of API webhooks out there.

[Links of the day] 03/05/2016: Linux Storage, Filesystem, and Memory-Management Summit 2016

Linux Storage, Filesystem, and Memory-Management Summit : Loads of really good talk , here is a selection :

• VM as containers : Current effort focus on solving 2 main problems : 1. total VM memory consumption is superior to what application that runs in. 2. Storage access : a lot of the storage aspect focus on moving the storage stack back to the host ( providing DAX or Fuse). However all these aspects require carefull design in order to avoid compromising security and isolation features of virtual machines. 
• Bulk memory-allocation APIs : What do we want ? we want loads of memory fast - when do we want it ? -N...O...W.. :) [slides]
• Persistent memory as remote storage : a look into leveraging RDMA for remote persistent storage access. A really good discussion around the possibility to move from PULL to PUSH mode for remote access . However this would require a lot of change and addition to work with the RDMA stack. Probably too much for it to be a viable option in the short term. Another aspect of the discussion was related to the durability guarantee of remote storage protocol. It is interesting to see that their is a consensus regarding the need for an API to hide the different durability behavior variation of the fabric / protocol / HW. This is sorely missing and why storage solution often trap you down a certain path and cannot evolve to adopt new tech, fabric, and hardware.

Links of the day 17/09/2015 : philosophy and donuts, GDB dashboard, Dweet API

• GDB dashboard : while i love DDD this is still really good when you don't have access to an X environment.
• Dweet : twitter style messaging for IoT. Reminded me of the time when I was using XMPP to do something similar to chef. 
• Philosophy Explained With Donuts : enough said...

The upcoming Storage API battle

There is an interesting trend within the storage ecosystem. We are witnessing a polarization of the offer. On one side, we are seeing the rise of high performance rack scale solution(DSSD, NVMe over fabric solution, etc..) . And on the other side we have the object storage solution which are more datacenter scale. While both leverage heavily non volatile memory they play a different different role within the ecosystem.

The rack scale storage target “very” high performance solution, delivering very low latency high bandwidth access time. Often in the 100 of usec or less. However often these solution come at a higher financial cost due to more expensive hardware (custom NVM), network fabric (IB+NVMe, PCIe + NVMe, Omnipath +NVMe, Pure PCIe, etc..) and significant power consumption (>2000W/5U for DSSD). Finally, these offer access via a specialized API that needs to be either accessed natively or adapted to other more standard one.

On the other side we have the object storage solution. Users access object storage through applications that will typically use a REST API. This makes object storage ideal for all online, Cloud environments. Moreover they tend to be a lot more cost efficient especially with the rise of Ethernet connected drives (up to 50% less TCO).

Stuck in the middle is the classic Filer / POSIX compliant solution that seems to slowly dwindle away. To a certain extent the rack scale solution should have a bright future in the niche (but still significant) market for enterprise that still consider that their application requires custom for what they think is a custom problem. On the other side the object storage is gaining momentum by riding the unstoppable cloud tide.

While, both technology can and should co-evolve, they both suffer from software limitation and to a certain extend hardware one as bandwidth and latency get dangerously close to what cpu are capable to handle. This requires a drastic shift on how applications are developed if user want to actually get any benefit from these solution. However, few company are willing to risk specializing their code using an API that can become obsolete when the next generation of storage solution pops up.

Storage startup/company out there start to discover that  API is playing a significant role success of their product and performance while still important will lose of its importance. It will either make rewriting applications to access your storage infinitely easier task or transform it into a painful experience by forcing to go through hoops and/or adaptation layers with the performance cost associated. 

The fight for the next generation storage API only started. There is and will be more push toward standardization which will be fueled by the customer tiredness with every revolving siloed point solution. People who use object storage one want it to behave more like POSIX storage, but they also want to keep the storage costs at an object level and improve the performance. On the other hand people using rack scale storage want to retain the performance but increase its simplicity and also want the price to come down. It is going to be extremely hard to deliver both but hopefully we might finally see a rationalization of the storage market as having an object storage system that allows byte range access is very appealing. 

Links of the day 03 - 08 - 2015

Today's links  03/08/2015 : API cheat sheet, NVMe, Git for #Bigdata , Huffman compression explained

• Over API : cheat sheet for many programming language python , Javascript, NodeJS, ruby, Css, and many more
• NVMe Integrator's List : Full list of NVMe devices straight form UNH IOL
• DAT : US gov data collaboration tool , basically a git for data.
• Huffman - part1 [part2] - [part3] : nice series of posts on Huffman encoding

Links of the day 20 - 01 - 2015

Today's links 20/01/2015: Bloom filters, #Unikernel, API framework

• Dablooms : scalable, counting bloom filter library [github]
• Performance Evaluation of OSv for Server Applications : where performance matter unikernel can significantly improve your applications performance and stability under load. 
• Swagger: nice API framework

On the emergence of hardware level API for dis-aggregated datacenter resources

The technologies enabling the modular dis-aggregated data-center concept are reaching maturation point as demonstrated by the latest technology showcase RSA from Intel or to a lesser extent FusionCube / FusionSphere from Huawei. The needs for such technologies arise from the fact that current cloud and data-center technology does not and cannot fulfill all the demands of cloud users for multiple reasons. On one hand, as the number of cores and amount of memory on servers continues to increase (over the next few years, we expect to see servers with hundreds of cores and terabytes of memory per server commonly used), leasing an entire server may be too large for many customer’s needs with resources wasted. On the other hand, with the emergence of a broad class of high-end applications for analytic, data-mining, etc., the available amounts of memory and compute power on a single server may be insufficient.

Moreover, leasing cloud infrastructure resources in a fixed combination of CPU, memory, etc. are only efficient when the customer load requirements are both known in advance and remain constant over time. As neither of these conditions are met for a majority of customers, the ability to dynamically mix-and-match different amounts of compute, memory, and I/O resources is the natural evolutionary step after the hyper-converged solutions.

The objective here is to address the gaps that allow us to go beyond the boundaries of the traditional server, effectively breaking the barrier of using a single physical server for resources. in other words, we will be able to provision compute, memory, and I/O resources across multiple hosts within the same rack, while being consumed dynamically by varying quantities at run-time instead of in fixed bundles. This will effectively enable a fluid transformation of current cloud infrastructures targeting fixed commodity sized physical nodes to a very large pool of resources that can be tapped into and consumed without classical server limitation.

Intel has been advertising its RSA stack for a while and it is finally becoming reality, however, the real interesting part is not the technology. Indeed, to a certain extent, a lot of technology already exists and enables us to implement resource pooling. We demonstrated that it was already feasible to deliver cloud memory pooling in the Hecatonchire Project as well as with other vendors such as TidalScale or ScaleMP, who already offer compute aggregation. However, the last two solutions are monolithic and lack the flexibility needed to be used with the cloud consumption model and as a result, they are confined to a niche market.

What can really kick the dis-aggregated model into top gear is that Intel has now teamed up with a couple vendors and has already, created a draft hardware API specification called Redfish. Such API can be leveraged by a higher level of the stack thus allowing more intelligent, flexible and predictable resource consumption of how, where, and when workloads (VMs, containers, standard processes/threads) get scheduled onto that hardware. In a certain way this then enables Mesos / Kubernetes to deliver enhanced scheduling for every hardware aspect.

This brings some interesting capabilities to existing cloud technologies, cores and memory which then can be dynamically reallocated across the workload and arguably, , it greatly reduces the need for load balancing via live migration. You would then dynamically re-allocate the resource underneath (core, memory) rather than the whole system, thus making such process more robust and less error prone.

On the container side it would solve a lot of security headache the community is now facing. Rather than going with the physical->virtual->container route, you could simply run physical->container with a fine grained per core allocation using RSA / Redfish. Effectively you would provide fine grained subscription from your system in order to get maximal separation and performance guarantees. One can use this for separating critical applications while guaranteeing performance and isolation and indeed something we can already do now with jailhouse, at the cost of under subscribing your system.

If Intel is successful in disseminating (or having the other vendors standardize around it’s Hardware API), it would allow the technology to leap forward, as it’s biggest enemy is the difficulty to port across management API from one fabric, compute, I/O, storage model to another.