ykumar6

Founder here, happy to answer any questions

I think the interesting opportunity here is can bring this real-time workflow to professional software teams that use git and micro-services?

The blog post talks about how the api server was dropping web hooks, and there is no re-try mechanism built into most web hook senders.

Scaling out an api server is not resilient enough, and there needs to be a queue-based system fronting your web hooks so they aren't dropped

This is pretty cool, how does this integrate with the UX?

Travis CI and Circle CI push code to a staging or production environment. So you still need to setup a full-stack environment to do end-to-end testing.

Runnable let's you have end-to-end (full-stack) environments with every branch. The minute a branch comes up, you have an environment. This includes a clone of your database

Founder here - We absolutely can! Just give us a heads up so we can make sure it loads up properly on your account

The reason it's built for Github organizations is we can access-control your private infrastructure based on the permissions set in Github.

We don't have access to the same APIs with just a personal accout

It's on our roadmap. Can you submit a support ticket and I can fill you in over email

Founder here. Check us out for your future jobs. Maintaining sandbox infrastructure is a pain.

One of our key lessons is being able to dispose and rebuild your infrastructure on a daily or weekly basis so leaks don't destroy your environment.

We recycle customer environments in Runnable, on a regular basis and its completely transparent to users

We're trying to hire developers to help us do that :-)

Hey appleton - Here are some differences

1) You don't have to re-configure your environment variables and 3rd party APIs for each branch on Runnable. Every branch runs in the same sandboxed environment with the same env variables and 3rd party services. With the help of an HTTP proxy and a dynamic DNS server, we can route traffic to the right set of containers for the branch you want to test.

2) Runnable is built on Docker, which means all your configuration files and the way your containers are run is non-proprietary

3) You can connect arbitrary branches with each other for testing. So if you have a feature branch on a web server, and a feature branch on an api server - both can be connected easily through our web interface. This allows for cross-branch testing. Underneath the hood, we swap the IP address to connect the right containers together.

4) Our environments spin up much quicker than Heroku's. We build and run on the same machines so there are no network transfers and we can utilize build cache better.

5) Databases clone instantaneously with Runable, versus waiting minutes (depending on size). This because our build system applies Copy-on-Write to database containers

6) You can run end-to-end integration tests as your code is being pushed to a branch. Heroku only creates an environment when you're done coding and a pull request is open

Yes, every branch can get a clone of your gigabyte database. This works by applying Copy-on-Write to the containers running your stateful containers.

So it becomes very easy to test schema changes and migrations with this approach

CircleCI doesn't host your containers. They just build and test them. Runnable runs actual environments for your branches

Hey All - Founder here. Happy to answer any questions or discuss some of the problems we've solved building on Docker.

Think of your career as being a generalist, but learn things like a specialist.

You want the opportunity to work on a wide array of problems so you build a repertoire of solutions and insights that can be applied to various problems.

Being a full-stack engineer is a great place to start, but it's limiting because you never gain enough depth beyond plugging together front-end, back-end and off-the-shelf components.

Instead, you want to rotate between various roles so you can focus on different areas. This way you can understand the pitfalls and best practices of certain systems (like infrastructure, queues, machine learning, angular, etc).

Amazon Elastic Container Service is a robust offering and I can't see why anyone would choose Tutum over ECS.

Yes, you can run Tutum on AWS, but why? When products can't substantially differentiate themselves against AWS, the customer will choose AWS. Customers don't want to be stuck in choice paradox.

Yes, I 100% understand that point. But I repeat what I'm saying, this isn't a concern for most developers and most software companies. They don't care how a page table is written. They don't care about optimizing that.

Every standard or abstraction can be unbundled into multiple standards or abstractions. But at the end of the day, what wins is something that's simplest to the operator

Yes, but do software companies really care about "giving direct, (but mediated), control to the programs".

What is the trade-off between that, and the added complexity in understanding all the different ways you can program something?

IMO, developers want a simple and standardized model to build applications on operating systems so they don't have to care about the internals.

This article represents a marginalized view by the larger industry as a whole.

The real problem with abstractions it promotes the lowest common denominator. If you have lots of different storage options, an abstraction will try to abstract them and create a standardized interface.

But this is a trade-off. The real benefit comes in simplifying the programming model and not forcing developers to read through manuals figuring out how to flip a bit on a hard drive. Instead, they can leverage open-source and libraries that rely on that standardization to deliver most of the value (with a small perf hit)

" Unfortunately, years of CS education seem to have taught most people that it's the other way around, causing massive increases in design complexity that are only justified by dogmatic adherence to "more abstraction is better"."

Abstractions only create design complexity when they are applied incorrectly. Abstractions should scale horizontally across a layer of the software stack (VMs, Storage - NFS, APIs, etc). If you're create a single-use abstraction, it's not really an abstraction but a complexity

The question remains if companies and developers value or care about the flexibility of creating "page table rules".

For highly scalable systems, the perf trade-off is just a matter of spinning up more VMs.

The higher-order benefit is you can expect your operating system and VM to behave the same, no matter what

They are making 2 separate arguments then. What they are arguing against is standardization, which is just as important

Abstractions are important as they reduce complexity, and simplify operations.

The foundation of computing is based off abstraction - using layers and interfaces to hide complexity, so developers can focus on higher-order problems.

This article argues against abstractions citing security, performance and cost. But time and again it has been shown that most costly component in software is human time - and simplifying the underlying architecture is worth the trade-offs

The exception may be for companies that have clearly recognized network effects.

In this case, your product may not be valuable without a lot of users, customers or cars .. You need to spend to get to critical mass, but I'm sure it's important to articulate a plan on why your business becomes profitable from that point onwards.

Too often, there isn't a tipping point or that tipping point is very hard to reach and companies never become profitable

I look at AI as a continuum or evolution of software to do more for humans.

Today, if you make a phone call and a computer operator picks up, the experience is not as nice as it could be. In 50 years, it may become indistinguishable from talking with a human.

Similarly, a google search may become more intelligent. Facebook is already going this way with Project M.

Calling a cab via uber may result in a software-driven car picking us up. There is no evidence this kind of intelligence will threaten humans. It's just a tool.

Humans are in the business of solving problems, AI helps us solve problems. Killing us is not solving a problem

Installed 30 minutes ago, entire team hooked

Just a quick note on Gmail. It's not just a mail server, it also filters and classifies emails better than any other product on the market.

No other company has that kind of volume of data and heuristics

I am very interested to know what are the specific capabilities that you are able to unlock that Google drive can't deliver upon.

The power of Docker is enabling companies to move faster. Docker lets developers and companies to continuously deploy with fewer bottlenecks and issues.

Yes, I realize it can be used for other things. I'm not sure if there is value in those things.

I don't know, but the solution is education. There more educated the consumer is, the less a company like google or facebook can get away with.

Clearly, there is not enough education about privacy and how your data is being used to extract money from your pockets.

But when it comes to agility, yes, it's more about improving upon (or finding) the value proposition of that product.

If uber could cut down the time it takes to find a car from 5 minutes to 1 minute, wouldn't that be better for everyone?

How does a company on Sandstorm compete with a modern SaaS company that can change an algo behind-the-scenes and instantly improve experience?