ACM named Sir Tim Berners-Lee, a Professor at Massachusetts Institute of Technology and the University of Oxford, the recipient of the 2016 ACM A.M. Turing Award. Berners-Lee was cited for inventing the World Wide Web, the first web browser, and the fundamental protocols and algorithms allowing the Web to scale. Considered one of the most influential computing innovations in history, the World Wide Web is the primary tool used by billions of people every day to communicate, access information, engage in commerce, and perform many other important activities.
The ACM Turing Award, often referred to as the “Nobel Prize of Computing,” carries a $1 million prize, with financial support provided by Google, Inc. It is named for Alan M. Turing, the British mathematician who articulated the mathematical foundation and limits of computing.
Apache BookKeeper is a high-performance and low-latency cloud storage service, originally designed for write ahead logging. Since its original development, BookKeeper has been expanded and is now used by companies including Twitter, Yahoo, Salesforce, Huawei, and EMC.
In their presentation at the recent Vault conference, Venkateswararao Jujjuri (JV) from Salesforce and Sijie Guo from Twitter provided an overview of Apache BookKeeper and showed some production use cases. In this interview, they provide some additional implementation details.
Linux.com: Can you give our readers some background information about Apache BookKeeper? Why was it developed?
JV and Sijie: Apache BookKeeper was originally developed as a sub-project under Apache ZooKeeper. It was designed for high performance and low latency write ahead logging, with strong consistency, replication and strong durability support. It was originally developed for the HA solution of HDFS.
Right now, it has grown beyond its original scope to become a scalable, high throughput and low latency storage service. It is widely used by multiple companies, like Twitter, Yahoo!, Salesforce, Huawei, EMC. There also various projects that have built over BookKeeper, like Apache DistributedLog and Yahoo Pulsar.
Linux.com: How does it work?
JV and Sijie: BookKeeper is a CP system for immutable data (w/ deletes). Hence, the added immutability of its data gives great availability in addition to its consistency and partition tolerance. It is a thick client scale-out distributed system and makes cap-adds a breeze. Bookkeeper uses ZooKeeper as its metadata store and also consensus engine to manage/maintain the cluster.
The beauty of the design is that interaction with the metadata server is very very minimal. The client talks to the metadata server only during open/create and close times of the ledger, and it doesn’t come in the IO path. This gives greater performance that is less prone to failures.
Linux.com: Are there similar products available? How does it differ?
There are tons of products that offer scale-out storage solutions. But what makes BookKeeper unique is its ability to offer a short-tailed, low-latency, distributed scale-out storage solution. Although this is a CP system, its greater availability makes it almost a C(A)P system. It is an apt storage for immutable data.
Linux.com: Have you encountered challenges in its implementation? If so, how have you addressed them?
JV and Sijie: Yes. There are a lot of interesting implementation details inside Apache BookKeeper. For example, Apache BookKeeper has very low latency with high throughput while still maintain strong consistency and durability.
This is because of various reasons:
First of all, the storage was designed for I/O isolation. It separates the journal disk (which requires large sequential writes and group fsync to persist data) from the ledger disks (which are used for storing indexed data, require fast random reads) physically. So, it avoids the I/O contention between writes and reads, to achieve low latency while we do fsync to ensure durability.
Second, we use a quorum-vote protocol on writing data. Data is written parallel to multiple replicas and the client is waiting for acknowledges from majority. It helps reduce the write latency to avoid impacts from any slow bookies.
Third, at read side, we use a speculative read mechanism on reading data. The speculative mechanism works in this way: The client first issues one read request to one of the replicas, if the read request doesn’t respond with a given time (speculative read timeouts), it will then issue a second read request. The client will wait for responses from both requests. The first responded request will satisfy the read request. If we tune the speculative read timeout to be aligned with 99.9th percentile latency, we will reduce the tail latency.
There are also other interesting aspects in Apache BookKeeper, such as how we ensure consistency, how we do group fsync, etc. Feel free to reach out to us at mailing list: user@bookkeeper.apache.org and dev@bookkeeper.apache.org.
Linux.com: What additional features or further development are planned for Apache BookKeeper?
JV and Sijie: Apache BookKeeper has been successfully used in messaging or streaming area for real-time data. As we grow the project to support more storage use cases, we want to make sure it can also be use a very good long-term storage. We are also working with multiple cluster schedulers (like Mesos and Kubernetes) to make sure it can run easily in different cloud environments. Security is also another big feature coming out in the next release 4.5.0. It will be available soon — around April/May.
Learn first-hand from the largest collection of global Apache communities at ApacheCon 2017 May 16-18 in Miami, Florida. Linux.com readers get $30 off their pass to ApacheCon. Select “attendee” and enter code LINUXRD5. Register now >>
OPNFV said its fifth platform release brings development and operations methodologies to the NFV space, and is a “turning point” for organization.
The Linux Foundation’s Open Platform for NFV project launched its fourth platform release, dubbed “Danube,” which the organization said provides key architectural components and improvements designed to foster the adoption of network functions virtualization systems.
OPNFV said the platform, which was released at this week’s Open Networking Summit, brings development and operations methodologies to the NFV space through “collaborative upstream development, integration, deployment and significant continuous integration/continuous development testing automation.”
Blockchain, the technology that made Bitcoin possible, has been getting a lot of attention in the IoT world, often because of its role in security. However, experts and practitioners said the potential of blockchain for IoT is deeper and broader than just keeping the bad guys out.
Ian Hughes, analyst of IoT at 451 Research, sees a role for blockchain that goes deeper, enabling authentication of devices — especially when they are connected infrequently, as the case might be with, say, agricultural systems that may shut down for large parts of the year. Having a blockchain distributed ledger can provide a tidy way to account for and recognize the return of long-lost network participants as trusted members.
As compelling as new languages like Rust are for building systems, C and C++ remain fundamental for writing applications that run close to the metal, despite the waxing and waning of their usage statistics.
What’s more, the culture of tools for C/C++ development remains deep and fruitful. Here are five C-related projects — compilers, libraries, and support tools — that caught our eye recently, whether for bolstering existing projects or starting new ones.
In my previous post, I wrote about a simple process for triaging vulnerabilities across applications. Once you have the issues prioritized, the vulnerability remediation process is pretty straightforward. You don’t have a lot of options; either remediate the issue, ignore it, or apply other measures (compensating controls) to mitigate the risk posed by the vulnerability.
1. Rip and Replace
This is the most common approach taken. Essentially, you are going to fix the problem by “amputating” the vulnerable component and replacing it with a component that fixes the vulnerability (either directly or by using a different open source project).
Together, Kubernetes and gRPC, provide a comprehensive solution to the complexities involved in deploying a massive number of microservices to a cluster.
One of the most exciting parts of being in this industry over the past couple of decades has been witnessing the transformative impact that open source software has had on IT in general and specifically on networking. Contributions to various open source projects have fundamentally helped bring the reliability and economics of web-scale IT to organizations of all sizes. I am happy to report the community has taken yet another step forward with FRRouting.
FRRouting (FRR) is an IP routing protocol suite for Unix and Linux platforms which includes protocol daemons for BGP, IS-IS, LDP, OSPF, PIM, and RIP, and the community is working to make this the best routing protocol stack available.
FRR is rooted in the Quagga project and includes the fundamentals that made Quagga so popular as well as a ton of recent enhancements that greatly improve on that foundation.
Here’s a bird’s eye view of some things the team has been busy working on:
32-bit route tags were added to BGP and OSPFv2/v3, improving route policy maintenance and increasing interoperability in multivendor environments;
Update-groups and nexthop tracking enable BGP to scale to ever-increasing environments
BGP add-path provides users with the ability to advertise service reachability in richly connected networks
The addition of RFC 5549 to BGP provides IPv4 connectivity using IPv6 native infrastructure, enabling customers to build IPv6-centric networks;
Virtual routing and forwarding (VRF) enables BGP users to operate isolated routing domains such as those used by web application infrastructures, hosting providers, and Internet Service Providers
EVPN Type 5 routes allow customers with Layer 2 data centers to exchange subnet information using BGP EVPN
PIM-SM and MSDP enable enterprise applications that rely on IP multicast to use FRR
Static LSPs along with LDP enable architects to use MPLS to engineer network data flow
An overhaul of the CLI infrastructure and new unit test infrastructure improves the ongoing development and quality of FRR
Enabling IETF NVO3 network virtualization control allows users to build standards-based interoperable network virtualization overlays.
The protocol additions above are augmented by SnapCraft packaging and support for JSON outputs, both of which improve the operationalization of FRR.
Pretty cool stuff, huh? The contributors designed FRR to streamline the routing protocol stack and to make engineers’ lives that much easier. Businesses can use FRR for connecting hosts, virtual machines, and containers to the network; advertising network service endpoints; network switching and routing; and Internet access/peering routers.
Contributors from 6WIND, Architecture Technology Corporation, Big Switch Networks, Cumulus Networks, LabN Consulting, NetDEF (OpenSourceRouting), Orange, Volta Networks, and other companies have been working on integrating their advancements and want to invite you to participate in the FRRouting community to help shape the future of networking.
Although it is true that microservices follow the UNIX philosophy of writing short compact programs that do one thing and do it well, and that they bring a lot of advantages to a framework (e.g., continuous deployment, decentralization, scalability, polyglot development, maintainability, robustness, security, etc.), getting thousands of microservices up and running on a cluster and correctly communicating with each other and the outside world is challenging. In this talk from Node.js Interactive, Sandeep Dinesh — a Developer Advocate at Google Cloud — describes how you can successfully deploy microservices to a cluster using technologies that Google developed: Kubernetes and gRPC.
To address the issues mentioned above, Google first developed Borg and Stubby. Borg was Google’s internal schedule manager. When Google decided to use containers 10 years ago, this was a new field, so they wrote their own stuff. Borg ended up scheduling every single application at Google, from small side projects to Google Search. Stubby, Google’s RPC framework, was used for communication between different services.
However, instead of putting Borg and Stubby on GitHub as open source projects, Google chose to write new frameworks from scratch in the open, with the open source community. The reason for this is that both Borg and Stubby were terribly written, according to Dinesh, and they were so tied to the Google’s internal infrastructure as to be unusable by the outside world.
That is how Kubernetes, the successor of Borg, and gRPC, a saner incarnation of Stubby, came to be.
Kubernetes
A common scenario while developing a microservice is to have your Docker container running your code on your local machine. Everything is fine until it is time to put it into production and you want to deploy your service on a cluster. That’s when complications arise: You have to ssh into a machine, run Docker, keep it up with nohup, etc., all of which is complicated and error-prone. The only thing you gain, according to Dinesh, is that you have made your development a little bit easier.
Kubernetes offers a solution in that it manages and orchestrates the containers on the cluster for you. You do not have to deal with machines anymore. Instead you interact with the cluster and the Kubernetes API.
It works like this: You dockerize your app and pass it on to Kubernetes in what’s called a Replication Controller. You tell Kubernetes that you need, say, four instances of your dockerized app running at the same time, and Kubernetes manages everything automatically. You don’t have to worry about on which machines your apps run. If one instance of your microservices crashes, Kubernetes will spin it back up. If a node in the cluster goes offline, Kubernetes automatically distributes the work to other nodes.
With random pods and containers spinning up on random computers, you need a layer on top that can route traffic to the correct Docker container on the correct machine. That is were Kubernetes’ services come into play. A Kubernetes service has a static IP address and a DNS host name that will route to a dynamic number of containers running on the system. It doesn’t matter if you are sending traffic to one app or a thousand — everything goes through your one service that distributes it to the containers in your cluster transparently.
All of that taken together, the dockerized app embedded in its replication controller, along with its service, is what in Kubernetes makes up one microservice. Obviously, you can run multiple microservices on one cluster, you can scale certain microservices up or down independently, or you can roll a microservice up to a new version, and, again, it will not affect other microservices.
gRPC
When you have multiple microservices running, communications between them becomes the most important part of your framework. According to Martin Fowler: The biggest issue in changing a monolith into microservices lies in changing the communication pattern.
Communication between microservices is done with Remote Procedure Calls (RPCs) and Google has 1010 RPCs per second. To help developers manage their RPCs they created gRPC.
gRPC supports multiple languages, including Python, C/C++, PHP, Java, Ruby and, of course, Node.js; and uses Protocol Buffers v3 to encapsulate data sent from microservice to microservice. Protocol Buffers are Google’s language-neutral, platform-neutral, extensible mechanism for serializing structured data. In many ways it is similar to XML, but smaller, faster, and simpler according to Google. “Protocol Buffers” is technically an interface definition language (or IDL) that allows you to define your data once and generate interfaces for any language. It implements a data model for structured request and response, and your data can be compressed into a wire format, a binary format for quick network transmission.
gRPC also uses HTTP/2, which is much faster than HTTP/1.1. HTTP/2 supports multiplexing, opening a single TCP connection and sending all the packages over that. HTTP/1.1 opens a new connection every single time it has to send a package, which adds a lot overhead. HTTP/2 also supports bidirectional streaming, which means you do not have to do polling, sockets, or Server Send Events, because it allows you to do bidirectional streaming on the same single TCP connection easily. Finally, HTTP/2 supports flow control, allowing you to solve congestion issues on your network should they occur.
Together, Kubernetes and gRPC, provide a comprehensive solution to the complexities involved in deploying a massive number of microservices to a cluster.
If you’re interested in speaking at or attending Node.js Interactive North America 2017 – happening October 4-6 in Vancouver, Canada – please subscribe to the Node.js community newsletter to keep abreast of dates and deadlines.
