The Fascinating World of DevOps: A Phenomenon That Has Changed and is Changing How Software is Built and Delivered!
Photo Credits: https://www.flickr.com/photos/mattmflickr/7461949414

The Fascinating World of DevOps: A Phenomenon That Has Changed and is Changing How Software is Built and Delivered!

Everyone’s talking about DevOps as a growing movement in software. For those of you who are not familiar, here’s a Wiki kind of definition (by me, as I understand it, after probing a few folks) – the DevOps culture narrows the chasm between development and operations, as it relates to software, with a goal to enable faster and efficient software delivery.

Emergence of DevOps as a New Approach to Software Development

All of you are familiar with the SDLC or software development lifecycle. Code – Build – Test – Package – Release – Configure – Monitor. Each stage of the software lifecycle will require a certain set of tools to execute that cycle flawlessly.

Development and operations sides were two different functions within the IT organization before the evolution of DevOps. Operations mostly dealt with compute, hardware, network requirements, and security policies, while software development focused on the building and managing applications. But Development had to interact and conflict with Operations to make software happen. This overhead would usually derail or delay software development efforts.

With the emergence of this new type of technology stack however, developers now have access to tools that will automate a ton of operative behavior, allowing them to focus on the core, which is building and managing the application and its functionality. Result – faster, better, and more software to simplify our lives.

The Interlinkage Between Agile and DevOps: Tracing the Evolution and Reason for DevOps

In the fascinating world of software, there are several “isms”, activities, paradigms, frameworks, disciplines, standards, and of course, tool sets. Core activities begin with gathering the requirements, designing and building to them, testing and then monitoring them.

You could use different models or paradigms such as traditional software engineering, waterfall, agile, or lean with methodologies such as SCRUM or Kanban. And of course, you could pick from a large stack of tools to undertake software delivery.

But let’s talk a little bit here about why DevOps at all? Why was there a need to automate some of the software development operational functionality? It all began with a need for agility and flexibility in software development. And why a need for agility? Because quality software was needed faster, and hence it needed to be released faster, reliably faster, to deliver the value to customer who is demanding it.

Consider mobile apps, and how fast they need to be released to compete for a customer's mindshare to ensure optimal downloads? Ubers, Snapchats, Facebooks, Twitters, and many many many more need to release new features @ the speed of light to keep a tab on that mindshare. Now do the math!

Developers started using continuous integration approaches to achieve continuous delivery of this type software. Today, in some sense, DevOps is powering or accelerating THAT continuous delivery with an ecosystem of collaboration and automation tools, makes sense?

Making a Case for DevOps with Continuous Delivery for Any Time, Any Device Business Applications with the DevOps Ecosystem

As mentioned, applications need to move at the speed of light. And, as we move beyond mobile to wearables, and other IoT devices, these applications need to be even more uber fast. From simple transaction centric applications to innovative, early stage idea driven apps, the DevOps philosophy can cover the entire spectrum with its flexible ecosystem.

New Relic has a DevOps  tool set guide that outlines this ecosystem brilliantly. From OS, infrastructure, and virtualization layers to containerization, database, configuration, test, build, delivery, monitoring, and optimization, there’s a large DevOps tool network to tap into.

Depending on the software and its scale, a combination of these tools could be used with a team that understands how to use these tools, and/or with an integration partner who is familiar with the stacks. It is clear that to solve complex software build problems, a single tool will not be sufficient. And your software teams will have to intelligently mix ‘n’ match the DevOps stack.

If you've any interesting DevOps stories, share here....

Have Fun!



















要查看或添加评论,请登录

Padmini Murthy的更多文章

社区洞察

其他会员也浏览了