One of the things we do at Zefflin is help IT organizations to automate the lifecycle of complex, N-tier applications. This means defining applications once (blueprinting), deploying and upgrading them automatically in heterogeneous hybrid cloud environments and auto-scaling up/down based upon demand.

This type of automation is being adopted widely.  The reason is that it pays off in a big way.  

Application automation ROI:

• Productivity - the same group can manage many more apps in a more complex cloud-based environment
• Agility - app dev groups can respond faster to business needs or market changes, enabled by improved application portability
• Speed - by enabling continuous integration and continuous delivery, application development cycles are accelerated because the time between code --> build --> test --> QA --> migrate to production is dramatically reduced  
• Cost Reduction - by utilizing a hybrid cloud model and adopting modern DevOps practices, customers can reduce both infrastructure and application development costs

Because of the maturity of tools, the cost of automation is now lower than it has ever been.  In order to get the full benefits of application lifecycle automation, however, it must be fully integrated into an operational environment. IT Service Management and ITIL in particular, has been widely adopted by IT organizations. That means IT support processes are delivered in a consistent way, from the way IT interacts with its users, to responding to environment failures, to managing changes to the production environment. 

Many of our customers are telling us: "We need to integrate application automation with our ITSM processes".  For example, when an application deployment does not go as planned, an incident should be opened so the failure can be tracked and the right people assigned to fix the issue.  When the same application is deployed successfully, it represents a change to the production environment. As a result, a change request should be opened so ITIL-compliant audit requirements are met. In addition, the Configuration Management Data Base (CMDB) should be updated, so applications can be mapped to the infrastructure on which they run.

What if all of that could be done automatically?

To fill a need expressed to us often by our customers, Zefflin has developed a Cloudify plugin that supports integration with ITSM tools like ServiceNow.  We have applied years of experience in ITSM and application automation to develop an out-of-the-box integration that will:

• Auto open an incident if an application deployment or upgrade errors out
• Auto update the CMDB upon successful application deployment, upgrade, scale up/down or tear down
• Auto open/close a change request upon successful deployment of an application
• Accommodate customer-specific policies for application mapping and CMDB

The Cloudify plug-in for ServiceNow is designed to enable fast, reliable integration with standard ITIL processes with minimal implementation effort.  Customization can be done to accommodate variations of business process for specific needs such as:

• Specific CMDB governance policies
• Incident Management assignment rules
• Specific CMDB application mapping requirements
• Diagnostic information passed to an incident on auto open

In evaluating various solutions for application lifecycle automation, customers must confront a confusing array of orchestration solutions. Orchestration comes in two flavors: application, and operations.  Many times the two are confused, but they are very different. Operations orchestration products are designed as general purpose, event driven process automation tools. They are excellent for automating repeatable IT operations processes like onboarding employees, granting access or integrating disparate systems like monitoring and ITSM. Application orchestration tools are designed for apps only, and all the processes associated with their lifecycle, like define-once (Blueprinting), deploy, upgrade, auto-scale and tear down. They are not Cloud Management Platforms (CMPs), but augment and compliment CMP functionality. Application orchestration tools are procedurally focused (as opposed to event driven). They can be event driven, but only for very specific events, like those that trigger auto scaling.

Choosing the wrong tool to solve your business problem will result in a very long, expensive implementation.

DevOps is about people, process, and tools, working together.  DevOps Transformation is about change from an existing working environment to a new environment encompassing a DevOps model.  If you don’t already have development and operations teams you may not transform anything, but form a DevOps team from scratch.  This paper will highlight a best practices approach, key risk areas, and what you can expect from DevOps, to help you make informed decisions.

In simplest terms the word “DevOps” is a Portmanteau which, by definition, is a term formed by munging two words together into a compressed or tighter single word.  In practical terms, it involves taking two huge and complicated organizations and their associated practices, priorities and processes, “Development” and “Operations” and making them a single, powerful coherent entity. 

 Traditionally, application development and IT operations have been organized in silos, with clear delineation of responsibilities.  App dev has been responsible for design, code, build, test, bug fixes and QA, where operations was responsible for production cutover, migration, support and reporting back of bugs.  Because of the clear lines of responsibility, hand-off processes had to be derived and implemented.  The result?  Both sides optimized their respective organizations as they saw fit.  This seemed like progress, but in fact resulted in inefficiencies, finger pointing and less then optimal use of resources.  DevOps as a discipline seeks to correct this situation and establishes a single set of processes and underlying technologies that enable the next generation of optimization, efficiency and cost reduction in IT.

Delivering DevOps ROI

DevOps as it turns out, is the compression of all the complexity to reduce the red tape, to improve alacrity, agility and delivery quality of products and support services.  This improves customer satisfaction at high velocity with better time to market and timely release of products to maintain and gain market share.  Properly implemented, cost reduction and fast ROI can be achieved. 

Examples DevOps adoption delivering at scale  

One example of where we see DevOps employed by a global community to deliver relevant, disruptive core products at very large scale is in open source and how it is being employed as an enabler to cloud product delivery.  Keep in mind that open source software is by definition open which allows reuse and contribution to the code base by multiple voluntary entities.  Although it is not always free, open source products are often sold as part of a common business model and can come with durability, dependability, comprehensive support, service level agreements (SLAs), and standards.  Some very large scale IT industry leaders are open source contributors.

OpenStack is an example of this well-established model.  It has a great number of contributing developers worldwide, and many enterprise software companies are jumping on board.  VMWare integrated OpenStack into its product line, for example.  HP also delivers its own distribution of OpenStack.  RedHat includes OpenStack integration and management in its platform.  There is a primary code trunk and multiple branch distributions where product specialization is done and code is contributed back to the community as open source.  These specialized versions are used in some mission critical areas within the enterprise as is the truly open trunk.  The processes to do this are common with standards that evolve from the community.  Practices combining development and test, QA and operations via automated tooling for deployment and solid product management are jointly built, employed and refreshed.  This model is so successful, many organizations large and small, embrace it completely. 

Review  

So we have covered the DevOps of One, of small teams, and DevOps of many.  Therefore, we can draw some conclusions about DevOps:

• It delivers within industry standards (PCI, HIPPA, etc.)
  
• It enables faster time to market
  
• It can produce relevant ROI
  
• It is employed by both startups and industry leaders
  
• It has a broad community support 
  
• It integrates well

In the world of enterprise software, product management and all the processes associated with it are well understood.  Enterprise software companies constantly evaluate market conditions and develop a product roadmap that includes development of future functionality and product direction. 

With open source software, the rules are different.  For some open source software, the product management function is still contained inside a single software company.  For OpenStack (also in the case of Linux), the product management function lies with the OpenStack Foundation, an independent non-profit organization which has its own by-laws, procedures and governance.  It's board members are also elected by the community, which minimizes dominance by any single vendor.  This changes the dynamic completely because market requirements have a different path by which they become product functionality. Any developer can submit a code change for consideration.  Companies can employ (at their own cost) any number of developers, thereby vying for influence by sheer number of heads.  Enterprise software companies like VMWare, HP, IBM and others are embracing OpenStack, but they also have significant software license revenue that is complementary and/or competitive with OpenStack. This is not a bad thing, but is an important nuance to understand for anyone considering a long term commitment to OpenStack, because some product features may have genuine market pull, while others may be influenced by enterprise software.  There are advantages to this also. For example, VMWare Integrated OpenStack (VIO) has strong integration to vSphere, vCloud Director and the entire VCloud Automation suite (recently renamed to vRealize Suite).  HP Helion OpenStack, has strong integration to their cloud automation suite, including Cloud Service Automation (CSA) and Operations Orchestration (OO) products. 

The code development and management process is also a major consideration for any software user.  In the enterprise software world, the entire development process is owned by a single vendor from code, build, test and QA to packaging and distribution.  It is assumed that any enterprise software company has safe-guards and processes that ensure code quality and security.  With OpenStack, the development community is very large.  For the latest release (Kilo), some 1,500 developers put their weight behind Kilo, merging over 19,500 patches and dispatching with nearly 14,000 tickets, all in a 6 month period.  The coding, QA and security processes have to be automated and very disciplined in order to enable this volume and size of developer community.  The OpenStack community has adopted modern DevOps and automation practices. Code checks covering code quality and security are more stringent than most software companies have internally.  This is by necessity and is a very good thing for the user base, because the structure applied represents a lower risk for users.  

There are tremendous gains to be had from adopting OpenStack as part of a full private cloud strategy.  Each IT organization is unique and you should approach it with your business requirements, constraints and current architecture in mind.  Understanding of OpenStack, its ecosystem and open source software is essential, however.  

As big as the advantages can be, it is critical to understand that OpenStack, as an open source component of your operation, is a different world than other proprietary enterprise software you might be used to.  Those who grasp the differences and leverage them to their advantage will be successful with OpenStack.

As an IT leader, you are faced with supporting a growing business while budgets remain flat.  At the same time you are expected to increase the speed, quality and reliability of service – all as technology constantly evolves and changes.  Virtualization of the IT compute and storage infrastructure has revolutionized operations, increased productivity and resource utilization, and brought new agility to IT.  But virtualization has also created new challenges and problems.  Even after making virtualization an integral part of operations, many IT organizations find themselves asking “What else can we improve upon?”
The answer lies with the next logical stage in virtualization’s evolutionary path:  automate IT operations functions to increase productivity.  Regardless of the cloud architecture chosen (public, private, hybrid), automation of processes in the areas of Catalog/Request Management, Approvals, Chargeback, Provisioning (not only OS, but storage, network, database and application), Governance and Compliance yields a significant ROI for today’s IT organization.
Software tools that are used to automate IT processes have matured significantly in recent years.  They now cost less to implement and are easier to integrate into existing infrastructure and tools.  Superior integration capability means that previous investments in areas like virtualization can be preserved and a best-of-breed approach can be taken without forcing vendor lock-in.  Open source software like OpenStack™ has put tremendous downward pricing pressure on traditional enterprise software.  This means that the ROI of automating specific parts of IT Operations has changed in favor of the CIO, and what a short time ago might have been a significant financial commitment with high risk is now much less in both cost and risk.  Automation is feasible, affordable and carries much lower risk than even one year ago. 

This blog entry is based on an abbreviated version of a white paper published recently by Zefflin.  To obtain the full copy, click here.

There are many software tools on the market today, with new ones emerging regularly.  The list below is not a comprehensive one, but shows some of the industry leaders.   Tools vary greatly in maturity, cost and scalability.  They vary in scope from pure orchestration, DevOps, OpenStack distributors and full scale Cloud Management Platforms.  The key is to select the right tools for your organization that will minimize cost, risk and resource investment, while enabling your organization to grow the solution as your company grows.

For more details about software vendors and tools, download the white paper.

An automation strategy and a plan go hand-in-hand with a cloud strategy.  A cloud strategy and architecture, whether private, public or hybrid is an essential first step, but is only part of the answer.


The following steps are essential in adopting an automation strategy.

1.       Cloud strategy, architecture and roadmap.  It is important to understand what you will be working with before considering automation.  For example, choosing AWS as your primary platform provider may affect the choice of automation tools (like orchestration or server provisioning) and processes (like application provisioning or compliance).

2.       Step back and look at all manual processes.  It is important to objectively look at any manual processes.  It is equally essential to look at each process from a ROI perspective:  how much do I have to invest in automating this process?  How much do I have to invest in maintaining it? and how much labor can I save as a result?  Caution: pride of ownership and turf protection can influence the outcome of this review – it must be strictly objective.  Some processes may have to be adjusted or re-engineered which adds to the cost.  Examples of simple processes to automate would be server root password reset or event remediation.  More complex processes might include application provisioning and configuration.

3.       Develop a short, medium and long term strategy and objectives, with ROI expectations for each stage.  This will help prioritize and set expectations.  Often it is good to start with short, quick win types of automation projects to prove the success and generate internal momentum for the idea of further investment in automation.  This planning should be done with a firm understanding of what is possible, feasible and risk appropriate.

4.       Identify software tools.  Today there are an incomprehensible number and variety of software tools, from open source to startups and well-established enterprise software companies, that purport to automate data center processes of all kinds.  New tools appear on a weekly basis. It is important to filter out the noise, cut through the hype and find out what will work for your organization at a reasonable cost.  It is also crucial to determine if you already own some of the software that can be used which will dramatically cut cost.  For example, if your company has a EULA with an enterprise software company in place, you may have access to some tools already under the terms of that EULA.  A solid orchestration tools is essential, as orchestration is the centerpiece to automation of data center processes.  It should be flexible, able to develop custom workflows without extensive training and have a large library of plug-ins or APIs that can be used to integrate with your existing applications such as service desk, change management or DevOps tools.

5.       Take a baseline for future comparison.  A baseline is essential in order to measure progress and success of future automation efforts.  A baseline should encompass metrics for cost and speed of service

For more information about how to adopt Data Center Automation in your organization and environment, download the white paper.

Data center automation is not just an option anymore.  You, as an IT leader, must continually provide value at a lower cost.  In order for your IT organization to continue supporting a growing businesses, remain relevant and prepare for the future, automation has to be an essential part of the strategy.  We have outlined some of the possible approaches, challenges, benefits, risks and returns in this white paper.  Every IT organization is different and should develop an automation strategy and plan in line with the objectives, resources and constraints of their particular business.

My first topic is something that may affect all of us, mainly because the outcome could disrupt most IT organizations.  This has not been widely published, but VMWare has recently been sued for IP infringement by the Software Freedom Conservancy and an individual Linux developer, Christoph Hellwig. 

This is apparently after several years of negotiation with VMWare.  The allegation is that VMWare used some open source Linux code in ESXi.  If this is true, VMWare illegally charged license and maintenance (excluding support) for what should have been an open source product.  Christoph and SFC have filed in German court, where there is precedence for injunctions for software IP infringement that have world-wide implications.  VMWare says publicly that there is no merit to the case. 

After reading some of the details, I think the decision could go either way.  It is an open question.

What does this mean to you?  It depends on the outcome, of which there are several possibilities.  In my opinion, VMWare has the following options: 

 VMWare’s Options:

1. Develop a new ESX that does not use the infringing code – it’s not exactly clear on the effort required, but could be significant
   
2. Settle with Christoph and SFC
   
3. Go to court 
   
4. Make ESXi open source
   

The GNUv2 open source license agreement under which Linux is distributed says clearly that if you use the code and add your own, you are required to make the result open source.  There are ways around this rule, mainly by architecting the resulting product to have a loosely coupled integration rather than embedded code (a “shim layer”).  VMWare chose not to take that route, however.  According to SFC, they have embedded the open source code into their compiled version of ESXi – that’s a direct violation of GNUv2.

All indications are that VMWare is putting effort into all options at this point.  It has been reported that they have allocated development resources to work on replacing the infringing code.  Even if they are successful, they still have the massive effort of upgrading everyone, and a lot of customers are not going embrace the idea of risking their entire virtualized production environment with a 1.0 of anything.   Even if they eventually replace the infringing code, they would still potentially be open to law suits from customers for all the back license and maintenance they paid for something that is open source.  Regarding option 2, they have tried to settle with the plaintiffs, without success.  Plaintiffs say that they were required to sign an NDA just to review the offer  – they declined.   In the unlikely event that they do settle, that still leaves them open to suits from the hundreds of other Linux developers, who could get very litigious if they saw a settlement was reached.  

Option 3 is go to court.  This could be an option but the stakes are very, very high.  If VMWare wins, this all goes away (assuming no appeal, and assuming no one else takes it up in another court in another country), and nobody’s life changes.  On the other side, the court could grant injunctive relief to the plaintiffs, meaning VMWare would be ordered to stop selling the ESXi immediately, in addition to having to carry out any other associated court order.  There is precedent in German courts for injunctive relief for software infringement that has world-wide implications.   If that happens, VMWare will likely be sued in other countries, including the United States.  They will also be vulnerable to a class action law suit by all their ESX/vSphere customers who could go after a refund of all the license and maintenance they paid (support charges are the only valid charges for open source), plus any damages and/or interest.  This could be significant.

The 4th option is to make ESX open source.  This would settle the suit, but would still leave VMWare open to customer liabilities for all the license and maintenance they paid before it was made open source.  Again, that’s a big pile of money.  This may be a viable option.  VMWare acknowledges the decline of vSphere sales and the threat of OpenStack to vSphere business in its most recent 10-k filing.  It may be pre-empting the inevitable. 

From VMWare 10-k


It’s difficult to predict the outcome of the law suit at this point.  This could go on for several years.  My guidance to anyone would be to watch this space and IF the time comes, make contingency plans for minimizing dependence on vSphere/ESXi.  OpenStack is gaining traction in both the SMB and Enterprise markets as it matures, governance gets tighter and the ecosystem continues to evolve.  Eventually the market will realize that you can do with OpenStack (and then some) what you can do with vSphere, and that since OpenStack is open source, software is free and support will run you around $2k per year per physical server.

If you have any questions or would like to discuss anything further, please feel free to contact me directly.  I sincerely hope you made it this far in the newsletter and that this was valuable information.