DevOps: It’s Different for Big Firms
As cloud computing matures, we hear more and more about DevOps. DevOps is a new term — not a new idea. It’s the effort to be sure that Development and Operations work together. Ensuring that the Dev and Ops work as a team has always made sense, and it especially makes sense today moving from Waterfall to Agile software development.
Here’s why: imagine you work for a large retailer (traditional, not a startup). You want to respond to new consumer demands, so that means creating a website. It also means integrating your traditional selling systems into the website through ecommerce. Now let’s say you want to add a customer loyalty key fob that ties in-store purchases to the website.
Not only do you need to deliver quickly, but you need to deliver all of your solutions at web-speed. Web-speed means Agile Pods must drop code (or want to drop code) every two or three days.
Herein lies the problem and opportunity: Dev wants to drop code every two or three days, but Ops needs seven days to approve a change and up to eighteen weeks to provision a new infrastructure. See the issue? From the Dev point of view, Ops is perhaps the single greatest issue to delivering the value promised by Agile and PaaS.
DevOps in large firms is an effort to optimize the software release process (including the underlying infrastructure). Since Ops is the slower of the two, Ops is the area we need to examine. Of course, any solution requires a change in both Dev and Ops.
Ops has certain needs:
- What changes: Companies of all sizes must meet significant regulatory requirements: HIPPA, PCI, SOX, GLBA just to name a few common ones. Change Management, usually in Ops, is normally charged with keeping the records that show the changes to production systems. Change Management is also typically the team that schedules release windows.
- Provisioning: Services, storage, middleware, operating systems, and networking all play a part in creating the infrastructure the new application will integrate into. Coordinating these requirements through automation is critical to DevOps.
- Feature information: Someone has to respond to customers using the new software. That is Ops’ primary job. Ops needs to know how the new software is supposed to work as well as how it works with the existing systems. Pushing new features into product should include positive feedback from Ops.
- Features not working as expected and workarounds: All software has bugs. A list of bugs and workarounds can save the business a lot of money. Ops can resolve customer issues faster if they know what doesn’t work in advance, so before a new release goes into production, Dev needs to inform Ops of any known errors so they can respond accordingly.
- Systems dependencies: Ops needs to know how the updated app might affect the infrastructure. For example, will it create significant additional load on the local area network (common for internal apps) or perhaps tax the mainframe? Did engineering help Dev? Hopefully they know this before the new software takes entire selling systems down.
Most of these are information requirements that are easily satisfied if the Agile team develops them during the sprint. If the requirements are put off until the end, company can wind up with outages and lost revenue.
The Cloud: What It Really Is and Means Series
- Cloud Computing: What You Need to Know
- Cloud Computing: What You Need to Do
- Your Cloud Success Requires New IT Roles
- When to Adopt Cloud Computing
- How to Adopt Cloud Computing Successfully
- What You Need to Do to Adopt Cloud Computing
- When is Cloud Adoption Right for You?
- Utilizing IT Roles for Cloud Success
- The Impact of Cloud Computing on Staffing
- Cloud Computing Risk Management: Trust But Verify
- How to Control Cloud’s Undesirable Side Effects
- Supporting Your Cloud Efforts with ITIL
- How to Manage Public Cloud Security
- Organizational Agility — the Real Benefit of Cloud Computing
- 6 Steps to Realizing Your Cloud Strategy
- DevOps: It’s Different for Big Firms