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
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
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
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