#appnarok

Systems-level data technology is rapidly evolving. Unfortunately this means best platform for data science and big data is different every year. Honestly, this is the main reason why I hate systems engineering. Most data scientists use R, with large-scale experiments being handed off to data engineers. With the architecture changing so much, there doesn’t appear to be much reason for an application-level, software engineer to learn systems just for the sake of learning them. Although Hadoop is still great for processing unstructured data, numerous other tools like Spark are maturing for processing structured data. Spark has the additional advantage of working mostly in memory, often resulting in much faster queries.

It seems to me that more and more things are becoming declarative. All I have to say is what I want and not how. SQL is declarative, Software Defined Networks are declarative, and now server scalability is declarative. Who has time or the money to worry about partial server failures in one’s application code? Enter Finagle, a system for managing procedure calls between your different services. When your product isn’t engineering how to get Cassandra to reliably ingest data from your data pipeline, Finagle is one step closer to allowing you to buy the services you need, integrate them into your stack, and get back to building your app.

Futures express dependencies between asynchronous operations and serves as a container to hold results until all responses are available. A future is either empty, succeeded, or failed. This allows one to abstract the unwieldy state diagrams of TPC, 2PC, and other methods of ensuring messages get across and data maintain ACID properties. In a large scale distributed system, servers can fail and data can be lost and cause cascading failures. Accounting for this is hard, and only companies like Google and Twitter can write good concurrent code. Most of us are stuck with outsourcing our services, but even then communication can be faulty. Thank you Finagle.

Another declarative tool to help expedite development and implementation of scalable backends is Thrift which allows seamless communication between different languages by defining an interface and uses code generation underneath the hood. No more serializing and unserializing and unwieldy java code to handle failure cascades.

Google recently announced that its experimental protocol QUIC is in use for half of all requests from Chrome to Google servers, and it could be a major challenger to the established HTTP/TCP stack. QUIC is built on top of UDP, which might sound insane, but actually has significant performance benefits for clients that have been to certain websites in the past. Unlike TCP, it can start communication immediately with known sites. Integrating QUIC into the rest of the internet is also completely feasible since UDP is a common protocol among machines. The benefits seem to outweigh the drawbacks so far (e.g. better YouTube streaming), but like any new technology, it’s questionable whether this will actually prove to be reliable and secure in practice. As discussed in a recent TechCrunch article, Google hopes that QUIC features will be integrated into TCP/TLS since it is harder to work on improving TCP itself. So if this actually happens, why sacrifice the reliability of TCP at all?

When making networked games TCP and http are mostly useless since game programmers need lower level control over what packets are sent when, and because TCP enforces reliability and ordering, with dropped packets stalling the receiver. Anyways, decreased latency and pushing instead of handshaking (or just faster handshaking) might reduce lag in networked games, alt. Encrypting headers will use up more CPU power, which is often already taxed with decompressing assets while the game is running. More security issues to.

Another protocol coming out of Google is the open networking protocol SPDY which manipulates HTTP traffic in order to reduce latency through multiplexing and compression. Support for SPDY will be withdrawn completely in 2016 to make way for HTTP/2.

HTTP/2 is the first version of HTTP since 1997 and is upgraded from HTTP/1.1. It came as a standardization answer to SPDY, which was open-source. Clients and servers can elect to use HTTP 1.1 or 2.0. This design decision of adoption via electivity can also be seen in other browser upgrade projects such as javascript 6. One exciting feature of HTTP/2 is decreased latency in page load speed through server pushing. Server pushing is a mechanism for sending asynchronous data from server to client. Currently this is done by keeping a connection open after the initial handshake via various means.

When I first heard about Kubernetes, a cluster management solution for containerized OS’s, I wondered why no one was talking about OpenStack in the same breadth since they appear to basically do the same thing at different levels of the stack. OpenStack lets you control provisioning of hardware systems, provides a hypervisor for its distributed system, the control to start up and stop physical clusters/machines on demand, and numerous other tools for handling synchronization, replication, networking, etc. Kubernetes allows you do the same sorts of things with virtual OS containers. I did a little digging, because I was skeptical that Kubernetes was actually solving an entirely new problem. OpenStack does indeed have frameworks and APIs for controlling containerized OS’s, although the names have changed, the latest version has Heat for orchestrating cloud services, with Glance being used for starting VM images and creating templates, (not quite containers) and various different modules for synchronization. The main difference is that Kubernetes lets you orchestrate containers, while OpenStack let’s you orchestrate hardware, templated Vms, and applications.

Mirantis has just made an agreement with google to integrate OpenStack and Kubernetes. The main benefit of this is Kubernetes makes it easy to transfer data between clusters as long as they both run Kubernetes, allowing people to transfer data between different cloud services, such as Google’s compute platform and Rackspace’s OpenStack. The new integrated module is called Murano. This has the potential to shake up the PAAS and IAAS industries a little bit. Portability was one of the original selling points of OpenStack, but there were still issues with moving data from clusters running one type of VM to others, and using a proprietary OpenStack cloud like RackSpace’s introduced numerous API incompatibilities when users tried to transfer their service to another cloud or build their own OpenStack cloud. Murano may solve those issues, or it might just become unfulfilled promise.

This week, Noah Zoschke from Heroku spoke to our class. He advocated that modern web apps can and should use a variety of services in their construction, as opposed to using one monolithic codebase. Each service should do one job and do it well. Therefore, like Unix, this approach to web application design has many strengths: each service is tailored to its specific task, and communication between services via standard APIs is universally understood and easy to accomplish. Developers can focus specifically on the functionality they are trying to create while leveraging the work of others in a clean and scalable fashion. Of course, this comes at a cost: the more services, the more overhead there is in communicating between them. Third-party services also must be highly reliable and available if so many other services are going to depend on them. Furthermore, if these services aren’t combined intelligently, it is possible for an app to degrade to an unintelligible blob - hard for new developers to ramp up on and arguably no better than a giant codebase. That being said, it is undeniable that web apps are moving in a service-oriented direction, and there are tried and true practices for intelligent composition of services (e.g. The Twelve-Factor App). Since Unix has stood the test of time well, the future certainly looks bright. -Ryan

One topic near and dear to my heart is that of microservices. The microservice architectural style is an approach to developing applications as suites of self-contained services that communicate to each other via an API. Each service is independently deployable, and thus independently scalable in both deployment and development. Features can be added and refactored in a microservice so long as its API doesn’t change. Microservice clusters under heavy load can be expanded without having to add compute power to other underwhelmened microservices. Teams do not have to store logic where it doesn’t belong since every microservice has its own stack. Microservices work and is the go-to architectural style. Facebook, Amazon, Etsy, Pinterest, and other technology leaders constantly release engineering blogs describing their architectural topology and deployment methods. Microservices are the programs and the net is the pipes.

Microservices often communicate to each other via HTTP. This allows a microservice to be used both internally and externally of a company. The mobile app and the web app one uses both use some of the same microservices, but have a different application layer. This supports the DRY principle of not redoing things. Also, because applications are conglomerations of microservices, individual components can be outsourced to more experienced domain developers. If you are a mobile-game company, your product is not databases or operations; but, mobile-games. With a microservice architecture, you can modularly add Ops services like Pager Duty or Splunk. You can replace your Storm cluster with Amazon Kinesis. You can host some of your services on PaaS such as Heroku. You have more flexibility.

One interesting and useful aspect of microservice architecture is the ease of deployment. One can put a microservice in a Docker container, upload it to AWS, deploy as needed, and orchestrate via Puppet/Chef. Compare this to the many deployment steps of a monolithic application the the difficulty in debugging as issues cascade from upstream.

All Systems Are (Eventually) Go

Go is a programming language meant specifically for scalability problems. As our speaker (and creator) of the language, Rob Pike, said, it was designed to have strong readability, scalability, suitability, and “toolability.” It seems like it addresses these four areas well. For readability, it is similar to other popular programming languages. Therefore, it should be easy enough to figure out, granted it is likely possible to come up with ugly, contrived, and unreadable examples. Go’s simplistic and intuitive way of handling variable scope also allows for better readability: it is clear exactly what some variable “foo” refers to in any given context. Go also has proven suitability for handling scalability through how it manages dependencies and its use on Google’s problems. Readability also contributes to the argument for toolability, Pike argues that tools are easy to write because of it. Therefore, it seems that Go does what it was intended for well. However, since it’s targeted towards issues specific to Google, it doesn’t necessarily apply to others’ issues in quite the same way. Not to say that it isn’t a useful tool for tackling anyone’s scalability problems, but as of this point in time, Go hasn’t been adopted all that widely yet. When one thinks of widely-adopted languages, things like C/C++, Java, and Python come to mind. We feel that Go could eventually become widely-adopted since scalability is a significant concern today.

Go was meant to be a better software engineering language than C++. It trades purist efficiency, for ease of implementation and readability. For example, Go has automatic garbage collection. While this is less efficient than manually allocating and deallocating memory, it cuts down on the amount of code necessary to do something and hence, development time and maintenance cost. Also, since Go enforces strict semantics, no more C golf, it is easily parsed; so much so, that the abstract syntax tree can be traversed and replaced on the fly. This allows easy upgrading of the language, something that usually takes decades in C++.

JavaScript 5

Javascript was written in 10 days, is the most widely used language on for the Web, and has some issues semantically.

E.G.

Defining variables without var declares them in the global scope

Represents ints as 64-bit floats

Correct module exportation is provably unsolvable

Javascript 6

The transition from JS5 to JS6 is an evolution, rather than a rewrite. Old JS code will still be able to run. Some features of JS6 include:

Reverse compatibility with JS5

New syntax for classes that work with existing prototypical inheritance patterns

Native exports syntax

Generators

JS6 can be used now with the transpiler Babel.js to promote adoption