Docker has made containerization more accessible than ever before, which is changing the way we develop applications. Rather than a single code base that represents the entirety of an application’s functionality, apps are broken up into smaller functional pieces called microservices that all work together to form the application. App developers, however, are finding it difficult to host these applications online because they are quickly outgrowing the “one-size-fits-all” nature of Platform as a Service (PaaS). What is PaaS anyway? PaaS exists as a way to allow app developers to deploy and manage web applications without having to deal with the complexities of creating, configuring, and managing servers. In other words, developers can focus on writing their applications and then quickly and easily deploy them to production, without having to wait hours (or even days) while someone else provisions and configures their infrastructure. P is for Platform Platform — a standard for the hardware of a computer system, determining what kinds of software it can run. The P in PaaS stands for Platform. A platform encompasses everything your app needs to run — your application code, dependencies, web server, proxy, etc. In “traditional” PaaS all of these things are in a global space, one giant monolithic shared platform. Before you deploy your code, you need to ensure there’s an infrastructure somewhere that has everything prepared to run your app. When most people think of PaaS they imagine a well-designed UI that provides a nice layer of abstraction on top of an underlying host (like AWS, Google, or DigitalOcean) and takes care of ordering, configuring, and managing servers for them. Something like… Heroku. PaaS as we know it Heroku was originally created in 2007. In January of 2009, Heroku launched a new version of its platform that had been completely redone from the ground up. (warning: opinions ahead) Just after that, in March of 2009, Ruby on Rails 2.3 was released. Rails was already gaining popularity, and with 2.3 it suddenly became a very popular choice for web development. Life before Rails was a little bit like the wild west. You were either using Java on the front end because that’s what your backend was, or you were using PHP. PHP wasn’t really known for its conventions… there was that saying, “there are as many PHP frameworks as there are developers” (similar to the JavaScript scene today… but I digress). With Node.js in its infancy, Rails looked like a very promising alternative to the way web development was being done, especially with the promise of “convention over configuration”. As it turns out, it was just what many developers were looking for. It was then that Heroku positioned itself as the de facto host for Rails applications and PaaS as we know it began to take off. Source Google Trends (back to the facts) Over the next few years, Heroku would announce support for various other languages, making PaaS available to more than just Rails. Since that time PaaS has exploded, to the point that there are now of different providers to choose from. dozens The Price of PaaS The trade-off for not having to configure servers and manage infrastructures comes at the cost of and . flexibility control — When you select a PaaS provider, you’re stuck on their, single, underlying host. For example, Heroku uses AWS under the hood. As your application grows, if you need to expand into new regions you’re ultimately limited to whatever Amazon has to offer. Flexibility Also, since you’re not ordering your servers directly from the host, you’re limited to what plans your PaaS provider offers. This has the potential to severely limit the sizes and configurations of servers you have access to. — Another major limitation of PaaS is direct control over “your” servers. With most PaaS providers you don’t have SSH access to the servers, and if you do, it’s limited access, so you won’t be able to install packages or services. Control Also, since the servers are ordered through the PaaS provider and not directly from the host, you can only manage them through the provider’s dashboard. This usually limits the amount of direct interaction you have with the servers themselves (restarting, rebooting, etc.). The Future of App Development Application development has seen a huge shift towards microservice architecture and containerization, specifically with Docker. Source Google Trends Containers have actually been around for quite some time. Starting with way back in 1979. From there came several iterations including FreeBSD Jail, Open VZ, LXC, and LMCTFY. chroot Finally, Docker was introduced in early 2013. What really set Docker apart was that it didn’t only offer containerization, but an entire ecosystem for creating, using, and managing containers. What before was a fairly obscure process, was now quite accessible. Containers themselves are like little, isolated, mini-servers running inside of a host machine. They have their own resources drawn from the host and wrap all their processes in their own filesystem. They are very lightweight and are easy to create, scale, and destroy. Containers are perfectly suited to house a single piece of functionality, and so it was largely due to containers that the microservice architecture became popular. Decoupling each part of the application offers stability and flexibility. An application no longer consists of one giant code base. However, as an applications microservices grow it needs a matched level of flexibility from a hosting solution, which PaaS is unable to provide. The future of PaaS The next iteration of PaaS will be -PaaS (μPaaS), which makes complete sense if you think about it. micro The P in PaaS isn’t going away, and it never will. However, microservice applications need a platform that is as flexible and dynamic as they are, and so PaaS is evolving to fill that need. μ is for micro In μPaaS, each piece of an application is its own container. This creates a unique ecosystem of microservices that are all deployed along with your app into any environment. Wherever your code goes, your infrastructure follows. Gone are the days of “I don’t know it works for me…”. Imagine a local environment that can be distributed freely through a development team with the guarantee that it will work the same for everyone, even the new hire… really cool! micro-PaaS in production μPaaS allows developers to easily create instant, isolated, development environments, then just as easily deploy that same environment to production. This dev to production parity is actually a really big deal Also, because of the distributable nature of these environments, there is no longer a need to be tied down to any one particular host. Applications don’t need a “full stack” or “single host” PaaS offerings, they need an underlying host that is as dynamic as they are. One step forward, two steps back There is one large caveat, however… Much like PaaS needed something like Heroku to truly reach its full potential, μPaaS needs something that can abstract away all the complexities of managing Docker and containers. While containerization is really awesome, it brings development back to where it was before PaaS. Now, however, instead of configuring and managing servers, developers are configuring and managing containers servers. within Instead of being responsible for just an infrastructure of servers, you’re now responsible for an infrastructure of containers an infrastructure of servers… infrastructureception! inside of Container Orchestration Because of the need to wrangle all these containers and make them manageable, things like Kubernetes (K8s) and Docker Swarm were created. While these are great tools that solve a real problem, they come with their own learning curves and non-trivial complexities, which can make using them daunting. Just like PaaS abstracts away infrastructure configuration and management, μPaaS will need something to abstract away all the container configuration, orchestration, and management. Start using micro-PaaS right now is a good example of a μPaaS available for use right now. Nanobox It takes into consideration everything developers will need from a μPaaS, making it easy to maintain environment parity between members of a team and throughout all stages of development. It deals with all the complexities of configuring and managing containers servers so app developers don’t have to. and The ease of which modern applications can be created, as well as the flexibility and control offered by μPaaS to deploy and manage these apps, represents a very significant leap towards the future of application development, and the future of PaaS.
