Getting Your Microservices Strategy right!
In my article in 2015, we have touch based on the fundamentals of Micro-Services, the momentum has picked up and that warrants revisiting the approach and strategies of microservices that are transforming the landscape of the application architecture and consumption thereof redefining the design, development, data and delivery aspects even today at much more larger way. It is challenging the legacy approach of monolithic architecture by paving way for distributed, loosely coupled, inter-connected and highly scalable ecosystem of functionalities called as fine-grained services. The strategy is to move out capabilities vertically, decouple the core capability with its data and redirect all front-end applications to the new APIs, in this era of microservices…
What are Micro-services and how are they different from Containers?
Microservices, i.e. microservices architecture (MSA) is a resilient application architecture, a development / testing technique or style that structures an application as a collection of services that are isolated and loosely coupled with each other. Simply put, collection of processes, self-contained piece of business functionality with clear interfaces that are communicating over network as per the defined workflow and set goals and may contain everything from the operating system, platform, framework, runtime and dependencies, packaged together for execution.
Containers on the other hand, encapsulate discrete components of application logic, libraries, frameworks, etc provisioned only with the minimal resources needed to do their job and can run independently isolating applications from one another, without dependency on OS, platform and the underlying running infrastructure resources. Simply put, pack your code, discrete components of application logic and its dependencies into a container that can then run anywhere with the minimal resources needed to do the job.
A microservice may run in a container, but it could also run as a fully provisioned VM on cloud. Likewise, a container doesn’t have to be used for microservices, even though containers are a good way to develop and deploy them. The containerization of the applications ensures an easily distributed architecture and cloud-to-cloud portability. While running on cloud, enablement of the application to externalize APIs and microservices is the best path for applications to provide the best functionality on cloud platforms since they are autonomous and have independent ability to scale-out a specific microservice on-demand. Any e-commerce application can be broken down into microservices, key application modules such as log-in, transaction history, current inventory, viewing deals and combos or product catalog, recommendations, shopping carts, check out, payment gateways, payment receipt and finally tracking the shipments are all interconnected yet standout modules that can be developed, tested independent of each other and still respect the workflow and security of each user, product, transaction and payments.
Microservices can be implemented in different programming languages and might use different infrastructures whereas containers are independent of it. Microservices allow you to separate sensitive data and add more careful security to that data. Furthermore, by ensuring all traffic between microservices is secured, a microservices approach could make it harder to exploit a break-in.
Types of Microservices...
Largely, microservices are of two types, stateful and stateless.
The Stateful microservices save session information within the code and the runtime cache. When a stateful service terminates it has to save its state. Stateful microservices possess saved data in a database that they read from and write to directly. Note that well-behaved stateful microservices don’t tend to share the databases with other microservices because that makes it hard to maintain decoupling and well-defined interfaces. Typically, these stateful services offload persistence to host its running on thus in-adversely locks itself to the same host to re-launch the service and maintain the stickiness to session. Many use Technologies, such as PortWorx, Flocker and Docker volume plugins, address this problem by creating a separate persistence layer that’s not host-dependent.
Stateless microservices on the other hand do not retain the session state between requests. They do not link requests in the way that stateful microservices do. They handle requests and return responses. Everything they need to know is supplied on the request and once the request is complete, they forget it. Stateless microservices are often used for transactions that return specific results and run only as they are required to produce those results. Stateless services can also scale because any service instance can run a request and get the same result.
The Layered Approach
Since microservices are components of a single application workflow of functionalities, ecosystem of microservices must be integrated and tightly coupled with each other. The layered approach of this integration between core services, composite services and edge services (Read, API services) must work in tandem and provide individual component scalability and still preserve granular capabilities thereof.
Overall, Service boundaries are closely tied to business demands and hierarchy boundaries of the application workflow / logic and times span across entities and stakeholder components running across multiple systems and locations, yet respect service interactions, APIs and data structure protocols thereof. In principle every microservice architecture must strive to keep things as straightforward as possible to avoid tight coupling of the components. In some cases, you might be using an event-driven architecture with asynchronous message-based communications. But then ayou should look into basic message queue services like RabbitMQ and avoid adding complexity to the messages transmitted over the network and maintain consistency and integrity of data that serves multiple microservices.
In short, having a microservice architecture makes developing and maintaining each business capability easier. But things become more complicated when you look at all the services together and how they need to interact to complete actions. The modern microservices system is distributed with multiple points of failure and by principle of design, one need to cater for that and take in account not only issues where a service is not responding, but also be able to deal with slower network responses, latencies from external edge services, clean recovery from a failure can become tricky at times as you need to make sure that services that get back up and running do not get flooded by pending messages or stale requests etc.
Building microservices is a journey rather than the immediate goal, it is recommended to start small to understand the technical requirements of a distributed system, how to fail gracefully and even scale individual components at ease. Once this is mastered one can gradually increase the scope and complexities adding more and more services with expertise and experience.
In Summary, Microservices is a strategy that is beneficial to both raw technical code development process, and overall business organization strategy. Microservices help organize development teams into units that focus on developing and owning specific business functions to maintain granular focus that improves the overall business communication and efficiency.
The key to digital transformation success is finding ways to access the mission-critical data stored on legacy systems and putting it to work. Microservices, with APIs, make complex development easier. Legacy Monolith application architecture and microservices architecture adoption is not a simple binary choice. Both have fuzzy definitions, different criteria and goals to achieve that tells us that many systems might still be on a boundary area and few might not even fit into either category. Most of us, including me, keep talking about microservices in contrast to monoliths because it makes sense to acknowledge that there are systems out there that don't fit comfortably into either category or might be in evolving stage to fit into one. Let’s think of monoliths and microservices as two regions in the space of architectures with interesting characteristics that are useful to discuss as viable options wrt to goals they are set forth to achieve but no sensible enough to treat them as a comprehensive partitioning of the architectural space. What Say?
Oct 2019. Compilation from various publicly available internet sources, authors views are personal.