What is this Platform-as-a-Service (PaaS) future exactly? How do NoOps and DevOps fit into this whole equation?
PaaS is about making developers lives easier.
PaaS is really a combination of things, focused around faster deployment times, lower barriers to entry, higher scalability, high availability, geographically dispersed systems, and more.
So how do you get your PaaS ready to go? First there are a few key concepts to understand, so we'll dive into those first.
In this article we're going to dive into NoOps, DevOps, and how they relate to PaaS. Then with a short context description of what led to this technology we'll take a look at the premier open source solution Cloud Foundry. We'll take a dive into what makes it tick, the architecture, and a simple deployment of an application. Along the way we'll also step into the core concepts behind Platform as a Service.
NoOps and DevOps
A quick definition of each, to get us started.
- NoOps - No operational needs for developers except to deploy a PaaS enabled application, usually considered a SaaS App. This is a prime demand of small businesses, start ups, and mid-large enterprises that have independent development and product teams that need the ability to prototype or get apps deployed quickly without worrying about the infrastructure or other concerns of the system.
- DevOps - The combination of Developer and Operations, rolled into a single occupational characteristic that combines these needs. DevOps often maintain the network, infrastructure, and platform as well as the actual code base and deployment of the application. DevOps is a rare and distinctively intense and wide breadth characteristic.
Before NoOps was an option for developers, DevOps tried to solve the problem by giving developers a development interface for doing operations. The premise behind NoOps is that developers can finally get their work done without having to worry about ops at all. It is not about the death of operations. Let ops guys behind the scenes fine tune everything and keep it running. That's what they are good at and they won't go away. Let's just make sure that developers need to do "no ops" in order to get their work done.
Developers are not working with networking, because they don't need to; they're not working through routing issues, instances staying live, crashing, or where things are put - because they don't need to. Their responsibility and effort is focused solely around their applications and their business value.
Where Did This Come From? Traditional Development
Traditional development often included many tedious tasks centered around allocation of machines, resource assignment for the machines, specification of machines, clarification and excess communication related to all these things, some guessing about what the future holds and allocation of financial capital to buy the machines. Then came the setup, configuration, then resource placement of the machines in a data center, co-location facility, or in some cases a closet inside the company's building. These approaches were, at best, challenging and at worst, were done by trial and error. PaaS and the future of NoOps, and even to an extent DevOps, does away with this traditional software development nightmare.
All these traditional environment issues have cost the development industry billions of dollars over the years. However, a revolution is brewing and already disrupting the way in which software development is done. This move is as huge as the move from assembly to C/C++ or C/C++ to higher level abstract languages like Java, C#, or Ruby. The move to PaaS, and the corresponding removal of the operating system barrier, enables vast improvements in the way software is developed.
The Core Principles of PaaS
One core principle of PaaS is simple app life cycle management. Start, stop, deploy applications.
Let's take a look at a traditional deployment process compared to a PaaS deployed solution. First we'll dive into the traditional deployment.
- Get a machine or instance to run the application on.
- Load the operating system.
- Setup the networking and prepare it for inclusion into the environment where it will be placed.
- Setup the hosting web server or services files and folders in preparation for deployment.
- Build/Setup the application autonomously from the system itself, preferably on a dev machine.
- Verify that the deployment of the configuration can be moved from one environment to the next.
- Push the code base and application dependencies into source control.
- In some way, get the application from source control to the server that was previously created: move, x-copy, use an msi installer, bash script, or deploy.
Ouch, that's 8 steps. Some of them extremely time consuming and painful. Let's take a look at what we'd have to do to get the same exact application deployed to a PaaS Solution (we'll use AppFog in this case).
- Tell the PaaS the domain name you want.
- Push the code base and application dependencies into source control. Github is always a good place to work from.
- Push your code live (see picture) by clicking Create or using a simple command line tool: af push
Your code base will then automatically be pushed up to the PaaS provider, automatically built and deployed onto the fabric of the system.
That's it. Three steps. Simple.
(Click on the image to enlarge it)
This screenshot provides a great example of everything you need to get started via the UI or via the command line. This is a sneak peak of AppFog's PaaS that utilizes Cloud Foundry at the core.
Architectural Elements - Client Layer and Plugins
The client layer and plugins provide UI and command line capabilities that enable simple ways to deploy applications onto the PaaS. The client command line is just a few steps. For instance:
sudo gem install vmc vmc target api.cloudfoundry.com
As an example create a node.js application at this point, add an app.js file with the following code:
var vmc_port = (process.env.VMC_APP_PORT || 3000);
var vmc_host = (process.env.VCAP_APP_HOST || 'localhost');
var vmc_http = require('http');http.createServer(function (req, res) {
res.writeHead(200, {'Content-Type': 'text/plain'});
res.end('Foo, I'm Alive!!\n');
}).listen(port, host);
In the directory with that file then just end the command:
vmc push
You'll get some feedback, with some questions that you can just just hit enter on. The defaults are good for an initial deploy. The one I did differently, just to show some simple binding of applications to services, is selecting 1 for a mongodb service.
Would you like to deploy from the current directory? [Yn]: Y Application Name: some_app_name Application Deployed URL: 'you_test_subdomain.cloudfoundry.com'? Detected a Node.js Application, is this correct? [Yn]: Y Memory Reservation [Default:64M] (64M, 128M, 256M, 512M, 1G or 2G) Creating Application: OK Would you like to bind any services to 'gvp_node_test'? [yN]: y The following system services are available::Please select one you wish to provision: 1 Specify the name of the service [mongodb-55666]: Creating Service: OK Binding Service: OK Uploading Application: Checking for available resources: OK Packing application: OK Uploading (0K): OK Push Status: OK Staging Application: OK Starting Application: OK
- mongodb
- mysql
- redis
Even though we don't have an actual database setup, I did this to show how easy it is to setup a service. At this point though, we do have a running application, so hit it with curl to verify it is running.
curl your_app_name.cloudfoundry.com
With that you will get a response of "Foo, I'm alive!!". That's it, you're application is deployed. A total of installation, target, and push! Again, three steps!
Let's take a look at a few other things we can do with this application and the Cloud Foundry Environment at this point.
Updating an Application Without Causing an Application Restart
Some of the things you'll need to do on a regular basis are updating, restarting and pushing applications. Some of those things include:
Push an application
vmc push blaghApp-v1 --url blaghApp-v1.cloudfoundry.com
Check out the instances with
vmc instances blaghApp-v1 1
Also unmap the application instance
vmc unmap blaghApp-v1 blaghApp-v1.cloudfoundry.com
To rollback try a combination of these commands
vmc map blaghApp-v1 blaghApp-v1.cloudfoundry.com vmc unmap blaghApp-v1 blaghApp-v1.cloudfoundry.com
and stop that same application that is mapped
vmc stop blaghApp-v1
There are many other commands and options. Be sure to check out at http://cloudfoundry.org.
More Material on Frameworks and Services
With PaaS, one of the key features is to support a framework or many frameworks. Here's some of the key options that are available with Cloud Foundry and Iron Foundry combined.
Node.js
- GettingStartedwithVMwareCloudFoundry, MongoDB, andNode.js
- Node.jsandCloudFoundry
- CloudFoundryintrotoNode.js
Sinatra + Rails
- SettingupRakeforSinatraw/ CloudFoundry
- AddingRSpecw/ CloudFoundry & CloudFoundry
- Sinatra, CloudFoundry, andTheDirtyDetails
PHP
Java
ASP.NET
Using a service, like AppFog we have the ability to abstract the PaaS even further and provide a vastly streamlined interface and command line. Even though AppFog will provide all of the Cloud Foundry functionality, the AppFog PaaS will extend the Cloud Foundry abilities further with additional functionality.
How does this work?
At this point I've covered the basics, summarized what PaaS really provides to a company that is ready to step up to the plate. Now we're going to take a deep dive into what makes this a great leap forward.
PaaS Internals
In a platform as a service offering there are a lot of things that go on underneath, which often make it a rather complex system. There is self healing that needs to occur, instances of servers and other things that must spool up or terminate. All of these things need automated with as small a human touch as possible.
Here's a simple diagram of the Cloud Foundry & Iron Foundry PaaS Software that is being used by AppFog, Stackato, and others to provide platform services.
(Click on the image to enlarge it)
Architectural Elements - The Cloud Foundry Core System Architecture
The core of the Cloud Foundry system, including the additions available with Iron Foundry, are centered around the controller. Commonly we refer to this as the "concept of the controller" so as not to mix it up with the other dozen patterns that use similar terminology. This controller is self healing and and can be used in multiples through out a platform architecture.
Around the controller exists a number of controller assisting technologies such as Resque and Stager. There is a pub/sub functionality that is provided by the NATS that acts as the glue between these components and gives it a resiliency that is needed in systems like this.
Architectural Elements - Droplet Execution Engines
The Droplet Execution Engines, or DEAs, is a program that simply deploys and starts code on a server like Apache or thin. Their job is to execute the end-user code.
DEAs are part of the overall architecture responsible for running across the platform. This may include Node.js, Java, or in the case of the Iron Foundry DEA extended out for .NET. DEAs can be numerous and of various configurations, which is perfect to allocated certain instance sizes based on their intended usage.
Architectural Elements - Router and Health Manager
The router works as an event daemon in the system with the responsibility to listen for new apps coming active. On the other end of the spectrum the health manager is there to identify any issues that may arise and issue the controller or other mechanism to resolve those issues.
Architectural Elements - Services
Services are one of the greatest extension points in Cloud Foundry. In this realm there have been dozens of additions such as MySQL, Redis, SQL Server, and more.
Architectural Elements - The Future
Even though Cloud Foundry is well thought out, there are many last mile features that still need put into place. An example would be something like auditing, authentication and orchestration, which is still needed for many enterprise use cases. With the great support behind Cloud Foundry there is little doubt there will be many new features and capabilities in the near future.
For a great deep dive into the architecture check out Derek Collison's Presentation "CloudFoundry - InsidetheMachine".
DevOps, Enter NoOps
From the architectural designs you can see that there is still a large need for PaaS Providers to
have strong DevOps Support. However with the consolidation of this it draws DevOps to a more honed and centralized value within a PaaS Provider. But outside and within small business, mid-sized, or any PaaS user it can provide a situation to enable the DevOps Role to be moved to a provider, enabling core competencies of the business to focus around the applications and needs they have instead. With that shift, enters NoOps for more business focus, clean application development, shorter cycles, and the always elusive increased business agility.
Are you ready for NoOps? Let us know your thoughts at @adron and @appfog
About the Authors
Lucas Carlson is the CEO of AppFog, which he founded in September 2010. Before AppFog, Lucas led the development of MOG, a web 2.0, music-based, popular social networking application, from the ground up with Ruby on Rails and MySQL. At MOG, he wrote the majority of the code base, created an architecture that could scale as the community grew, and hired, led and cultivated a technical team. MOG.com is currently one of the five most popular Ruby on Rails sites on the web. He has authored over a dozen Ruby libraries, including the Ruby Cookbook, and contributed to various others including Rails and RedCloth. Lucas participates in industry groups and speaking engagements on a regular basis around the country.
Adron Hall is a software architect and programmer who has worked with cloud computing services since 2007 using big data and everything from business intelligence to the nitty gritty of array structures inside file based data stores to create caching tiers for custom software needs. Currently, Adron is advocating for cloud technologies, better data centers, the best software development practices and keeping everything secure in the financial industry.
/filters:no_upscale()/articles/paas-arrived-cloudfoundry/en/resources/fig1.jpg){kind=link}
/filters:no_upscale()/articles/paas-arrived-cloudfoundry/en/resources/fig2.jpg){kind=link}