May 7, 2019
In the world of “one-up” IT, it seems like almost everyone is wanting to understand how to integrate microservices into their solution architecture. And rightly so. The benefits of using microservices are numerous and varied. Let’s examine some of these positives and consider if they can help you solve some of the problems that you are facing today.
Agile scalability
In a traditional Web application, you can author scaling rules such that when a certain request count is reached, additional instances of the entire Web application can be automatically spun up on newly (and dynamically) allocated Web servers. However, you do not have any control over which specific area of that Web application needs to be scaled. Do you need to scale the entire Web app, or just a part of it?
For instance, there could be a queued backup of HTTP requests waiting to post values into a payment system. Perhaps there is a rather extensive validation algorithm that needs to be processed before the payment can be finalized. This small yet often-accessed part of the Web app could thus become a bottleneck. In traditional scaling of a Web app, to scale up new Web servers would be dynamically provisioned, the entire Web app will be loaded onto those servers, and the process will continue.
A more efficient architecture design would be to scale up just the payment service on its own. Not only would that be quicker (since you are not provisioning new versions of the complete Web app), but it uses less resources (since you are only scaling a piece of the solution).
To further save in resources and time, add in a cloud provider to leverage its container technology to host microservices and other cloud services to help with innovation, scalability, provide resource optimization.
Focused development
The goal of “micro” service is to do one thing only but do it very well to meet the needs of the business. This typically means a small team, a finite and very focused development scope, and functionality to design and implement the microservice very well. Services should be “slim” and keenly targeted and no overlapping functionality with other supporting microservices. When this is accomplished, consumers of that service can thus focus on using that service and could care less about its implementation or how the microservice accomplishes its goals.
Keeping development focused at the microservice level gives teams the chance to experiment. It is very very easy for multiple versions of a microservice to co-exist for A/B testing. You can route certain percentages of requests to the different versions, assess /compare the results, and then make design decisions. This can be done multiple times per day if necessary. This ability to experiment is not possible with anything larger than a microservice.
When decomposing the monolith down to microservices, we are now free to implement each microservice in the most effective way. This may mean using a different version of Java or NodeJs than what the other microservices are using. Or you can go all the way in on polyglot development and allow teams to choose the specific technology (e.g. Java, .NET, Go, etc.) they want for their given service.
DevOps Integration
With all these independent teams developing non-overlapping and focused microservices, how to we integrate this all together into a viable solution? The DevOps model can serve as a facilitator. Both microservices and DevOps offer an agile model that is a key component of the microservices model. Well-designed microservices follow this model to assist in development, speed, and agility – yielding smaller and more frequent releases. Continuous Integration (CI) is all about integrating frequent releases and thus is a perfect platform for a microservices release model. This model encompasses shorter build, test, and deployment cycles that fuel the ability to quickly roll out new versions of a service.
Microservices bring additional productivity to DevOps by embracing a shared toolset, which can be used for both development and operations. That common toolset establishes shared terminology, as well as processes for requirements, dependencies, and problems. This encourages development and operations teams to work better with one another, allowing those entities to work jointly on a problem to successfully fix a build configuration or a build script.
DevOps and microservices work better when applied together. This is especially true when DevOps automation is added to the equation, ensuring you get the same process followed exactly each time through the CI/CD pipeline. Automation also cuts down significantly on the time to process the new code/build/test/deploy cycle.
Standardized Communication
Microservices communicate using common mechanisms, such as RPC (such as REST or SOAP), or messaging. This promotes easy interaction with them. With RPC, a service makes a synchronous request to another service, then waits for that called service to respond back. While it is a simpler programming model due to the logic of the caller continuing immediately upon return from the RPC call, it can also have blocking/waiting issues while calls are waiting to complete.
If asynchronous communication is required to avoid blocking calls, then messaging can be used. Here a message is “published” into a message broker. That broker takes the message and forwards it on towards “subscriber” receivers who have registered to be notified if this message is published. The publisher (calling code) can then return immediately after publishing the message to the broker and does not have to wait for the message to process.
Evolutionary Architecture
One of the big architectural benefits of microservices is how well microservices support the ability to implement an “evolutionary” architecture. This allows you to continually innovate and incrementally change without incurring any significant cost, risk and change to those services that are running on it.
The advantages of microservices
These are the primary positives of microservices. Together they form a very efficient and streamlined agile model for development. However, microservices are not a technology to blindly make everything better. There is overhead in developing them, and it is a more complex model in certain ways than a monolithic architecture. Due to this complexity, we must use the Agile development method, and DevOps automation.