Free Minecraft Premium

Free Minecraft Premium: I just got a free redeem code from this site http://minecraftupgrade.com

Free Minecraft Account

Free Minecraft Account: Awesome http://minecraftupgrade.com

Comparison of top DevOps tools (Pros and Cons)

Tools	Puppet 3.0	Chef 11.4	Ansible 1.3	Salt 0.17
Pros	Modules can be written in Ruby. Web UI handles reporting, inventorying, and real-time node management	Cookbooks and recipes can leverage Ruby Centralized JSON-based "data bags" allow scripts to populate variables during runtime Web UI lets you search and inventory nodes, view node activity, and assign Cookbooks, roles, and nodes.	Modules can be written in any lang. No agent required on managed clients. Web UI lets you configure users, teams, and inventories, and apply Playbooks to inventories. Extremely simple to set up and manage	State files can be simple configuration templates or complex Python or PyDSL scripts. Can communicate with clients through SSH/local agent Web UI offers views of running jobs, minion status, and event logs, execute commands on clients Extremely scalable.
Cons	Requires learning Puppet DSL or Ruby Installation process lacking in error checking and error reporting	Requires knowledge of Ruby programming Currently lacks functional push commands Documentation is sometimes vague	Lacks support for Windows clients Web UI doesn't tie into an existing Ansible deployment automatically; inventories must be imported	Web UI is not as mature or complete as competitors Lacks deep reporting capabilities
Pricing	Free open source version; Puppet Enterprise costs $100 per machine per year	Free open source version; Enterprise Chef free for 5 machines, $120 per month for 20 machines, $300 per month for 50 machines, $600 per month for 100 machines, and so on	Free open source version; AWX free for 10 machines, then $100 or $250 per machine per year depending on support	Free open source version; SaltStack Enterprise costs $150 per node per year, with volume discounts and site licenses available

Survey: Nearly Everybody Will be Using DevOps by End of 2015

DevOps adoption is expected to reach 93 percent by the end of 2015, according to a new survey commissioned byRackspace. A big portion of that number consists of respondents who have already implemented DevOps practices (66 percent), with more than a quarter of respondents planning to implement DevOps by the end of the year. A significant majority (close to 80 percent) of respondents are using some sort of outsourced DevOps services, a key finding for providers that have services that help customers use DevOps tools and practices, such as Rackspace.

DevOps combines many of the roles of systems administrators and developers. It is a set of principles driving greater collaboration between the different groups responsible for taking a product or service to market. IT automation products are DevOps tools, and agile software development is the cornerstone of DevOps, as the overall environment is becoming more dynamic. Major technology shifts of Internet business and collaboration technologies, open source software, and cloud computing are prompting the shift.

Rackspace has reason to both commission the survey and tout the results. It has been building up its DevOps services, and the survey supports this strategy. The Texas company has focused on managed services for cloud in order to distance itself from other cloud infrastructure service providers.

It’s known for its “Fanatical Support,” a message and philosophy the company is evolving for the cloud services world. Fanatical support extended to DevOps and automation last year, and 18 new services were launched this year. DevOps Automation is the highest tier of managed services.

Vanson Bourne performed the study, interviewing around 700 IT decision makers across the U.S., U.K., and Australia. The key takeaways, according to Chris Jackson, CTO of DevOps at Rackspace, are that the operations team is the primary driving force behind the change to DevOps, and customer satisfaction is the biggest benefit.

Given that DevOps is still in its infancy, such high penetration is almost hard to fathom. It is also hard to capture the maturity and stage of a company’s DevOps transition. The survey does examine which DevOps practices have been implemented, with half saying that development and operations teams have been fully integrated, suggesting mature DevOps adoption:

A granular breakdown of how DevOps is being executed across the organization, courtesy of Rackspace

 

The survey shows that DevOps is important, almost all companies strategizing how to move to this approach. The key priority for future implementations is to align DevOps goals with business goals. “The results of the DevOps Adoption Study validate that there is significant recognition among global businesses that DevOps is fundamental to fully exploiting the cloud in the pursuit of driving rapid innovation,” said Prashanth Chandrasekar, GM of Rackspace’s DevOps Business .

What’s the big deal about DevOps?

The biggest business benefit of switching to DevOps is the increase in customer satisfaction (over 60 percent), according to the survey. Other benefits include a reduced spend on IT infrastructure and a reduction in application downtime or failure rates, cited by about half of respondents as the biggest benefits. One third reported increase in sales and employee engagement as the benefits.\

Over 700 IT decision makers breakdown the IT benefits of DevOps (Source: Rackspace)

“Through cultural alignment, automated deployments, and agile infrastructure, businesses are using DevOps methodologies to reduce time to market by responding rapidly to customer feedback — ultimately driving significant business value and efficiency,” said Chandrasekar.

The technical benefits of DevOps are faster delivery of new features, a more stable operating environment, increased innovation, and better collaboration.

DevOps implementation

A keep it simple phased wise approach to implementing DevOps  in your organization (this is strictly not prescriptive) :

1. Scoping - Define a clear scope of what you intend to put under the DevOps services umbrella. Also which applications would you want to start with at the outset. A phased approach with a smaller non business critical application is the way to go about it as opposed to the Big Bang approach.
2. Human Resource - You may want to start with your star performer of course but make sure that he has these three most important skills : scalable and flexible, promptness and process orientation.  Also, the most ideal candidate for your DevOps core team would be a system admin with good scripting/automation skills or the agile-admin as they are more popularly called today.
3. Process framework - Whether you want to start with ITIL first and then integrate agile/scrum into the process or vice-versa. This is very important so as to prioritize from the inception so that right processes can be tweaked based on ITIL principles or agile methodology.
4. Defining  KPI's - Changing the KPI's like MTTR and MTBF has to be revisited and new metrics should be defined, implemented and measured. .This measurement is key to understanding the business and operations benefits that the company achieves with DevOps implementation.
5. Automate - Automation through tools and scripts is one of the key tenets of DevOps. The sole objective of DevOps is to achieve Quality @ the speed of delivery which requires processes to be automated and applying lean methodology by eliminating redundant processes.  

It is very imperative that the team is educated of the culture of continuous testing, integration and delivery which is built into the process to achieve the expected efficiency from DevOps implementation. 

DevOps ..contd

DevOps is soon getting synonymous with management of IT automation. DevOps is more of an organization’s culture than the actual process. It is a stronger collaboration between developers and operations engineers. Developers are expected to turnaround new developments faster and operations engineers are expected to maintain up-time by following a set of defined processes. While change is the daily routine of Developers, for the operations engineer it is an absolute alien (more of 'follow the process').

DevOps predominantly is an extension of Agile methodology. In layman’s term, it would mean putting a system administrator in the agile development process. On the ground, it involves a lot of coordination between teams where tools play a very important role in streamlining communication, documentation and tracking. These tools are used for app/infra automation like automating the testing process, deployment and release process, change process, etc., as described below:

Change Management

Objective: To enable beneficial changes to be made, with minimum disruption to IT services.

Release & Deploy Management

Objective: To plan, schedule and control the movement of releases to test and live environments.

Incident Management

Objective: The primary objective of Incident Management is to return the IT service to users as quickly as possible.

Knowledge Management

Objective: The primary purpose of Knowledge Management is to improve efficiency by reducing the need to rediscover knowledge.

Commonly used tools:

Automation: Puppet, Chef, CFEngine, Ansible, Salt Stack, Docker

Functional Testing: Cucumber, QTP, Rational, Selenium, Visual Studio Test Professional

Configuration Testing: ScriptRock

Continuous Integration: Jenkins, Travis CI, Ant, Circle CI

Continuous delivery: IBM Tivoli

Content Management System: SharePoint, Wiki, Joomla.

Monitoring and graphical analysis: Nagios, NewRelic, Ganglia, iperf, AWS

While ITIL develops process culture in an organization and brings process maturity, agile helps in accelerating the processes ensuring faster time to market. With the right process combination and marriage of ITIL with agile, an organization can reap the benefits of speed and improved customer satisfaction; which the industry today has termed as " DevOps". 

DevOps Lifecycle

How true it is that a picture speaks a thousand words. The below picture explains the DevOps life cycle in a brilliant manner:

For more information on 'DevOps'. Please stay connected....

Defining Priorities

 ITIL says that Priority should be a product of the Impact/Urgency matrix. ISO/IEC20000 agrees with that in 8.1 Incident and service request management.

It is customary that Priority of issues has four to five levels. It is most commonly marked with the numbers 1-4 or 1-5, where "1" is the highest and "4/5" is the lowest priority. 

PRIORITY = IMPACT X URGENCY .  

Below is how the ITIL priority matrix looks like:

·         Impact - Is defined by the criticality of downtime is for the business. Usually measured by the number of users affected. For e.g.: If one or more application/ services are down.

·         Urgency - it is usually defined in SLA for the specific IT service. If more than one service is impacted, parameters for the higher urgency service will be taken into account.

Managing SLA’s using COBIT

Objectives:

Objective 1: SLA framework: Management should define a framework to promote the definition of formal SLAs. Define the minimal contents such as availability, reliability, performance, capacity for growth and levels of support provided to users. Users and IT function should have a written agreement that describes service level in qualitative and quantitative terms and responsibilities of both parties.

Objective 2: Aspects of SLAs: Explicit agreement should be reached on the aspects that an SLA should cover (e.g., availability, reliability and performance).

Objective 3: Performance procedures: Management should implement procedures to ensure that the manner and responsibilities for performance governing relations between all the involved parties are established, coordinated, maintained and communicated to all departments.

Objective 4: Monitoring and reporting: A service level manager should be appointed for monitoring and reporting on the achievement of the specified service performance criteria and all problems encountered during processing.

Objective 5: Review of SLAs and contracts: A regular review process for SLAs and underpinning contracts with third-party service providers should be in place.

Objective 6: Chargeable items: Management should include provisions for chargeable items in the SLAs

(Rewards and Penalties)

Objective 7: Service improvement program: A process to ensure that users and service level managers regularly agree on a service improvement program for pursuing cost-justified improvements.

Maturity levels:

Maturity Level	State	Indicators
0	Nonexistent	Management has not recognized the need for a process for defining service levels.
1	Initial/ad hoc	There is an awareness of the need to manage service levels, but the process is informal.
2	Repeatable and intuitive	There are agreed-upon service level agreements, but they are informal and not revised. Service level reporting is incomplete.
3	Defined process	The service level agreement process is in place with checkpoints for reassessing service levels and customer satisfaction.
4	Managed and measurable	Performance measures are increasingly reflecting end-user needs, rather than only IT goals.
5	Optimised	Service levels are continuously reevaluated to ensure alignment of IT and business objectives.

ITIL 2011 diagram