#underdog.io

Post by Taylor Hughes CTO of LaunchKit (Ex-Senior Web Developer at YouTube)

LaunchKit is a suite of tools that makes it easier to build, launch, and manage mobile apps. We take the tedium out of releasing apps and enable cross-functional team collaboration. Our tools help users build screenshots for their app store page, create an app website, track sales and reviews for apps already released, and get info posted into Slack. We are also about to release tools that help teams create native UI for their apps from the web.

Tech Stack

On the server side we are a Python shop, using Django (for a simple REST+JSON API) and Celery for background tasks, over Postgres and Redis. We have several components written in Go. Our web client is a server+client JavaScript app using a framework called Skit (skitjs.com) that we built, which is mostly vanilla JS, with Handlebars for templates.

We use AWS (Ubuntu-flavored EC2, ELBs for SSL termination, RDS for Postgres, S3, Route53, etc.); Papertrail for logs, Pingdom for monitoring. We use Google App Engine for photo hosting/processing.

Helping Teams Deploy Native iOS UI from the Web

The most difficult thing we've done in the past 3 months is build underpinnings for the next phase of LaunchKit. We've publicly launched a set of nice web-based tools, but what we're building next is far more complex: we're working on hosting web-configurable, native client UI for iPhone (and eventually Android) where you can choose and customize various UI flows on the web and easily install and run them in the client.

To make this work, we've built an iOS client-side SDK and runtime, as well as a set of server-side components to compile and deploy native iOS UI. Adding some special sauce to all of this is a dynamic user-focused analytics platform, which collects and analyzes client-side user data to inform these various "hosted UI" flows.

Taken together, it's a sprawling, multifaceted and fascinating project – but it's been challenging putting all the pieces together. We're obviously very excited about the end result, which we hope to launch this fall.

One year ago today, Underdog.io was born.

Back then, it was supposed to be nothing more than a side project. In fact, we were so unsure of Underdog.io that we originally planned to run it anonymously. Chris accidentally purchased the domain under his real name, so that was short-lived.

At this time last year, we were busy checking the logs and watching as candidates and companies applied for access. In a short amount of time, we knew were on to something. That's when we began working on it full time.

This year has been humbling. We've done some things right, and many things not so right. Through it all, we've been touched by the support of the community. We're now working with over 100 awesome startups in NYC.

Better yet, we're helping people find amazing job opportunities. Our goal continues to be to help our candidates discover and manage new job opportunities. To give them a voice. And to make things a little less cumbersome for awesome companies that just want to meet amazing people.

This week on “Inside the Stack,” we hear from Steven Benario, a Product Manager at Ufora. Steven and his team have hired one Underdog.io candidate. Ufora has openings on its engineering team.

Describe Ufora in 2-3 sentences.

The Ufora platform empowers data scientists to analyze any data quickly and easily by automating the engineering. It combines speed and scale with the ease-of-use and flexibility of scripting languages like Python or Matlab, so you can work as easily with 100 gigabytes of data as you can with 100 kilobytes.

What are your primary programming languages?

C++, Python, CoffeeScript, Fora

Ufora is in a unique situation because we built a programming language, Fora, specifically to be the foundation of our software stack. Fora is a dynamically typed, just-in-time compiled, implicitly parallel language. Because we were writing our own JIT compiler, we chose to develop a large part of our infrastructure using C++ so that we could take advantage of LLVM and Clang to rapidly generate machine code.

The vast majority of our web components (both front-end and back-end) is written in CoffeeScript. Python could be considered our “outer shell”, as it’s the glue that holds many of our other components together. Python has a great set of wrappers and libraries that make it easy to directly interact with both AWS and our in-house C++ code.

What are your primary web frameworks?

Angular.js, Backbone.js, Node.js

Historically, we’ve used a combination of Backbone.js and Node.js as our workhorse web frameworks, though we’re currently transitioning from Backbone to Angular.js. We really like the clean separation between logic and presentation that Angular enables.

Node, of course, is a popular choice—it’s flexible, fast, and has a dynamic ecosystem and community.

What are your primary databases?

Redis, S3

We use Redis as our key-value store inside the product. It’s fast, lightweight, flexible, and did we mention fast? For our cloud deployments, we use Amazon S3 as our “big data” store for analytics performed in the platform, as well as for things like backups of user state, log files, etc.

Which DevOps tools do you use?

Chef, Docker, CloudFormation, Pingdom, CloudWatch, TestLooper (proprietary)

Our cloud deployments are built on AWS, so we use a lot of the AWS DevOps tools like CloudFormation and CloudWatch. We also use Pingdom to make sure we’re on top of it in case something goes down.

For all deployments, we recently started using Docker and Chef — we’re big fans of Docker. It’s so easy to spin up docker containers  and try something out that we find ourselves doing it all the time, rather than turning on real “machines” in AWS. We’re also starting to use Docker pretty extensively in our test infrastructure.

The last major tool that we use for DevOps is TestLooper — a homegrown framework we use for for statistically backed testing. Much like other CI tools, it continuously monitors Github for new commits, and automatically assigns machines from our test pool to run hundreds or thousands of hours of tests on each and every commit we make.

TestLooper is particularly useful for tracking down subtle defects — things like race conditions or non-deterministic failures that occur once every 100+ hours of runtime. Once it identifies an increase in the failure rate, it will walk backward in the commit chain until it can statistically identify which commit introduced the failure. Once there’s a high confidence that a commit is “clean”, we stop allocating test machines to that commit.

TestLooper allows us to take advantage of AWS Spot Instances, which gives us access to dozens of machines at a fraction of the normal hourly price. For example, as I write this, we have 80 machines up and running in our test pool, for a total cost of around $8/hr. This infrastructure has been instrumental to our success.

Tell us about an interesting engineering challenge that you’ve overcome.

One way to think about Ufora is as an operating system that joins many small machines into one unified large machine. One of the primary challenges in building this operating system has been managing data and thread locality--in other words, ensuring that each computation instruction and the data it operates on are in the right place at the right time. This piece of infrastructure is called Cumulus.

Cumulus manages memory, computation schedules, cache locality, message passing, etc. It handles all of the tasks that you might take for granted when working on a single machine, and it does it all extremely quickly and completely automatically.

For example, when a user imports a 100GB dataset into Ufora, Cumulus is responsible for determining how to stripe that dataset in memory across all the machines in the cluster. When a user wants to start analyzing that data (using a GBM for example), Cumulus breaks down that computation into smaller chunks and ensures that each compute thread is physically co-located with the data it needs, even as the data is being dynamically distributed and redistributed across the cluster while computations are running.

This isn’t nearly as simple as job scheduling—Cumulus needs to make “smart” decisions about whether it’s cheaper to move data over the network to a specific execution thread, or if it’s easier to pick up a running thread and move it to the data on another machine. It also has the ability to pause and split a thread while it’s running, and move one half around the cluster, and resplit recursively.

For example, in one of our popular demos, we count how many Prime numbers occur in the first 100M integers. On a 60-core cluster, Cumulus splits this operation over 780 times, moving threads across CPU cores to automatically saturate all 60 cores with work.

Cumulus poses some very complex computer science challenges and we focus a lot of development time here because it’s one of the most critical components of our infrastructure. But it’s only one piece! The Ufora stack is quite large relative to other projects, spanning from the language level to our web front-end. And, of course, it’s constantly evolving to incorporate the latest developments in complementary technology and to meet the needs of our customers.

If these are areas you have expertise in, what are you waiting for? Get in touch!

*****

Thanks to Steven and the whole Ufora team for a great post. Visit ufora.com to read more about the company and to see their technology in action. Companies: email [email protected] if you’d like to be featured in this series.

Cumulus Cloud image courtesty of Jeff Kubina.