The DevOps goal is to improve the communication and cooperation between the development and the
infrastructure teams. Sadly, nothing is mention about the infrastructure needs for other departments'
teams such as Sales, Marketing, Credit, Treasury, etc. These teams have web presence and run third
party and customized software tools. Building Intelligent DevOps Editor with "Turn Key" features
requires that we must have a good handle on all the details of running infrastructure team (provider) and
their clients. To have "Turn Key" features, we must address the needs of our editor end-users.
"Turn Key" features would reduce if not eliminate any or all the interfaces
between the infrastructure team and their clients. We also need to leverage Virtualization in
building virtual networks.
Our Intelligent DevOps Editor - "Turn Key" Software
Software tools are bought "as is" from vendors, build-in-house, outsourced to consultants or
combination of buying, building and outsourcing. Most institutions such big banks or insurance companies
are not in the business of building software, but they still have several development and testing
departments. The same thing can be applied to infrastructure. Customization and support of these
software tools may run into several issues such as cost, time and changing technologies. These
institutions would be under the mercy of the needed support from their software vendors and consultants.
In-house tools have very high risks if they are not well designed, tested and
documented. Therefore, our approach is to build a well designed, well tested and
well documented software tools.
Our approach is to use Object Oriented Design with Virtualization to build our Intelligent DevOps Editor.
Object Oriented Design (OOD)
Object Oriented Design (OOD) can be used to build a virtual structured environment. It would be composed
of manageable objects. Our OOD Virtual Model (see the link of Building Using OOD web Page) would make it easy to:
• Structure and size
• Move around
Also such virtualization can be created as a running prototype, or we can build software programs
as a model virtualizer similar to ones that are used in building airplanes, big buildings or
high-rises. Such a program(s) can be created as a way to give estimates, be part of the planning as
well as test other criteria without building anything.
For more information on our virtual OOD approach see the following link:
Image #1 is a simple representation of how Virtual Servers
and Virtual Servers Container can be implemented. Infrastructure teams can work with a software
vendor to develop their own unique and customized software tool with GUI interfaces. This would be used to
automate building Virtual Servers and Virtual Servers Containers.
Image # 1
Figure #1 gives a graphic representation of building Object Oriented Servers and Server
Containers. The Application Server Container is a virtual object which has other virtual
servers as virtual objects. An Application Server Container may have a virtual web server
such as Tomcat, a firewall software as virtual server and virtual File Transfer Server such
as FTP. The same thing can be applied to the Database Server Container with virtual FTP
server, Oracle virtual server or any third party software running as a virtual server within
the Database Server Container.
With such server virtualization, then automation and customization can be implemented. Such
automation can produce an infinite number of virtual servers and containers. These virtual
servers can be created, customized, installed, duplicated, cloned, deleted or cut/paste into
and out of any network or virtual network.
The Concept of "Turn Key"
Turn Key of or involving the provision of a complete product or service that is ready for immediate use.
The goal of our Intelligent DevOps Editor is eliminate the communication and the cooperation issues
between the Infrastructure team and their clients such as the development team. Our Editor provides
a GUI interface for any team to create any server type and software installation for their infrastructure
needs. They simply use an interactive-user-friendly GUI interface (see Image #2) to fill out all specification
parameters. Our Editor parses their requests and runs a number of checks which include resource, security
requirements, time of delivery and the team access and resource privileges. It may requires further
questions, ID and permission privileges. It would grant the team's request with a un-shaded GUI "Build"
button which would be clicked to start in real-time building of all their requested infrastructure servers
and software. They would also be able to run a number build-in tests to insure their approval.
With the same GUI interface, teams can save, save as, delete, clone, inherit previous builds, and other options.
Roll Back can be easy as build one of the previous saved version or setting.
The backend of our editor has a number of software components which would build in real-time all the
infrastructure components and their tests.
A number of statistical software components run to help with updating and evaluating the editor performances.
Our Intelligent DevOps Editor
What is a software editor?
In general, an editor refers to any program capable of editing files. Good examples
are image editors, such as Adobe Photoshop, and sound editors, such as Audacity or
for text editor such as Microsoft Word or WordPerfect.
What is a DevOps Editor?
The best answer is to present a picture or image and Image #2 is our Editor's markup or prototype for
audience to examine. The editor features are covered in the DevOps Editor GUI Interface section.
How can we build such an Intelligent DevOps Editor?
The key feature of our editor is Intelligence. Intelligence here is not Artificial
Intelligence, but developing intelligence software. We communicate with gurus of
development and infrastructure, and try to pick their brains. We build a number of
processes and tasks mimicking these gurus handling and approaches. We rearrange
these processes and tasks in order to be able to translated them to code and a running
software. With the computer processing speed, thousands if not hundreds of thousands of
processes and options can be performed on the input data in seconds. These processes
add to intelligence of our editor.
The following are the steps and processes which would include the analysis, architect-design
and development, testing and documenting of building our editor. It also includes running
statistics for improving our editor and its performance:
• Interview all the gurus of every business unit and pick their and turn their expertise into processes
• Research other companies and competitors for building networks
• Figure what the outside world is doing
• Create a set of questions and answers that would be asked the end-users
• Interview the end-users and figure out what is nice to have and have to have
• Document best practice for build a virtual server
• Research best automated virtual server builder software-tools in the market
• Run a number of statistics to find out frequent settings built by each department
• Build a number of default setting and values
• Create a number of automated tests for each virtual server setting
• Run a number of statistics to find most errors and how they would be handled
• List all possible misc handling processes
• List all possible exceptions and errors handling processes
• Build a number of script, tests and templates which can be used in our build
• Estimate the cost of building the editor
• Brainstorm the editor with the team and management
The above steps and their output are our editor architect-design-development-testing specs.
We would build the editor markup and prototype and test them with end-users feedback.
A "Beta" version should be developed and tested with end-users feedback.
DevOps Editor GUI Interface
To make our Intelligent DevOps Editor concept easier to understand, we may need to
present a picture. We are presenting a markup or a running prototype with a GUI
interface for our audience to examine. Image #2 is our editor prototype and
also a link to an HTLM page which would popup for our audience to play with and
see our editor's features. For further clarification, we are presenting a summary
of some of our editor' features or functionalities.
Image # 2
Check previous section which covers Intelligence: "How can we build such an Intelligent DevOps Editor?"
Our Editor's users would enter all the required data which would be stored into Java arrays
and objects. Our Editor's backend processes would cross reference the data looking for
errors, duplicate values, out of range values or any red flags. It
would prompt the users for corrections and what is doable.
Users can click the "Check List" button to make sure that all the required data are entered.
Test, Clone and Build:
Users have the option to test their input data and see if our editor can
create a running target environment. They can "Save" or "Save as" the entered data
and settings. They can import from other previously built environments. The difference
between "Clone" and "Save as" is "Save as" saves the input data, and "Clone" on the
other hand would save the running environment with all its updated settings and
scripts. As for Build option, our editor would build the target environment for
immediate use in real-time. Such running environment can be cloned as well a saved.
Our Setting is not just a random settings, but we would be using the history of
each department (development, credit, Sales, etc) infrastructure features, settings
and issues. Project name and ID would identify which department is using our editor. Based
on which department is using our editor, the default setting would be automatically
loaded into the editors. Each department would have its unique default settings.
The default setting will change as technologies, users demands and Changes Requests.
To us documentation is very critical to our running environments. Documentation
can help in tracking and finding errors, issues and trends. It can also aid in
building statistic which would be used to make our Intelligent editor more intelligent
and dynamic. To automate documentation, we build two documentation sections:
• Build-in Templates: which would be filled out by the users.
• Free Hands: where users to give their own document and feedbacks.
Users' free hands would be periodically checked for how we can improve our editor.
Management is another critical part of running and managing these target
environments. Again, we have two management sections:
• Management Processes: which would help managers perform their expected tasks.
• Free Hands: where managers give their own document and feedbacks.
Managers' free hands would be periodically checked for how we can improve our editor.
Online Help Doc and Recommended Settings:
Our Editor users can be anyone from any department. Users may or may not be network
or web savvy, nor expected to experts on infrastructure requirement. Online Help
Doc and Recommended Settings are the documentation of how to build the required
environments with examples and the default settings. We would also provide tutorials
and training for departments team members.
Target Environment Software Components and Environment Settings:
Users may use the default setting or change them to their
needs. The documentation for the online help and setting are for users to utilize
in figuring out their environment needs.
Testing is very critical in building error free environments. There is auto testing and manual testing.
Manual testing is an option for users to test their own unique scenarios.
Our Editor would not allow any Building unless auto testing or manual testing are completed.
Our Intelligent Infrastructure Editors
What is already done - Our Intelligent Infrastructure Editors
We recommend that our viewers visit our CRM Data Farm site and checkout our Post Office
Project's Intelligent Infrastructure Editors for Building, Migration and Testing Data Centers.
For Our Intelligent Infrastructure Editors see the following links on our CRM Data Farm site:
Pros and Cons
Our ICM architect is not small project nor easy to implement. Our Intelligent
DevOps Editor is a tough sell to any company.
• Makes ICM's goal of building intelligent data services a reality
• Remedies the communication and cooperation
• Can be used by other departments not just the development
• Sets the stage for more intelligent and futuristic approaches
• Helps in building data centers and reduces the cost of building and migration
• Needs a good grasps on subject matter
• Needs dedicated teams of analysts, architects and developers
• It will be a hard sell to management