Microservices in Software Architecture

Software value can take many forms but the ability to respond quickly and flexibly to new business challenges separates “just so” software architecture from high-value software architecture.  To this end, over the past 20 years, we have seen many steps down the path from monolithic applications to client-server to service-oriented architectures (SOA).  Now, organizations seeking to maximize the business value of their software architectures are adopting microservices architectures.

Microservices, as the name suggests, should represent the smallest unit of functionality that aligns to a core business capability.

That’s not to say that each business process or transaction is a single microservice but rather that business processes and transactions are “composed” using microservices.  Sounds like SOA?  Well, yes, it did to me too, at first.  The major difference, I think, is that this time the industry has got out ahead of the curve, learned from the challenges that we all had/have with SOA and built the necessary infrastructure to standardize and support the microservices from the beginning.  For example:

• Microservices API’s are standardized
• Microservices are natively able to communicate with each other through industry-wide adoption of pre-existing standards like HTTP and JSON.
• Microservices can be formally defined using standards like the “Restful API Modelling Language” (RAML) so that developers reusing the microservices can depend on the functionality contained within the microservice and resist the urge to rewrite their own version “just in case.”  Indeed, a collaboration hub like Mulesoft’s Anypoint Exchange encourages merit-based reuse of microservices by capturing the reviews and ratings of other developers who have used that microservice.
• Microservices can be implemented in different programming languages.
• Tools are available to manage the complexity of microservices e.g. Mulesoft Anypoint Platform.

This last bullet hints at some of the challenges of a microservice architecture.  Development needs to be highly automated with automated deployment to keep track of all the microservices that need to be composed into a particular application and continuous integration.  However, the adoption of a microservices approach also requires strong discipline from developers and the devops team.  Fortunately, the “small is beautiful” nature of most microservices means that the development teams can (and should) be small so team discipline and communication can be maximized.

Implementating a microservices architecture is not something to try on your own for the first time.

There a number of companies that have already developed strong experience in architecting and development microservices including our own Spitfire Group who have done a number of implementations including a back-office upgrade for a Real Estate firm.

I believe that organizations should seriously consider enhancing the business value of their software by implementing microservices architecture for their “leading edge” products or services.  By “Leading edge,” I mean those software-based products or services that are most subject to change as the business environment changes.  They are probably customer-facing applications which have to respond to competitive changes in weeks not months.  They are probably going to be applications whose software value rests on they’re being fit for purpose all the time.

This post was originally published at https://www.softwarevalue.com/insights/blog/posts/2017/january/microservices-in-software-architecture/