tiero - Fotolia
How to match microservices middleware to your mission
Microservices middleware strategies require an understanding of goals, state control and other key factors. Discover everything you should consider and how it affects your needs.
Microservices is somewhat of a recycled concept. Many experienced developers recognize that many of the goals and features of service-oriented architecture, a predecessor concept, are the same in microservices. That's also true with microservices tools. Consequently, it's important to evaluate microservices tools and missions by looking at the specific things that make microservices different from SOA.
One primary difference between microservices and SOA is that SOA incorporates complete features of discovery, security and scheduling. Due to these base features, the SOA approach naturally fits a single model that developers can deploy, secure and govern. In microservices, on the other hand, discovery, security and governance features are parts of a middleware toolkit. Therefore, it's important to design with microservices middleware.
There are two primary goals of microservices. One goal presents microservices as business components that are linked to front-end processes, like mobile app support and web front ends. This model treats microservices more like traditional SOA components. The other goal, however, aims to use microservices as small functional elements to share among many different applications, so they are less likely to cover entire business processes.
Microservices as business components
In the first of these goals, microservices function somewhat like mini-workflow processes. It's unlikely that the code is stateless, so it queues work for each microservice. It is possible, however, to pull this workflow management out of the microservice and rely on an overall service bus, which is a traditional part of an SOA implementation.
To tackle this, you can either look for service bus tools that support microservices APIs or for message-queuing and API broker tools that support microservices access. An overall bus-oriented method to microservices should help strengthen security and governance and make formal API brokerage unnecessary. This approach should be familiar to most SOA developers.
If you choose to omit the central message bus, you may want to adopt the elements of a microservices design pattern. This pattern identifies all the key components of microservices and ensures that the pieces fit in an implementation. The messaging component of this pattern is especially useful because it helps facilitate decoupled, asynchronous message flows between users and microservices or among microservices when multiple services are needed to fulfill a request. However, this type of messaging may require API brokerage or discovery.
Microservices as small functional elements
The second goal of microservices focuses on composability, scalability and distribution. These microservices are often much smaller and more likely to represent horizontal tasks rather than business or vertical features. Also, these types of microservices likely require stateless operation, which creates a need for explicit state control.
The model-view-controller (MVC) is one clear answer to the challenges presented by this second microservices mission. MVC creates a data/process model and a series of controller-built views that represent possible uses. This can be applied easily to microservices, which, in MVC, could represent abstract data elements derived on request. Nginx has considerable collateral and suggestions on the use of MVC and other open tools to build state-controlled microservices applications, including web front ends.
It's also possible to build state-controlled microservices applications by using specific state control tools. Cloud tools, like AWS Step Functions and Azure Logic Apps, provide sequencing and state control within their respective clouds. Middleware tools, like the Redis data/state caching tool, provide similar capabilities for on-premises applications and general cloud applications. Any of these options provide an assembly framework for step-wise microservices processes and maintain the data and state context of transactions through locally stateless processes.
Microservices scaling is related to state control. When multiple instances of a microservice might be used, it's necessary to distribute the work first. It's also important to maintain the transaction context over multiple messages in some way. If your business applies state control logic to its overall application, it's not difficult to extend that to multiple instances of the same microservice, but you'll still have to provide load-balancing capabilities.
There are many different load balancers available for microservices applications. Load balancers can come in the form of appliances and independent cloud-hostable components. Load balancers can even be integrated with a cloud provider, private cloud or container technology.
For application front ends hosted in public clouds, first, look at the features of the cloud provider's own technology. If that isn't suitable or if your business plans a multi-cloud deployment that will cross provider boundaries, a cloud-hosted software tool is best. Appliance-based load balancers are a good strategy for the data center. It's not a good idea to mix different types of load balancers within an application, so make sure to pick a strategy that will run wherever you plan to host something.
Making microservices middleware choices
Once your business establishes the best mission and approach for its microservices project, there are several general principles to keep in mind when you select microservices middleware. The first principle is to select middleware that fits broadly across your microservices deployment. In addition, if you have multiple missions to support, it's smart to select more generalized tools that support them all.
The second principle is to try to keep stateful and bus or queue features out of microservices. Instead, place them in the main logic that invokes the microservice. Even when the mission doesn't require it, expect microservices to evolve to a more stateless form as application and component reuse goals increase.
Microservices are a leading-edge trend, and planning for the evolution of all your business's missions is smart. It's not possible to anticipate everything, but it's a smart practice to add as much flexibility and agility as possible.
