As more modern businesses embrace new organizational structures like DevOps, with a goal of achieving the continuous deployment of software, SOA architectures are becoming more granular. Microservices is a term used to describe these lightweight, highly portable applications used to build larger systems. Each microservice typically runs in its own process, communicating with other microservices using a protocol, such as HTTP.
Like many newer technology industry buzzwords, it is hard to explicitly define microservices, but enough common attributes exist to provide a high-level overview. Perhaps this architectural approach makes sense for your team’s next application design?
The esteemed software architecture pundit, Martin Fowler, describes how the need for microservices grew out of the hassle of making relatively minor changes to large monolithic applications running in the Cloud. For example, a simple UI change required all the components in the application to be rebuilt and redeployed across multiple servers.
Improved scalability in a Cloud-based distributed environment is another major advantage of microservices. Older applications required all of their components to be scaled. On the other hand, software designed using microservices only needs the scaling of the most resource intensive portions of the application.
The fact that each microservice is individually deployable ultimately makes this process easier to manage for build engineers.
Being able to leverage collections of microservices is a boon for organizations looking at code reuse for quickly architecting, designing, and building a web-based application. This echoes some of the original promises of SOA – or even piecing together desktop software using components – but the improved granularity of a smaller microservice works better in this era of the Cloud.
Using microservices also makes it easier to organize an application’s architecture. Fowler notes many enterprises create teams based on the business capability for a microservice. This means each cross-functional team includes personnel responsible for the UX, database, middleware, etc.
From an organizational standpoint, this is a structure similar to the Agile Tribes concept used at the Internet music streaming company, Spotify. Fowler mentioned that companies organizing their software development teams around their chosen application architecture is another example of Conway’s Law influencing the software engineering process – a process we talked about last year.
As mentioned earlier, application design using microservices helps organizations achieve a continuous delivery model compared to older software architectures. Given a scenario where only a small portion of a microservice needs updating, it is easier to rebuild that granular piece instead of an entire application. Organizations are able to leverage automated test and build routines to streamline the entire process.
Fowler feels it is too soon to anoint microservices as the future of software development. “While our experiences so far are positive compared to monolithic applications, we’re conscious of the fact that not enough time has passed for us to make a full judgment. Often the true consequences of your architectural decisions are only evident several years after you made them,” said Fowler.
There’s no denying that microservices architecture is worthy of further analysis by your software development organization. It just may be the missing link on your path to highly scalable and easily deployable applications.
Keep returning to the Betica Blog for additional insights on the software development world. Thanks for reading!
Posted on February 17, 2017 | Categories Quality Assurance | Tags Deployment Architecture, Microservices, Quality Assurance, Software Development, Software Testing, Software Testing Laboratory