DevOps.com published an article, ‘6 Common Causes of Conflict DevOps Sets Out to Solve’, which gives some great insights into each of these problems. The first one caught our attention:
1. I need a server… now
This is without a doubt the most common complaint we hear: that operations teams, or those responsible for making infrastructure available to development are blockers, too slow and don’t understand the needs of the business. What we see actually happening is demands for immediate drops of physical and virtual servers from teams who not only have literally just heard of this requirement coming down the line but have a pretty full on schedule of planned work too. Oh, and more than likely unexpected system failures and defects are generating a fair amount of unplanned work too having a direct knock on effect to their ability to respond to these demands and their planned work.
Gartner said in 2010 that “the DevOps philosophy was born primarily from the activities of cloud service providers as they worked to address scale-out problems due to increasing online service adoption.”
Fast-forward to today and Gartner defines DevOps as “a change in IT culture, focusing on rapid IT service delivery through the adoption of agile, lean practices…”
Get ready for this one… not all multi-cloud offers are created equally. Here are a few ways ‘multi-cloud’ is being used to describe what’s happening with (and in) the multiple clouds.
Multi-cloud – multiple clouds, each hosting a different application belonging to the same organization
In this case, the commonality between clouds is most likely the person managing the cloud. This person is probably jumping from one user interface to another – Microsoft, AWS, Joyent for example. He or she is probably going through the hassle of learning (and keeping him or herself up to date!) with all the user interfaces as well as the terminology and the tool chain of all the clouds involved. Instead, this person could do with a consistent interface between all these clouds, to help simplify the management process and speed up the deployment and the day-to-day operation of his applications across multiple clouds.
Chef are industry leaders in IT automation, offering significant benefits such reducing the time and effort, as well as risk of manual error, involved in building, configuring and managing application stacks. For the DevOps community, this is great.
Chef’s a fantastic tool that most people want to dig into straight away. First, though, you have to set it up and configure the Chef servers and clients including all the various dependencies involved. Then you have to manage, pull and execute Chef cookbooks. This is in many cases a repetitive task. The good news is you can manage Chef more easily by having Flexiant Concerto carry out these tasks for you. Here is how.