Editor’s note: This interview with Mark Richards was recorded for Coding Over Cocktails - a podcast by Toro Cloud.
According to Cambridge Dictionary, "evolutionary" is defined as a gradual process of change and development, whereas "revolutionary" is a complete change in a system, or bringing or causing great change.
The question that this article poses is a necessary one to define how microservices have changed and affected the way we build and design our systems.
"I think that microservices exhibit both of those", says Mark Richards, co-author of the book Fundamentals of Software Architecture and founder of the site DeveloperToArchitect.com.
Microservices are evolutionary...
"Did we evolve into this architectural style about six to seven years ago? It was eventually going to happen, [and] two things were really the catalysts for microservices." Richards says during an interview in Coding Over Cocktails, a podcast by Toro Cloud.
"The first catalyst was this whole idea of continuous deployment. We had continuous integration, and that was a good first step, but when Dave Farley and Jez Humble came out with the book Continuous Delivery, it was just remarkable. It finally gave us the answers on how to effectively deploy software." he explains.
Continuous deployment and delivery, Richards adds, allowed for developers to finally address large monolithic applications that didn’t work.
The evolution came about when developers realised that they could break up the applications into smaller, more manageable systems, which paved the way for effective deployment pipelines.
The second evolutionary catalyst Richard mentioned was Eric Evans’ concept of domain-driven design.
"I’m bold enough to say that microservices would not exist without the bounded context concept which Eric Evans drove through domain-driven design. These two [catalysts] are ‘parents’ of microservices in a way." he explains.
But, they’re also revolutionary.
"I have been doing microservices for a little over six years now, almost devoting my whole career to it at this point for the past six years - I have also seen the revolutionary aspects of microservices."
Richards explains that microservices was the very first architecture style that came out which required users to consider data as part of the architectural design.
"No other architecture style in existence has required this." Richards reveals.
The other aspect that made it revolutionary was the collaboration required for microservices to succeed.
"We’ve been trying to collaborate, not just communicate between each other, but really collaborate – working together on developing a cohesive system. Microservices requires this collaboration. Without it, things completely fall apart." he adds.
With revolution, comes resistance
In any revolution, there can be a lot of upset and collateral damage, and according to Ricrhads, users often experience the challenge of service granularity when dealing with microservices.
"How big should a service be? Our payment service, where we accept five different payment types for our processing - should that be one service or five? Should notification to our customers, which we do through SMS texting, email and even postal letters - should that be one service or three? Service granularity is hard." he states.
Apart from service granularity, Richards adds that decomposing data can also be extremely difficult, as data is, more often than not, interrelated.
"We've got foreign keys. We've got relationships between data. In microservices, we have ‘deployment hell’, where all these services depend on one another. We knocked one service out and all of a sudden, things can start breaking that we didn't even know were tied to it through workflows. If the deployments are not done correctly, it can be your worst nightmare. Service dependencies is where microservices really starts to fall apart. And these are some of the real major hurdles and challenges."
Fortunately, however, there are solutions to all of these. And in the podcast, Richards also details some of the reasons why microservices can indeed be a great fit for organisations looking to drive their digital transformation projects forward.
"So, there's so many, many good reasons why this is on the hype curve. Super high levels of scalability. Agility. One of the things that i s near and dear to my heart is architectural change. Architecting for a change. I've been touting this in conferences, in various talks, for almost 10 or 12 years about Agile architecture. And this was before microservices even existed." Richards recalls.
Coding Over Cocktails is a podcast created by Toro Cloud, a company that offers a low-code, API centric platform for application development & integration.
This podcast series tackles issues faced by enterprises as they manage the process of digital transformation, application integration, low-code application development, data management, and business process automation. It’s available for streaming in most major podcast platforms, including Spotify, Apple, Google Podcasts, SoundCloud, and Stitcher.
