Microservices are the latest, and perhaps most important, development in the evolution of application design for...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
the cloud. While early componentization or service architectures were designed to improve development efficiency and component re-use, microservices combine those benefits with the ability to optimize the cloud's fundamental resilience and performance elasticity -- provided that applications are done right.
To perfect your own strategy, first be sure to align your application needs with the advantages of microservices before you start your design. You should then accommodate primary technical requirements for microservices in your application design. And finally, make sure your application deployment model actually exploits microservices' potential.
The microservice benefit
The composability advantages of microservices are based on the fact that many business applications consist of different collections of similar functions. Developers have long recognized that by making these functions modular, they could be incorporated into multiple applications to reduce development and application lifecycle management efforts. In the past, the practice was to simply include the same component in several applications.
Service-based architecture takes this a step further by making common components into services, which are deployed independently of applications and simply called when needed. This approach eliminates the overhead associated with having multiple copies of components integrated with applications and reduces the risk of using inconsistent versions of a component. Most service-oriented deployments, including SOA, retain fairly tight coupling of components. A service is simply a hosted component.
Microservices change the relationship between services and applications to closely resemble a web model. A microservice is designed for multiple concurrent users and multiple concurrent application missions. They are also highly atomic business-valuable features that can be invoked in a very basic request/response model. Unlike SOA services, which are often designed for multi-stage transaction processing, microservices are stateless. This stateless property lets us replace them and scale in and out of them easily, posing the greatest challenge for architects and developers. Stateless components are not the rule in development.
The prescription for a microservice application is a broadly shared mixture of services designed to spread through a large resource pool (hybrid clouds, multi-cloud or large-scale public cloud) and to respond to failures or performance problems with replication and replacement of services. If this doesn't describe what you're building, stay with traditional service-oriented approaches.
Mapping microservices to functions
The first technical requirement in application architecture for microservices is to define features at a proper level of granularity. Too many microservices will kill application performance, and too few will invalidate the whole concept.
Any network-hosted service will introduce a large and variable delay in the total application response time, so creating a microservice for everything will string together many such delays and almost certainly compromise application performance. Microservices should represent business functions, not general software functions like database lookup. A query on a customer file is a reasonable microservice, where low-level RDBMS is generally not because of the service being used too often.
Most users find it easy to identify microservice candidates by starting with either enterprise architecture (EA) business process maps or software architecture UML diagrams. High-level functional pictures of applications, when viewed side by side, usually reveal similar business functions called in different applications. Properly defined EA reveals this by showing that the same information is needed in multiple business processes.
The next step is to formulate these candidate features as stateless, RESTful and web-like services. Stateless services can be replaced or replicated for load-sharing as every request is self-contained. In other words, the service does not retain anything between requests to accommodate a multi-step nature of business activity. Because business activity is naturally multi-stage, stateless services require that a stat be maintained somewhere else, and to decide where that might be is critical to microservice design.
Two options are widely used to maintain the state for microservice usage. The most popular and easiest to implement is the client-maintains-state model. This model dictates that the process invoking the microservice is designed to track the progress of multi-step processes and either pass the state of a current request to the microservice or integrate the response based on an overall context of that transaction. Any copy of the microservice can then field any request.
The other option is back-end state control. In this case, the microservice maintains a transaction's state by reading it from a file, as opposed to storing information inside that might be lost if another copy of the microservice receives a request. The microservice will still have to be able to identify the activity associated with a given request (a user ID and application ID will often serve) so a correct back-end record can be located. This approach is often used where client processes are web front ends that cannot reliably maintain processing context on their own.
If the primary advantage of microservices lies in its ability to scale with a load and replace failed instances without affecting workers, then the easiest way to lose that benefit is to fail to provide these capabilities in deployment. You have to be able to answer the question of how a given request is directed to a proper instance of a microservice, wherever it might be, and how new instances can be added and unnecessary ones can be removed without affecting users. This process is usually referred to as "load balancing" or "level 3 switching" within a data center, but when it's carried out in the cloud you have to consider the location of users and services. It's also important to remember that a load-balancing element introduces another network hop and additional processing delay.
There have been advances in building microservices in all popular programming languages. However, programming techniques at the language level are not enough to ensure that all the advantages of microservices are realized. Application design and architecture has to change, and each development team at every level must consider these changes to face the future optimally.
Discover how microservices bring agility to SOA
Learn about the IT automation tools that are taming the microservices nightmare
Put your knowledge of microservice architectures to the test