• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • paul wheaton
  • Jeanne Boyarsky
  • Ron McLeod
Sheriffs:
  • Paul Clapham
  • Liutauras Vilda
  • Devaka Cooray
Saloon Keepers:
  • Tim Holloway
  • Roland Mueller
Bartenders:

How DevOps is different from the Agile methodology

 
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
What is DevOps?

DevOps is the process of incorporating the culture and set of practices to achieve faster delivery, quicker automation, agility, improve security and serve better. It collaborates a smooth flow between the IT operations team and the development team to deploy code quicker, automate the test and deliver results which is a continuous process. By adopting DevOps organizations progress through faster delivery, reaching more customers, gain a better understanding of the complexity of an application, get quicker feedbacks which helps them to stand firm in the market.

Deep dive into the world of DevOps

DevOps is more of a culture. Through DevOps there is scope for continuous improvement, handling the issues when the software development team and operations team are in isolation. DevOps improves efficiency, uniting agility, and helps to boost productivity to help deliver faster both for the business and the end users. Some of the benefits of DevOps include flexibility, accuracy and fast delivery of software releases, the higher scope of automation, higher trust, handling complex situations and coming up with ideal solutions.  

When did the concept of DevOps evolve?

How and when did DevOps appear?

The concept of DevOps was known in 2008 when there existed utter chaos between the development and the IT operations team. DevOps evolved to provide an adequate solution to the traditional software development process. When the teams were in isolation, they faced issues which could not help achieve the desired results gaining unhappy customers and incomplete releases.  

Why is DevOps gaining immense popularity?
DevOps is widely accepted IT practices across organizations and development and IT operation professionals. DevOps stresses on the concept of improved communication among the teams and departments for better collaboration.  

What are the advantages of DevOps?

Organizations are embracing the change to incorporate DevOps as a part of their work culture to improve collaboration, streamline and improve efficiency by simplifying their work. DevOps works on a cross functioning method which ensures that it delivers in the quickest frame of time, enhances flexibility and security. Let’s see some of the technical advantages of DevOps:

Advantages of DevOps over Agile

Lean culture, continuous delivery Infrastructure as a code.
Improved project visibility.
Ability to manage the changing priorities
Higher security and flexibility
Improved customer satisfaction
Faster deployment and quick delivery to markets.
Stable environment with clear goals.
Seamless operations
Improved  communication and productivity.
Less risk
On time release
Easy identification of bottlenecks.
Higher market speed
Increased number of conversions
Increased Customer satisfaction
Environment stability and better working environment
Time availability
Steady software delivery
DevOps creates an environment which has more scope for testing, continuous developing, deploying and delivering or releasing software at a rapid rate. In DevOps, the IT operations team has complete tracking of the developers progress. In DevOps, there is less risk of project failure as there is disaster recovery and there are transparent inputs from the developers.

The development and the Operations team interact on a regular basis to monitor the progress that caters to the customer and business needs. DevOps uses tools such as Application Performance Monitoring tools to proactively know if there are any chances of a project to fail.  

How DevOps is different from the Agile methodology

What’s Agile Methodology?

AGILE methodology practices simultaneous iterations of testing and development activities of an SDLC.

The Agile SDLC focuses on its core values such as:

Individual and management interactions of the task assigned and achieved.
Agile focuses much on the process rather than the comprehensive documentation
Involves the client at all stages of the product development.
Responds to change.
Get ahead in your career by learning Agile through Mindmajix Agile Training.
Key takeaways from Agile methodology:
Agile methodology has the iterative approach to build a software product.
The entire agile divides the work into manageable chunks of achievable tasks.
The client is often involved as a part of the product development. It helps the teamwork in the right direction.
For smaller projects implementing agile and estimating results is accurate. While in the case of big projects we cannot exactly convey the time for development.
There is scope to identify the errors at any stage of the project.
There is a short release every 2-4 weeks called sprints.
Agile does not give much importance to documentation.
At the end of every iteration, testing is conducted to ensure quality.  Regression testing is done to ensure the stability of the application.
The prioritized product backlog tasks are divided based on priorities. At the end of each iteration, the release is deployed to the production environment.
At the end of each sprint, User acceptance (UAT) is done.
Since Agile is based on team involvement, there is more scope for regular interactions between testing and development.
A burndown chart is prepared.  
Agile is the most implemented and widely adopted SDLC for any product development. It’s one of the most efficient software development approaches to achieve quality software. Agile has proved successful by improving user experience and reaching goals by quickly delivering through its iteration process.

But DevOps has become more popular due to continuous testing, integration, development and deployment practices. While agile and DevOps both have their strengths and complement each other, DevOps is kind of an extension to Agile. DevOps implements principles and practices of Agile to stand successfully. Agile is successful without DevOps but can bridge the gap when accompanied by DevOps practices. While Agile is simply understood as scrum and continuous testing and deployment as DevOps which is not necessarily true. Let’s discuss the relationship between Agile and DevOps.

Some main reasons why organizations are adopting DevOps
It drives productivity
Flexible to accommodate change
Accelerating product development
Agile is in the middle of Lean Startup and DevOps.
Difference between Agile and DevOps?
Difference between Agile and DevOps

While Agile is the process of software development, while Devops, on the other hand, is about continuous software deployment and its related activities. So let’s have a look at some of the practices.

What makes DevOps Effecient

Planning for the Unplanned work:
In the DevOps team, individuals following Agile admit that agile is used to monitor the progress of the work. Tasks such as what has been assigned and what’s the release update etc can be planned. However activities such as security, performance can be unexpected events which need immediate attention. Since Agile is based on the sprint and product backlog concept teams cannot wait for the next iteration hence organizations are keen on adopting DevOps as it's an infinite loop which makes tracking easy.  Some of these lightweight scrum practices make a huge impact.

Speed vs Risk:

Teams  which implement Agile no matter with or without DevOps need to remember that the basis for the change has to be strong.  The team has to have sound knowledge and clear understanding of the framework and has to be incorporated as a part of their software development.

Talking in the DevOps perspective, the team has to ensure that the newly incorporated changes must not let any risk creep in. Also, there must not exist any unseen or changes which are not transparent, as DevOps is a continuous process  and there is scope for several changes on board. Hence when implementing devOps the team must have a fair idea of the risk that exists with every change being implemented.

Agile vs Quality:

The agenda for implementing both Agile and DevOps is to help improve the efficiency in work, delivery improved applications which are free of risk. Here quality is an important attribute which is often looked over. Several IT companies believe on the fail fast concept, as it’s easier to fix the damage and costs less.  But neither of them concentrates on the quality of the product. Adhering to this principle helps only in faster deployment to production rather than maintaining the quality of the work.

Agile produces applications that fit better with the desired requirements and can adapt quickly to respond to the requirement changes

Agile creates workflow which can be adopted as per the changing needs of the project. DevOps, can help to detect early bugs and fix it for having improved quality software. Developers have to implement the coding best practices to achieve the desired quality

Agile and DevOps have the need to extend their boundaries to bridge the gaps and to prove efficient. To achieve this they must adopt the practices and principles of implementing Agile and DevOps practices, for faster development and deliver improved quality software with minimal risks.

Conclusion

Devops and Agile complement each other. DevOps does not try to remove or replace Agile, however they complements each other very well. It does this by removing the excess wastage of time, and streamlining the process so that an application moves faster from deployment to the production area quicker.  Organizations following Agile, follow the process of automated testing and delivering by only extending their boundaries till the staging area. Hence Agile and DevOps  both don’t extend their boundaries, thus remaining in their territory.
 
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I completely agree with you in your opinion "Devops and Agile complement each other. DevOps does not try to remove or replace Agile, however they complements each other very well."

Devops is the acronym of a combination of Software Development (Dev) and Information Technology Operations (Ops). DevOps is a set of software development practises utilized to shorten the development life cycle of the software being built, while maintaining and delivering the required quality, modifications and updates.

DevOps is an extension of the Agile method and emerged as a result of the drawbacks of Agile. By delivering small iterations of the software instead of a whole product and working with a cross functional team, Agile provided flexibility for development and change, but could not manage to remove the barrier between the development team and the operations team. When something went wrong, it became difficult to determine if the problem lied in development or deployment, which created issues within the teams. DevOps resulted as the means to solve this problem.

Long story short, DevOps uses Agile practices, but with the barrier between development teams and operations teams now gone. So, a cross-functional dev team will work with the ops team to produce an iteration of software. Due to its flexible nature, DevOps has multiple layers of advantages such as, https://arkenea.com/blog/benefits-of-devops/, which provide the basis of DevOps architecture in an organization, https://arkenea.com/blog/devops-architecture/

 
Saloon Keeper
Posts: 28483
210
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Historical Note.

Back in the ancient days of mainframe computers, there were 2 separate groups of programmers. The Applications Programmers were responsible for the business applications. They were a Revenue Center of sorts, and thus grudgingly blessed by the bean-counters (who nevertheless thought that untrained monkeys would be cheaper. And after all if little 10-year old Freddy could make a program that could print "hello" over and over again, how much harder could it be to create a General Ledger system?)

There was another, smaller, group, however: the Systems Programmers. Their primary function was to maintain the mainframe's Operating System, although as things got more complex, they also added networking support, backup/recovery services and general software infrastructure. Bean Counters hated them because they didn't "make money" for the company. And often just wasted time and resources sitting around idle. Like, say, the Fire Department. And they demanded higher pay because when they didn't not do their jobs, the entire group of application programmers generally ended up dead in the water. Along with the payroll system, sales reports, et cetera. Systems Programming/Tech Support was often considered part of Computer Operations, although they spent little time in the actual computer room.

And then there was the actual Computer Operations group, which were the grunts who actually operated the hardware, slapping tapes up and down on the tape drives, loading decks of cards into reader/punches, loading paper into printers and so forth. Relatively unskilled (and thus lower-paying positions) that often served as the stepping stone to a career as an applications programmer and thence, perhaps to systems programmer or management.

When PCs took  over, the job of Systems Programmer (often referred to as Technical Support, back before that meant call-center-somewhere-else) pretty much evaporated. A PC doesn't need to have its OS custom-built to get the absolute maximum value out of its hardware. A PC doesn't cost $1 million+, so if it's not powerful enough, you just buy another one. And instead of having a team of specialists finding system faults and repairing them, you were supposed to just turn them off and back on again.

Once PCs began to gang up and form server farms, it became obvious that it was much more cost-effective to have a few people run many servers that one person/computer, to the old concept of a dedicated group of grunts - the Operations Staff. However, a lot of the traditional OS support work was no longer there, so the function of Systems Programmer remained vacant. Aside from the DataBase administrator.

Over the last decade, however, the rise of complex inter-connected systems where multiple servers talk back and forth and databases are everywhere, a similar function has arised, however, which is DevOps. Like the old systems programming group, DevOps people have to know details about software and software infrastructure. They are often granted (usually limited) access to the production machines. Stuff that you want accountability for and things that you really don't want junior developers mucking around with. A good DevOps person is someone who not only ensures that the application systems are running but has a role in the selection of the hardware to run it on and the configuration of the systems services.

You don't need DevOps to run Agile, and the reverse is also true. But since DevOps is designed to make the operating environment more responsive to the needs of applications and Agile is designed to make it possible to keep applications development - and support - more flexible, they do pair well.
 
Bartender
Posts: 1159
20
Mac OS X IntelliJ IDE Oracle Spring VI Editor Tomcat Server Redhat Java Linux
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I guess the dinosaurs (mainframes) in their dinosaur pens just downsized and evolved into birds (datacenter servers) flying high in the clouds.

I'm glad to say that for the most part I managed to avoid mainframes, but here's a humorous article about those old [DevOps] VAX/VMS days; GNU Humor - the VAXORCIST

   


 
Tim Holloway
Saloon Keeper
Posts: 28483
210
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I don't know if any DEC systems were ever truly classified as mainframes. When IBM was Snow White and the other mainframe vendors were the Seven Dwarves, it was something like Burroughs, UNIVAC, NCR, Control Data Corporation, Honeywell, General Electric and RCA. But even the minicomputers had their similarities.

IBM shipped a generic OS bootstrap OS with their hardware. So the first thing that the lead system programmer had to do was map out the physical hardware that was going to be attached to it (and on what connectors), and draw up a plan for the working OS. On some on those machines, 64K was a huge amount of memory, so the customized OS had absolutely no empty space or dynamically-sized resources. So what was in the plan was all you got. This plan was then punched into a deck and fed the the IBM assembly language compiler to produce the working OS image. This process was known as System Generation or SYSGEN. With luck, this would only take 18 hours or so. With LOTS of luck, you got it all right on the first try and didn't have to make corrections and do it over. Fortunately you had plenty of time to meditate on what you had done, since the minimal OS wasn't good for much else.

Having done that, you'd re-IPL (boot) the machine and bring up the production OS. IPL typically took maybe 20 minutes or so - about the same time as logging in on Microsoft Windows with Norton Antivirus™ installed, Typically you'd leave it up and running and only do actual reboots on Sundays. Mainframe OS's weren't supposed to crash.

When new equipment was wired in, you'd have to generate a whole new nucleus. But at least at that point, you had a fully-functioning OS running so a lot of the grunt work could be done during normal business hours.

Incidentally, you can run your very own "mainframe". The Hercules mainframe emulator emulates just about any model of the IBM System/360 lineage, all the way up to the 64-bit zSeries machines. However, IBM stopped making OS source code available back around 1985 or so, so if you want to run IBM's top-of-the-line OS/MVS, the most recent version available dates to back then. Still, that's what I used in one of the largest mainframe shops in town for a number of years before departing the mainframe world and we processed something like a third of all the mortgage loans in the USA.

You can run Hercules with MVS/OS (or any of several other IBM OS's) on a $35 Raspberry Pi. Which probably has at least as much processing power as the room-filling water-chilled IBM System/370 Model 165 that was everyone's dream setup back then. And lots more RAM. You haven't lived until you've submitted JCL for a COBOL program into a (virtualized) punched-card reader.
 
Bartender
Posts: 669
15
TypeScript Fedora
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Tim Holloway wrote:this would only take 18 hours or so. With LOTS of luck, you got it all right on the first try and didn't have to make corrections and do it over


No....just no
 
Tim Holloway
Saloon Keeper
Posts: 28483
210
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
One of the reasons why Agile wasn't something people thought of back then.

When you're developing apps and you only get 1 or 2 compiles run a day because you have to hand in a deck of cards at the window and come back in 3 hours or so to check your printout bin for the results, the idea of constantly-mutating design is not something that readily comes to mind.
 
Sheriff
Posts: 28370
99
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Tim Holloway wrote:... you have to hand in a deck of cards at the window and come back in 3 hours or so to check your printout bin for the results...



Three hours? Luxury! We had to come back the next day.
 
Tim Holloway
Saloon Keeper
Posts: 28483
210
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Paul Clapham wrote:

Tim Holloway wrote:... you have to hand in a deck of cards at the window and come back in 3 hours or so to check your printout bin for the results...



Three hours? Luxury! We had to come back the next day.



Seen some of that, too.
 
Marshal
Posts: 80267
430
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Tim Holloway wrote:. . . loading decks of cards into reader/punches . . .

And I thought that meant a couple of rubbers of bridge whilst waiting for it to boot.
 
I miss the old days when I would think up a sinister scheme for world domination and you would show a little emotional support. So just look at this tiny ad:
Smokeless wood heat with a rocket mass heater
https://woodheat.net
reply
    Bookmark Topic Watch Topic
  • New Topic