Speaking for the Dead: Are "Agile" and "Monolithic" Actually Good?

What if Agile is the product of getting bored at work, microservices are the result of us needing a challenge, and scrums are the result of an obsessive project manager? Do we all think waterfall development is a dinosaur whose extinction is deserved because of what we have been told and not because of reality? Do we think Agile is better because it simply sounds desirable?

Michael DeHann (@laserllama), creator of Ansible, spoke at the 2016 All Day DevOps conference, which espouses the benefits of DevOps, and, by association, Agile and microservices. It essentially says, “Let’s step back and evaluate the past. Maybe waterfall development and monolithic architectures are actually a good thing?”

Michael has been a software engineer and created a key tool in the IT automation toolbox - Ansible. His arguments deserve a look, because reevaluation can keep you from making mistakes and improve processes going forward.

Michael started his talk by making the point that in this day-and-age, it is waterfall vs. Agile and monolithic architecture vs. microservices. The assumption is that if you are still developing software with the waterfall method and/or developing monolithic applications, you might as well be riding a horse and buggy to work and dialing up coworkers on your rotary phone.

Throughout his talk, he asked questions to make his points, beginning with “Is big design up front bad?” -- with the conclusion, “I don’t think so.” His argument is that design and requirements at the beginning of the process enable a better production. Marketing and engineers hammered out requirements based on needs, abilities, and budgets. There was plenty of time to research and design solutions. Both sides worked together, raising questions and comments and documenting mutual agreement. This presented an accurate view of the strengths of various team members and dependencies between tasks and task orders. And, perhaps most important, engineering was engineering - they had greater responsibility and less hand holding.

Contrasting that with his view of Agile, big design up front is labeled as bad or counterproductive, engineers are viewed as interchangeable, and scope is more unpredictable. Estimates are encouraged to not be time based, which often results in a constant crunch time. Finally, meetings can consume a significant portion of your time, and often include “games reminiscent of Kindergarten, such as Fist of Five or Planning Poker.” Even in lightweight Agile systems, testing can suffer, requirements are more vague, and there is no mutual sign-off.

Michael argues that there can, in fact, be a middle ground where teams:

• Do share design
• Have an accessible, effective product owner
• Know hard requirements vs. soft requirements
• See test driven development and test automation as super important
• Understand that Agile and iterative development can be closer than we think

Agile and DevOps are also often associated with microservices vs. monolithic applications, but according to Michael, “What’s so bad about a monolith?”

Sample Microservices Diagram

An example microservices shop has 150 services, many thousands of Jenkins builds per day, 8 Amazon regions including dev, staging, and production, and thousands of EC2 instances. This can result in Jenkins configuration and security enforcement drifts, suboptimal code sharing, and DevOps writing lots of custom code to manage it.

Michael contrasts that with monoliths, which have:  

• Increased ability to develop on one laptop
• Interfaces that benefit from static typing vs design-by-contract
• Very small numbers of different server/image types in production
• Local function calls that are much faster than RPC
• Few instances sitting around with 5% utilization
• No need for “containers” to get around above utilization problem
• Greatly simplified debugging
• Easy code sharing
• Very simple version upgrades

Rather than argue that all applications should be monolithic, he makes the point that many of the concerns that resulted in microservices could be solved with improved communications. He contends that microservices are a tech solution to a people problem.

Michael concludes that labels cloud true meanings, monolithic architectures are more efficient, Agile can be less efficient, microservices attempt to solve people problems but introduce new technical and people problems, and that we should try and separate the labels from the true meaning of things. Most importantly, though, is the fact that there is something to learn from everything. So, even if you don’t agree with Michael’s conclusion, you should listen to his talk online here. You might learn an unexpected lesson.

If you missed any of the other 30-minute long presentations from 2016 All Day DevOps, they are easy to find and available free-of-charge here.  Finally, be sure to register you and the rest of your team for the 2017 All Day DevOps conference here.  This year’s event will offer 96 practitioner-led sessions (no vendor pitches allowed).  It’s all free and online on October 24th.