Question

At the risk of having this question closed as too broad, would like to know if a microservices-based application/architecture could be delivered with a traditional waterfall development methodology/teams where development team builds, test and hands over the code to operations?

Vice versa, a devops setup/team could also deliver a monolithic application, instead of a microservices-based application.

Often devops, microservices and cloud are lump together -- am wondering decomposing them makes sense, even at all.

Was it helpful?

Solution

No. These are orthogonal.

Traditional waterfall development still works as well as it ever did. It's strength simply doesn't lie in embracing change. In fact waterfall works well when change is something you need to resist. When your requirements are stable and reliability is critical, waterfall still stands up well.

DevOps certainly can support that. Continuous Integration doesn't preclude waterfall. Automated deployments don't preclude waterfall. No, waterfall is about thinking deeply about a problem, solving as many of it's issues in the planing phase as you can, and bending reality to fit a vision. For that to work you have to really know what you're doing beforehand. Getting DevOps support doesn't make you agile, force you to use microservices, or the cloud. It only provides capabilities that frankly any software team could use.

OTHER TIPS

If there is a problem I don't think it lies with the microservices themselves but the orchestration of them.

You can deploy individual microservices via CI/CD or a Ops team as you like. But much of what makes up a microservice based solution is the communication between microservices, either via queues or direct calls.

Managing the configuration of that messaging layer synchronised with the deployment of microservices is a challenge and you need to be able to react quickly, which plays into the CI story

Licensed under: CC-BY-SA with attribution
scroll top