Platform as a service (PaaS) has been around for over a decade. Starting in 2007, with Heroku, and growing since then into dozens of different offerings.
PaaS represented a big shift in the web and application development community because it made public cloud hosting easy and available for almost all developers. The idea of a "one-size-fits-all" infrastructure was very appealing.
Since that time, there has been another big shift in the industry that is moving applications and developers away from PaaS.
Applications are moving away from a monolithic architecture, where a single code base represents the entire application, to a microservice architecture, where each piece of the application is broken out into functional pieces that work together to create the application.
Because of this, application developers are finding they are quickly outgrowing current PaaS providers who cannot support this new architecture.
Developers are turning to Docker to help them containerize and virtualize their applications to support the microservice movement. This has caused a fundamental shift in the way applications are being developed and deployed.
What once was
In a traditional PaaS, you would develop your application locally, isolated away from where it was going to be deployed. Your application and its infrastructure were not connected.
When you went to deploy your application, you could either manually create your infrastructure, or you could use a PaaS like Heroku to do it for you.
Either way, there was an inherent division between your application and it's infrastructure.
Following the Manual
Setting up your own infrastructure meant you could put it wherever you wanted. It could be on your own servers, or out in the cloud on AWS or something similar.
The amount of work to get an application infrastructure up-and-running was (and still is) staggering. Security, networking, updates, redundancy, failover, concurrency, the list is practically endless...
Creating and configuring an infrastructure would take teams days, or sometimes even weeks. They would then have to monitor and manage the resulting infrastructure basically all day, every day, forever.
Trying to escape or improve on this process is what planted the idea for PaaS in the first place. Platform as a Service removes the need for infrastructure teams, often called DevOps.
Application developers are able to develop their applications and then deploy them on their own, avoiding any middlemen, or the need to have prior experience with infrastructures.
All this power and convenience does come at a cost though.
When your application is hosted with a PaaS, it's put on a shared host. This means your application is stuck on servers with a bunch of other applications, all sharing the same resources.
There are also two very large trade-offs when using a PaaS—flexibility, and control.
Flexibility is lost because you're stuck on your PaaS provider's underlying host. This could be their own servers, or they could be built on top of something else like Heroku is built on AWS.
This is referred to as "vendor lock-in". If you ever needed to change hosts you would have to migrate your entire application somewhere else.
Control is lost in two ways. On a PaaS provider, you generally don't own the servers your application is hosted on. Instead, your PaaS purchases the servers from their host and lets your application use them. It's like their service is a giant swimming pool, and they throw your application in with everyone else.
The second way you lose control is you're only allowed as much access as your PaaS allows. In some instances, you may not even be able to SSH into your own application.
The Great Divide
Regardless of the method you choose to deploy your application to production, there is still a huge disconnect.
Applications and their infrastructures are still separate. The all too familiar "why does it work locally but not in production" prevails.
Also, since applications are developed locally on individual developer machines, there is no consistency between these development environments. Entire teams can be working on the same application in entirely different environments, to disastrous effect.
I don't know how many times I've heard (or said) the words "I don't know, it works for me", but the truth is, I know exactly why. We're using the same code base, but our environments are completely different.
This problem even extends to new developers joining a team, and the team needing to spend a day (if you're lucky) getting that person integrated.
All of this has culminated into the evolution of PaaS...
μPaaS represents a shift in the way applications are developed and deployed. Rather than an application being developed in isolation from its infrastructure, an application is developed inside its infrastructure.
Wherever your application goes, your infrastructure goes too. Or better put, wherever your code base goes, your infrastructure follows.
Nanobox leverages Docker to create isolated, consistent, development environments that can easily be shared or distributed, with the guarantee they will work the same for everyone.
This guarantee extends to production as well. It doesn't matter where you put your application since your infrastructure goes with it, you can deploy to AWS, Digital Ocean, on-prem, whatever.
Your application will run the same anywhere and everywhere.
The Ideal Platform for Developers
With the introduction of μPaaS, Nanobox allows developers to focus completely on their applications. No time wasted dealing with the complexities of creating, configuring, and managing infrastructure.
Nanobox brings DevOps into the hands of everyone, making application deployment and hosting easier, and more accessible than ever before.
Bringing application development and infrastructure together also makes applications more stable. Once you have your application running locally, you can test it right there, in a production setting, and feel confident your deploy to production will be flawless.
Whats in the box
Nanobox is the first and only tool that spans the entire development to production workflow.
In addition to the local development workflow, Nanobox offers a production management tool that makes scaling and monitoring your application easy.
You can connect your Nanobox account with any host you choose, create as many applications as you like, and deploy your code to any or all of them.
Using the dashboard it's very easy to monitor your application health, scale, view logs, and a wide variety of other features that makes managing a production application painless.
Also, since you own the infrastructure your application is running on, you're given the ability to SSH into the containers and servers right from the command line, or from your host's dashboard.
Nanobox strikes the perfect balance between flexibility and control. Giving you as much control and flexibility as you need, when you need it, but doing all the work for you when you don't.