by Russ Miles & Sylvain Hellegouarch (Simplicity Itself), Wednesday 10th February, 2016
In the previous post I talked about why software, typically, is no friend of change. While you can certainly build software and deploy in a monolith fashionic to get some of the options to embrace change, the Microservices architectural-style is focussed on designing to respond to the very nature of any live system: change! And to do this quickly!
Because microservices are actively designed for change, engineering teams can welcome business variations in a more confident manner, increasing comprehension and trust between all the stakeholders.
In fact, I emphasise exactly this in my most recent talk on the "Technical Journey to Microservices". Microservices are most often adopted for adaptability (embracing change), speed and antifragility.
Rather than the anger and guilt that an agile team feels when "one small change" is proposed, change is embraced as a normal aspect of software research and development.
Because microservices are actively designed for change, engineering teams can welcome business variations in a more confident manner, increasing comprehension and trust between all the stakeholders.
In fact, I emphasise exactly this in my most recent talk on the "Technical Journey to Microservices". Microservices are most often adopted for adaptability (embracing change), speed and antifragility.
Rather than the anger and guilt that an agile team feels when "one small change" is proposed, change is embraced as a normal aspect of software research and development.
RSS Feed
