Selecting a DevOps or PaaS Platform

is the term to describe automation of the process of moving software products from development to production.

This is a key part of creating software agility in an organization and essential to compete in the new enterprise.

There are many ways and products to help you achieve DevOps automation and efficiency.   The term PaaS is somewhat synonymous although there are some who try to relegate DevOps to a lower level and define it as simply tools that automate some aspect of deployment whereas I look at DevOps as a term for describing anything that automates aspects of this process going up to complete automation.  I would find it hard to figure out where to draw the line between the two.  However, both

Nati’s Blog and Keene’s Blog attempt to distinguish the two.

Going forward I see 3 paths:

1) You can roll your own using tools such as Jenkins, Maven, Chef, Puppet and many many others. (what nati and keene call devops)

2) You can buy off the shelf products that complete the process end to end such as WSO2 Private PaaS

3) You can use some combination

I am going to talk about generally the steps and problems and tradeoffs associated with this in real enterprises and questions you should ask in deciding what you need out of a DevOps PasS platform.

If you are under pressure to deliver software in any enterprise today that will be delivered to the web or via mobile applications you must consider devOps tooling and automation.   There is hardly a choice because the advantages of being able to forego the error prone, lengthy, expensive processes that were done for decades are simply too great.  In the past, as much as 2/3rds of a project could be eaten up in this process of what we call DevOps.  The effort involved in acquiring the hardware, planning the infrastructure changes, the networking changes, the fault tolerance processes, the administration, support, upgrading and all the other aspects of delivering software were expensive and lengthy and required lots of SMEs who understood the networking, the security, the hardware, load balancing and scaling issues.  Sometimes special adapters and adjustments had to be made to key hardware and software components to facilitate the new application.  The process was manual and error prone and had to be checked and double checked.  If an error was made it could increase costs dramatically or bring your whole network down.   DevOps automation and PaaS has transformed the way applications are delivered and reduced many of the bottlenecks associated with this part of application development and deployment.

If you are a business person then if all this is avoidable why would you ever consider using a manual old fashioned DevOps process and roll your own deployment for applications?  Well, for many companies retooling existing applications to be DevOps compatible is too expensive.  That’s the only reason I can see or if your application has such specific characteristics of hardware required or deployment that it has to be done manually then I guess you are stuck with that.  However, almost everyone should be considering using DevOps PaaS as a default.

IaaS Independence Layer a must have

IaaS is the first step in DevOps PaaS deployment and here you need to consider are you going to run your application in the cloud on a commercial vendor or on your own infrastructure?  I really don’t want to address that here.  There are enough other resources on this.  What you need to be aware of is that there are technologies that allow you to be flexible in terms of selecting IaaS solutions and give you independence from the IaaS layer.   (JCLOUDS being the one I prefer at this time) This should be essential to any enterprise strategy as the choices and decisions about the deployment infrastructure can change over time.    So, the first thing is to consider an IaaS independence layer should be in your selection giving you a wide choice of IaaS vendor technologies.    There are several.  Then you need to actually select a “host it yourself” solution or choose a specialty private vendor or a public general purpose vendor.  The factors in these decisions are outside the scope of this blog.   Included in this layer you need to also consider which virtualization technology you will use.  Also outside the scope of this blog.

HYBRID Capability probably a requirement

Next you must choose if you are going to deploy in a hybrid manner.  This could mean deploying in your on site hosting environment and an external vendor.   The advantages of this are that regulatory and compliance requirements may require you to consider multiple vendors and locations, the cost of hardware can vary considerably and the speed to acquire new hardware varies.  Your internal infrastructure may be hard to scale quickly.

So, having a hybrid approach so that you can burst when demand goes up to an outside vendor automatically means you need a solution that can handle hybrid deployment and all the management issues that arise from that.  If you have a hybrid environment it complicates delivery of the application, synchronization of upgrades, networking configuration, latencies of the application but the benefits are potentially huge if you expect high variability in demand where you have specific situations which arise only periodically that require you to scale some part or all of your application.  For instance, should you build capacity for peak demand for the few hours a day yourself in your own facilities or use an external source for resources during those peak hours?   If you expect at certain times of the year demand will have spikes why pay for hardware for all the year for a christmas rush?  If you need hybrid capability there are very few PaaS / DevOps environments that support this well.  Otherwise you will be faced with many manual steps that defeat the whole point of DevOps and PaaS.  For many reasons a hybrid deployment capability is a big plus.

Polyglot is a must

Next you have to consider the type of application you are building and development environment.   Many DevOps infrastructures don’t support more than one development infrastructure type.  For instance Microsoft software is quite different from Java development and many DevOps PaaS will support it or not.  You should consider what are called polyglot DevOps or PaaS solutions so you don’t have to be tied to any particular framework for development as well as giving you flexibility in the future.   While the DevOps infrastructure doesn’t have to have every conceivable framework you use or may use it should be extensible to support new frameworks.  So, look for polyglot PaaS or DevOps.

Enterprise Grade

Next you have to consider “enterprise grade” concerns.  These are kind of soft issues but are critical when it comes to the real world issues of deployment.

Does the DevOps PaaS environment support having separate deployment environments for development, test and production or more?  Can it support multiple versions in test or production?   Some prominent DevOps PaaS do not support this and end up forcing you to test in your production hardware.  Something most mission critical companies would consider ridiculous but if you are making rinky dink game applications may not seem like such a big deal.

Does it support resource sharing well so that you get maximum benefit from the resources you use?  In order to maximally share resources all aspects of your infrastructure have to be multi-tenant.   Frequently DevOps / PaaS technologies don’t include a robust set of tools for development or use environments not designed for multi-tenancy.  The result is that many things run in a separate JVM per tenant which makes SaaS pretty expensive.   Will your shared applications, data resources be shared between all Applications and between all tenants or will there be separate instances that cost more hardware to implement?   Having an Enterprise Platform that is all multi-tenant enables maximum sharing of those resources.  A big plus.

Does the system have robust fault tolerance?   Do all aspects of the system have a design built for HA?  Is the platform built optimistically to run all the time or designed to assume failures and built for resilience to failure?

Does it support powerful security capabilities like federated security?  Frequently when you have multiple applications running in your PaaS / DevOps environment they will need more complicated authentication including users who represent whole organizations, two factor authentication or single sign on requirements.  You need an Identity capability in the platform or in your system that is integrated well into the DevOps / PaaS infrastructure because the DevOps / PaaS infrastructure is responsible for the first line of defense and load balancing it may need to know who is coming in and how to authenticate them.

Will the system allow you to specify templates for applications so that you can tell it how to deploy and scale your applications automatically?  When applications are deployed by the automatic deployment mechanism in your DevOps / PaaS you want to have an ability to tell it exceptions and how things work together so that it can make the right decisions about how to scale and when spinning up a new instance how to do that correctly for whatever application you are deploying.  You DevOps / PaaS infrastructure needs to have a template mechanism.  It can’t assume it knows how to deploy things based on simple predefined fixed rules.

Can you get administrative CLI access to all components?  Do all components have a CLI interface and uniform administrative API so you can build your own control consoles and administration?  As you deploy applications you will want to API centric approach to every component so you can build your own visual controls and operations tools.

Can you manage upgrades of any component of the devOps platform with no downtime or very little?   OSGi is a powerful tool that among other things supports different versions of the same library or component at the same time.  It also allows you to stop and start components, upgrade them and continue without bringing your whole application down.  This allows you to have zero or very short downtime.  In many applications this is highly desirable and allows you to post very high SLA’s.

Can you assign tenants to specific instances or versions and specify rules for how to pick the locations of resources like databases and compute?   Based on compliance regulations of different countries sometimes you have to pick different locations for data or compute.  Can your rules engine for your DevOps / PaaS handle customers anywhere in the world?  Can you offer service to some customers where they get dedicated hardware?  Do you want to roll out versions to different sets of customers at different times?  Frequently this is required.  Does your DevOps / PaaS support this?

Can you configure the system to implement the rules you want in your devOps?  You may have specific testing, specific configuration or proxies, adapters or other configuration, plug-ins for monitoring.  Can you configure the business process in your DevOps / PaaS to support arbitrary ad-hoc additions to your applications?

Can you require that before something is “promoted” from testing to staging or staging to Production that certain people need to approve it or certain tests need to be performed?  Does your DevOps / PaaS need to have the ability to manage the process of promotion and demotion in case something bad goes wrong?

Does it provide additional security protection to prevent one tenant from damaging another or one application from damaging another?  Your DevOps / PaaS can use various kinds of tools like SDN and manage network devices automatically to insure that even an errant application or tenant can’t harm or access other tenants or applications.

Can you specify some tenants get different deployment considerations?  Does the devOps platform handle the allocation of new instances automatically or allow you to set rules for those instances to be created or torn down?  A Rules engine is useful to specify things like hysteresis you may want for putting up and tearing down instances.  You may have different rules for different classes of customers or different times of the day.  A capability to be able to configure the rules for scaling, what KPIs or measures are used to determine when to scale or not and when to tear down, how much to scale before just “maxing” out what you have decided is your limit.  This is critical to getting the kind of cost control and performance you want to customers.

Does the platform give you powerful capabilities to monitor the status, SLAs, KPIs you decide are important for your applications?  Can you collect data and KPIs on the performance of all the applications to be used by the system and examined in dashboards easily?  There are many monitoring products on the market but a basic functional monitoring capability is a big plus for the DevOps/PaaS tools because they are integrated with the metadata of the platform.  Otherwise you will have to do an integration of your monitoring tools with your DevOps/PaaS framework so they don’t step on each other.

Does the platform give you plug points to introduce your own specific requirements and tests?   Does the DevOps / PaaS platform give you places you can insert your own code or your own processes?  If the DevOps / PaaS platform is open source that solves one problem in that you can always go in and change the code but wouldn’t it be better if people had thought beforehand where and how these plugpoints should be and give you the ability to insert your own capability in exchange so that the result is more supportable?  If it is not open source solution are you sure that is safe or okay?  DevOps / PaaS sounds simple but automating something that DevOps professionals spent whole careers doing is not quite as simple as all that.  The point is that there is complexity in doing this DevOps and a lot of value to be gained by choosing a solution that is flexible and enterprise grade, that has already thought about the issues you are likely to come across as you deploy applications.

These are some of the questions you will want to ask and to help you understand what the costs will be for you to work around limitations in the devOps platform you choose.

Summary

The point of implementing DevOps / PaaS is to produce agility and to get products into production quickly.  If you have a single application and you understand its deployment very well you may decide implementing your own chef or puppet scripts is a fine way to go.   However, if you are like most organizations and you have many applications you know that in the future you will have new requirements and these will involve many issues that will require you manage tenants is a more sophisticated way, then you will benefit from a more full featured DevOps PaaS environment.  Consider all the questions I brought up earlier as part of your evaluation.

WSO2

WSO2 Private PaaS is a DevOps / PaaS platform that gives you enormous flexibility and power.  It is enterprise grade and ready.  WSO2 Private PaaS is open source which means that the plug points to extensibility such as polyglot development frameworks or cartridges, templates and other key points of customization are in open source and available for you to modify if necessary.  It also means that other companies or individuals can add new capabilities that you can leverage easily.   WSO2 is working with Apache to incubate Apache Stratos (from WSO2 Private PaaS) the place where everyone can go to standardize on PaaS / DevOps functionality and plug points for new functionality.   Please check out Apache Stratos as another place to start your search for DevOps platforms and PaaS.