As technologists, we are dedicated to optimization. As such, we outsource tasks to cloud services who handle them more efficiently. We use Github for repository hosting, Heroku for web application deployment & hosting, Travis for CI, SendGrid to send application email, and Firebase for realtime apis.
Within the web application ecosystem, code hosting and code deployment have been optimized considerably over the past few years. What used to take days of ops work on Linode or Slicehost now takes seconds with Heroku. Managing a remote git repository (or, svn back in those days) took some time to setup and wasn’t nearly as efficient for teams.
- Application hosting
- Code hosting
- Project runtime
But what about our project runtime? While it’s true that your customers don’t see your runtime, it is a crucial component because it is the foundation of your application. Twitter famously had some major issues early on during their rapid growth that might have killed their meteoric rise. They eventually switched from Ruby & Rails to Java and the JVM. The transition wasn’t seamless and wasn’t a trival task by any means.
Today, the world isn’t much better off when it comes to development environments and managing your project’s runtime. Managing development environments remains a major cause of frustration and wasted time for many developers and development teams.
Typical development environments suffer from a number of architectural issues that hinder productivity: Development environments are not easily replicated and shared across machines; they are not versioned; nor are they kept in sync with their production counterparts. This results in the following common problems:
Keeping two development machines up to date on the same project can be a significant burden. We’ve all tried to keep our work and home computers in sync, but waste countless hours doing so.
Pushing applications to production servers that run different versions of the stack can increase the occurrence of runtime errors in production. (Otherwise known as “Dev/prod parity”).
On-boarding new employees is unpredictable and time-consuming. Even when using Chef or bash scripts to handle many of the mundane tasks, somebody on the team needs to maintain these scripts and troubleshoot them when they’re not working correctly.
Keeping dev environments in sync across team members is challenging. Designers and other non-core engineers who need access to the full-stack should almost never spend time setting up and managing their development environment.
While there are a few other teams tackling a similar problem, we differ from them in our approach to coding on the cloud. Action.IO doesn’t try to reinvent anything or force you to change your workflow. Instead, we let you use the tools that already exist on your system more effectively. There’s a ton of secret sauce baked into the system, and I’ll post some updates to this blog as we roll them out to the public.
For now, if you want a glimse of the future of development, sign up for our private beta.