#calhacks

This past week’s blog posts were very centered on Finagle, and the idea of scaling. Marius Eriksen made this the focus as he talked about how twitter handled their scaling problem.

A common theme among the blog posts were the idea of data centers and horizontal scaling. Unlike vertical scaling, horizontal scaling is most focused on the idea of adding new computers to the data center. One thing Marius made clear was that data center computers really are not meant to handle modern day applications, as very little has been done to improve them in years. The problems with data centers were a clear focus, with a common theme being addressing the fact that data centers often involve partial failures and painful abstractions.

Another common theme was the idea of RPCs, and using Finagle as a RPC as a means of avoiding the headaches commonly seen in data centers. This idea communicated that data centers could use RPC as a means of creating a more natural way of communication between the user and the data center. Using finagle’s model of fixtures, services, and filters, the use of an RPC becomes much clearer.

This week we had Eric Baldeschwieler from Apache Hadoop. Hadoop is an open source framework for data computation and distributed data storage that can be run on commodity hardware. Hadoop is very modular, allowing the components to be developed by different teams while still working towards a common goal. The most popular parts of Hadoop are MapReduce and HDFS, which is Hadoop’s distributed file system. Hadoop follows an interesting principle for warehouse scale computing, which is that all of this software should be able to run on commodity, off the shelf hardware rather than purpose built machines that optimize for one certain task. This allows data center operators to cost optimize and scale more quickly with off the shelf hardware rather than purchasing a large software/hardware package from a company such as Oracle. It’s 100 times cheaper to store your database in Hadoop as well.

Hadoop does huge data processing well. That’s what it was built for. A frequent problem in web scale companies today is that they have no methods to take enormous datasets, condense them down and parse useful metrics out of them. That’s where MapReduce comes in. For anyone that’s taken 61C at Berkeley, they’ve used MapReduce or its newer cousin Spark to parse a large dataset and get useful information out of it. MapReduce works by distributing the computational load across many different computers, allowing the work to be completed quickly and in parallel. As with any task that is completed in parallel, the task must be well suited for being completed in this manner, a task that was extremely computation intensive but not very data heavy would not be well suited for example.

This week, we had Marius Eriksen from Twitter come in to tell us about Finagle and handling scale by talking about the paradigm of data centers. One thing that Marius focused on was understanding what a datacenter is, and the problems that are inherent in working with a data center. Even though these machines are powerful and useful, they are inherently terrible, wrought with problems. Such problems include partial failures, being hard to program, and abstraction that is an absolute pain to handle. In addition to this, most modern software is not optimized for data centers, instead it is optimized for local computation and not the models that a data center is meant to support. Because of this, we need a new paradigm to understand the best way to tackle these issues, and that comes with a modular model to these data centers.

Finagle helps different processes interact with each other in a datacenter scheme for a web scale big data application. A seemingly harmless request may have to traverse many different databases or pull data from different servers, it’s easy to introduce errors if you spend a lot of time parsing data between sources so Finagle provides a consistent interface across the different sets. Because Finagle was conceived for the datacenter, most of the code is asynchronous, allowing your processor to do other important things while it waits for a request to finish. This allows for cleaner code and easier optimizations because of the asynchronous nature of Finagle.

This week we had Brad Fitzpatrick, a software engineer at Google and the maintainer of the Go standard library come in to speak to us about the improvements made in HTTP2, and how they addressed the flaws that came up within the original version of http.

One fundamental point about HTTP that led to the creation of HTTP2 was that the protocol had remained relatively untouched since 1999, and had not evolved as the web, and the content being served over the protocol had. Thus, for new use cases, such as mobile, the old HTTP was just not optimized to work well. Minor improvements that had been made from 1999 to 2013, such as the idea of pipelining, simply did not work, or had such little adoption that they found themselves effectively useless. HTTP was originally built to handle one thing at a time, with the slow startup time provided through the TCP handshake and huge requests being passed back and forth. In addition, shutdowns were not quick, and, in turn, these problems just did not support the modern web. Because of this, HTTP2 was born.

HTTP2, as most standards are, was created out of a slew of committees and as such took into account the design concerns of all of the parties with a vested interest in how the standard was implemented. Of particular note is the fact that HTTP2 operates entirely over the secure socket layer, which provides end to end encryption. This allows HTTP2 to enact new interactions without the interference of a middleman. The new standard greatly improves latency on a connection with latency, allowing for multiple streams of data to be delivered at the same time. This allows something like a tiled image to be streamed to the user rather than holding two or three connections to different web servers to download each tile as in HTTP1. The new standard also allows for push promise messages, which are resources that the server sends, knowing or thinking that the client will need them before the client asks, again improving round trip time. HTTP2 improves on most of the major issues with previous versions of the protocol.

Kubernetes take the complication out of managing cloud infrastructure. What it allows the developer to do is worry about the design and operation of the server and not worry about the physical machine that their code is running on at all. Application oriented architecture gives the developer freedom to create their code as well as gives the manager freedom to contract services out rather than doing them in house. The Kubernetes approach is to have the user express a desire, while the system expresses a state, then the system reconciles the two states to be equal without interaction or involvement by the user. The approach firmly enforces the bounds of abstraction in order to provide a unified, API like view for the user to see of the cloud.

Kubernetes isn’t alone though. It is one of an increasing number of tools designed to simplify the life of a dev ops engineer and increase the deployment capabilities of a project. The most well known of these in recent times is Docker. Docker’s approach is to containerize projects, essentially creating an upgraded version of a VM, thereby allowing for rapid and easy deployment and management. It is perhaps a testament to Docker’s own success and effectiveness that Kubernetes interfaces with Docker for managing individual machines.

This past week’s blog posts focused on the newly invented paradigm of Platforms as a Service. Platform as a service focuses on one core tenet: that as an engineer on a project, the goal is for the project itself to be as polished and usable as possible. For this reason, Noah encouraged the idea of using platforms throughout a product as much as possible because, as an engineer, it allows you to solve the problems your customers want solved, and leaves the coordination to the experts. The ideal way to develop an application, Noah argued, is to focus on what you know best, your product and your customers, and to focus on your business logic without wasting precious time on boilerplate and architecture. Instead of having to make monolithic applications, the platforms would be able to keep your code scalable and maintainable.

In order to allow for this PaaS philosophy to work, platforms must meet several criteria to be truly useful. As a PaaS-based platform, it is vital that users can navigate and utilize the platform easier that they could create that platform for themselves. Thus, API’s should be machine and human readable, and executable examples must be given. In addition, platforms should run on themselves, in order to ensure that they are able to empathize with the users’ concerns and know where problem points are within the application.