by Malcolm Herbert (Red Hat)
The post below originally appeared here on November 22, 2012.
A comparison between enterprise IT and public cloud computing dramatically highlights the benefits of moving to cloud.
Application deployment times can shrink from weeks in the traditional data centre to minutes in a cloud data centre; new application development time accelerates from years to weeks (or months at most); cost per virtual machine plummets from dollars to cents; server administrator ratios can explode from 20:1 to 300:1; while efficiency increases, with resource utilisation soaring from 20% to 75%.
With measurable benefits like these, it’s no wonder that IDC expects that by 2015 the majority of the enterprise market will require integrated hybrid cloud management capabilities (Source: IDC Cloud Management Study, 2011 Survey).
Continue reading “Five top tips for the journey to cloud”
by David Kang (Red Hat)
Cloud is not software, cloud is not hardware, cloud is not virtualization, and cloud is certainly not a panacea for broken IT. Cloud is an architecture: a set of fundamental tenets that have different implications at different levels of IT, from network, to hardware, to applications, and to the IT process itself. To say you have a cloud is to say that you have a cohesive architecture, technology set, and most importantly processes, that work towards a defined goal under a set of well-understood principals. Building your cloud is as much about defining your goals and governing principals as it is about investing in technology.
Building your cloud and consuming cloud services
Step one is defining your governing principals. This is a crucial step before embarking on your cloud journey as the policies and principals you define will help you navigate your journey through the rapidly expanding cloud ecosystem. This is also an opportunity to ask tough questions and examine what your principals and processes are, and why you have them. Process is ultimately about managing risk, so consider what risks are acceptable under your governance policies and weigh them against the potential benefits cloud can offer. Both Facebook and Google have adopted “deploy to production” models that seem to fly in the face of process conventions such as ITIL or RUP, yet somehow they seem to survive. The penalty for not doing this exercise is ballooning adoption costs, or failed rollouts all together.
Continue reading “Cloud Sniff Test: Cutting through the jargon”
by Zach Rhoads (Red Hat)
One of the core tenants of agile development is to focus on the tasks that are the highest priority and immediate need. This is sometimes referred to as “Just-in-Time” development. The idea is to focus on the tasks needed to ship the feature now and worry about everything else when it is actually needed. Another tenant that goes hand-in-hand with “Just-in-Time” is the idea of failing early. Basically, a team should know as early as possible if something is going to fail, that way the team does not waste time going down the wrong path. This means the team should develop a feature and solicit feedback in short cycles, allowing the team to quickly understand what works and what does not.
Continue reading “Reducing friction in agile development using cloud”