Microservices Are the Key to Flexible Architecture & Development

There’s a lot of hype swirling around the use of Microservice Architecture (MSA): how to define it exactly, and whether or not the microservices concept is the next big thing in architectural and development approaches. Is a microservice limited to a finite number of lines of code, or should its development be limited to a certain amount of time in the development lifecycle? At this point the answer to some of these questions is not clear, but what is clear is that using microservices as a software development protocol can lead to more flexible, responsive, and sustainable applications and systems. Microservices are an off shoot of service-oriented architecture (SOA), taking the SOA concept one step further by creating discrete and fine-grained services and protocols that are lightweight. That’s important in both new development and in the modernization of traditional monolithic systems that coalesce several complex business functions and workflows into a single system.

More specifically, microservices are autonomous applications and systems that have a single purpose, and that’s the key. They never have more than one purpose and that means they can be designed to perform that one service exceedingly well without the usual compromises required when developing multi-function applications. This makes them useful and beneficial in a variety of ways. For example, monolith-style systems often dictate the kind of tools required to build and maintain them. Those tools are usually lowest common denominator type tools, with the ability to accommodate several kinds of code bases and testing platforms. In a microservices application, the best tool for that specific function can be identified and used, leading to higher quality code development, testing, and deployment.

Using an MSA approach can also make it easier to maintain, sustain, and scale applications and systems. As opposed to monolithic systems, where one change can unknowingly resonate through several functions and code bases wreaking havoc, microservices allows for precise changes to a lightweight code base that is self-contained. This has benefits, including:

Flexibility: Add or remove functions as needed in near real time;
Responsiveness: Satisfy user change requests quickly and efficiently;
Maintainability: Code repair and version upgrades limited to a single service;
Scalability: Add functionality quickly and incrementally

Microservices has also introduced an important yet nuanced change to development practices that will grow over time: reusability vs. replaceability. This is a break from the customary practices around working with legacy monolith systems and more recent SOA-based systems. Because of the expense (resources, time, budget) involved in developing code a mindset developed around making code as reusable as possible. This had obvious pros – such as being able to use the same code set for multiple purposes; and cons – such as developing code that was good enough to do several things well but not one thing great. With microservices however, and the development technologies that have grown around it, it’s now more efficient and effective to rip and replace code rather than trying to reuse what exists. The discreteness of microservices insulates a service from other services allowing for quicker and “safer” development that enables rapid adaptability to changing business needs. It also has the side-benefit of constantly introducing modern code and coding techniques into a code base.

That said, microservices isn’t the answer to everything and every circumstance. One of the many reasons that monolith-style applications have endured is that while large, they are a single development footprint. That means less overhead for deployments and less coordination with other development teams. It also usually means less overhead and effort for initiating change projects, as once it’s loaded onto a developer’s machine they have access to the full application experience rather than just a slice. That’s not true of microservices, where it may require loading several discrete services to get the full feel of the application, and each microservice may (or may not) have a different deployment method. It’s incumbent on each development team to decide which approach is best for their particular situation and organization.

The biggest discussion around the evolution of microservices currently is: “how small is too small?” It’s relatively easy to identify applications that are too large and too complex for maintaining and updating efficiently. Decomposing monolithic applications into just-the-right-size microservice components is the Goldilocks question. Applications should start to resemble the makeup of modern Agile development teams – small and focused, with no redundancy of footprint or function. Another way to think about it is from a sustain vs. service perspective. The easier an application is to sustain (change, update, replace, etc.) the better the service is on the front end for the ultimate customer, at least in theory. Thinking about microservices in the context of better customer service and usability is a good rule to follow when deciding which way to go.

To be clear, a Microservice Architecture approach is an evolving practice in software development. As such, there is not – at least not yet – a standard playbook to follow when taking such an approach. What really matters though, and what can be the guiding decision point for now, is the benefits derived vs. the effort to accomplish. Staring with the conceptual, asking and answering question like what are the benefits of splitting this application in two, or three, or more parts? What modern tools can be leveraged to make a better application? What integration issues can be improved with a microservices approach? These are just a few of the considerations when considering a microservices application approach. Buzzy or not, the bottom line is that microservices as a development approach has the potential to make better applications and systems, and isn’t that what’s it all about?

Originally published in
Architecture & Governance Magazine
Read the original article here.