This blog covers a high-level introduction to the concept of microservices and how they differ from traditional monolithic architectures.
What are microservices?
Microservices are a way of designing software systems as a collection of independent, modular components
Each component, or microservice, is designed to perform a specific function and can be developed, deployed, and scaled independently of the others
Microservices communicate with each other through APIs, which can be accessed over a network
Why use microservices?
New instances of a microservice can be added as demand increases, rather than requiring a single, monolithic application to be scaled vertically
This can make a system more resilient, as the failure of a single component is less likely to affect the entire system
The modular nature of microservices allows for more rapid iteration and deployment of new features
This is particularly useful in fast-paced and highly dynamic environments
Allows for a more agile approach to software development: Microservices can be developed and maintained by different teams, allowing organizations to be more responsive to changing business needs
Challenges of using microservices
Testing can be more complex:
It can be more difficult to test the interactions between multiple microservices than a single, monolithic application
This may require more complex testing strategies, such as integration testing and end-to-end testing
Deployment can be more complex:
Coordinating the deployment of multiple microservices can be more complex than deploying a single application
This may require more sophisticated deployment pipelines and processes
Monitoring can be more complex:
It can be more difficult to monitor the performance and health of multiple microservices than a single application
This may require more sophisticated monitoring and alerting systems
Microservices can require more infrastructure:
A microservices architecture may require more infrastructure to support the deployment and operation of multiple microservices
This can increase the complexity and cost of operating a microservices-based system
Examples of successful microservices implementations
Netflix: Netflix has implemented a highly scalable and resilient microservices architecture to support its streaming service This has allowed Netflix to quickly roll out new features and updates to its service without disrupting the entire system
Amazon: Amazon has used microservices to enable the rapid iteration and deployment of new features for its e-commerce platform
Uber: Uber has implemented a microservices architecture to support its ride-sharing platform
Considerations for implementing microservices
Identify the appropriate granularity: Each microservice should be focused on a specific function, but it should not be so granular that it becomes difficult to maintain and scale
Design APIs carefully: The APIs that microservices use to communicate with each other should be well-designed and easy to use
Choose the right technology stack: It is important to choose the right technology stack for each microservice, based on its specific requirements and the needs of the overall system
Consider the impact on your organization: A microservices architecture may require changes to the way your organization approaches software development and operations, so it is essential to carefully consider the impact on your teams and processes
Design patterns that can be used when implementing microservices
There are several design patterns that are commonly followed when building microservices-based systems:
Single Responsibility Principle: Each microservice should be focused on a specific function and have a single responsibility. This helps to ensure that microservices are modular and easy to understand, maintain, and scale.
API Gateway: An API gateway is a microservice that acts as a reverse proxy, routing requests to the appropriate microservice and handling tasks such as authentication, rate limiting, and caching.
Service Registry: A service registry is a microservice that maintains a directory of all the other microservices in the system, allowing them to discover and communicate with each other.
Load Balancer: A load balancer is a microservice that distributes incoming requests evenly across multiple instances of a microservice, improving scalability and availability.
Circuit Breaker: A circuit breaker is a microservice that acts as a fail-safe, preventing other microservices from repeatedly attempting to call a microservice that is unavailable or experiencing errors.
Retry Pattern: The retry pattern is a technique for handling transient errors, such as temporary network outages or resource contention. It involves retrying a request to a microservice if it fails, rather than immediately returning an error to the caller.
Bulkhead: A bulkhead is a technique for isolating critical resources, such as database connections, to prevent a single resource from being overwhelmed and causing a cascading failure.
Tools that can be used for implementing microservices
There are many tools that can be used to build and operate microservices-based systems, including:
Containerization platforms: Containerization platforms, such as Docker, allow developers to package microservices and their dependencies into lightweight containers that can be easily deployed and scaled.
Cluster management platforms: Cluster management platforms, such as Kubernetes, allow organizations to automate the deployment, scaling, and management of microservices across multiple servers.
API management platforms: API management platforms, such as Kong or Tyk, provide features such as authentication, rate limiting, and caching for microservices APIs.
Service mesh platforms: Service mesh platforms, such as Istio or Linkerd, provide features such as service discovery, traffic management, and observability for microservices-based systems.
Monitoring and alerting tools: Monitoring and alerting tools, such as Prometheus or Datadog, allow organizations to monitor the performance and health of their microservices-based systems and receive alerts when issues arise.
In conclusion, microservices architecture can offer significant benefits for organizations looking to improve the scalability, resilience, and flexibility of their software systems. While it is not without its challenges, the benefits of a well-designed microservices architecture can be significant, as demonstrated by successful implementations in organizations such as Netflix, Amazon, and Uber. Suppose you are considering implementing a microservices architecture. In that case, it is important to carefully consider the granularity of your microservices, design your APIs carefully, choose the right technology stack, and consider the impact on your organization.
As part of Microservices Hackathon (a technical hackathon), was fortunate enough to work with some like minded folks and with the help of an existing project in Github, was able to create and extend a full-fledged microservices based project using Spring Boot, Spring Cloud and obviously Netflix-OSS.
The project can be found in the below link location:
Disclaimer: The chapter have been written with figures sourced from various on-line materials. I haven’t been bale to attribute these figures with source. Really apologize for this. In case anyone has any issues in me using the figures and content, please drop an email to me at tomcyjohnatgmail.com. I will make sure that the details are either attributed or the image/content removed from my blog post. Thanks in advance.
Spring Framework’s web application support is through two sub-projects namely Spring MVC and Spring Web Flow.
Spring Framework has its own MVC based web application framework in the form of Spring MVC. They conceived and developed its web framework to address some of the deficiencies and poor design consideration in other popular framework available in the market. One of the main deficiencies identified was the lack of separation of concerns like proper separation between the presentation and request handling layer and between request handling layer and the model layer. Similar to Struts, Spring MVC is a request-based web application framework. Spring MVC makes sure that all the interfaces are tightly coupled with the core Servlet API’s rather than the Spring API’s.
Spring Web Flow is one of the sub-project which aims at providing the infrastructure for developing and running web application. It tries to aid web application developers in defining appropriate navigation rules, manage navigation and conversational state as well as facilitating high level reuse and modularization.
Spring MVC as well as Spring Web Flow is a very huge topic to cover in one Chapter. There are books written only on these topics. I would cover some basic concepts of both Spring MVC and Spring Web Flow in this Chapter. The first part of this Chapter makes you walk through Spring MVC and the second part of this Chapter walks through Spring Web Flow. I will try to cover basic detail of both frameworks so that you will get a heads up on these and can start off developing using these.
Spring MVC allows you to build extensible, robust and loosely coupled MVC-based web application. With the use of the famous Model-View-Controller pattern, it inherently brings separation of the various layers in a typical web application namely business, presentation and navigation in a clear way.
We have covered MVC pattern in detail in this book, but just to refresh your mind, the responsibility of Model is to encapsulate the application data, the responsibility of View is to render the response to the user with the help from the Model object and the responsibility of Controller is to receive the request from the end user and transfer it to the back-end services which will populate the Model objects and sends the view object to the user.
Figure 14-1. Spring MVC’s fit in an enterprise application containing other layers
This is my final blog on this topic, hopefully. Part I of the blog can be found in here and Part II of this blog can be found in here.
I do at times think that my blog title itself is misleading or rather incorrect as I don’t feel that there needs to be a comparison between the two as both can exists together in one application without any issues at all. In fact if that’s the case we can use the best of both and be happy. But, there does exist this debate for a very long time and now a days Oracle also at times gives a comment to kill Spring Framework (buy and kill it to reduce competition, Oracle’s buying spree logic) and go with standards. Being the creators and maintainers of the Java language they do have the right to promote JEE but I feel they don’t have to have such a stance IMHO.
The community with full adoption of language has made it to a be a standard. Similarly when Spring Framework came in existence it was indeed helping Java developers use Java and avoid the complexities to develop enterprise application. In fact we have to give full credit to Spring Framework in keeping Java language alive and kicking. I have heard many times, even from my own managers that Java is too heavy and not that good for application development when you compare .NET. Spring to some extent have been bale to bring that easiness to it by taking the complexities away. At the moment also there might not be that much comparison between easiness with respect to .NET, but community is ready to develop applications using Java. Again for enterprise application comparing .NET and Java (JEE) is not that of a good idea because of so many reasons. Don’t want to divulge too much off the topic here.
As Kelly Tisdell mentions in his blog, JEE has definitely taken some page out of Spring Book and added onto its big Java bible and spreads a word across that “Java is standard, so migrate to JEE from Spring to be in standard”. It doesn’t say directly that stop using Spring but it has that tone in it.
Even after taking those pages, to develop an enterprise application from scratch using JEE does have its won complexities and Spring does have that easiness to it (might be subjective and debatable, but that what i feel). Most of nicer features in Spring has now crept into JEE under different names and much refined fashion (JEE have learned from mistakes and corrected it) for sure and that’s the reason developers have been prompted to think for this migration.
I wanted to put more facts in here rather than my opinions, but after so long I have indeed lost interest in filling in more details and i thought that i will just give my opinion and close this not so ending blog post. Apologies for same.
In my opinion, Spring and JEE should marry each other and an enterprise application should be developed taking into good points from both. I am in no way saying that JEE or Spring scores over the other because both are really good platforms to develop your enterprise applications.
Spring Batch is the first Java based lightweight, comprehensive framework for batch processing. Being built on top of the Spring Framework, it gives all the advantages of productive, POJO-based development approach.
Spring Batch is a lightweight, comprehensive batch framework designed to enable the development of robust batch applications vital for the daily operations of enterprise systems. Spring Batch builds upon the productivity, POJO-based development approach, and general ease of use capabilities people have come to know from the Spring Framework, while making it easy for developers to access and leverage more advanced enterprise services when necessary.
– Spring batch documentation (http://static.springsource.org/spring-batch/)
In this Chapter, we will cover Spring Batch in a comprehensive manner and aims at letting you use it in your enterprise application with less effort. The initial sections will introduce you to the core concepts on which Spring Batch is build and then later on delve deep into the various concepts in details along with appropriate code snippets.
Batch and Offline Processing
You would have heard these terms batch and offline processing for quite some time now and every time you have such requirement in your application you sit in front of the computer and start something fresh and code from scratch to realize this. With Spring Batch you now have a framework using which you can do these in a much better and cleaner manner. Before going through Spring Batch in detail, I would like to spend sometime explaining the usual business case which Spring Batch tries to achieve. Primary among these are batch and offline processing.
Batch applications needs to process high volume of business critical transactional data in an efficient manner. A typical batch program does the following:
Reads a large amount of data from database, file or queue as the case may be.
Processes the data according to the business requirement in an efficient manner.
Writes back the modified/processed data to database, file or queue as the case may be.
Batch is a group of similar or identical items and the pseudo code for this can be shown in Figure 23-1 below.
Figure 23-1. Pseudocode for a typical Batch
In most modern day applications there requires capability processing client request in offline manner. Offline processing differs from online/real-time processing with respect to the following aspects as outlined below:
Processing of processes which are long-running and which occurs beyond usual office hours
Non-interactive in nature and often requires appropriate logic capable of handling errors and taking necessary actions like restart in some cases and so forth.
Processing of processes which have large amount of data not fitting into a single transaction.
Some of the common examples of batch and offline processing are as given below, so that you can understand the use of Spring Batch and appreciate what it delivers out-of-box for you.
Large scale output jobs which need to run on a timely manner. For example; sales report spanning whole month or even whole year.
Import/export handling of data. For example; ETL (Extract-Transform-Load) jobs, data synchronization jobs etc.
Various close of business jobs. For example; sales report spanning a day, business level reporting etc.
The lack of standard, reusable batch architecture has resulted in the proliferation of many one-off, in-house solutions developed within client enterprise IT functions.
– Spring batch documentation (http://static.springsource.org/spring-batch/)
Why a framework?
So why would you need a framework for implementing batch? Why can’t we use a “for loop” for doing such batch jobs? We need to have a framework which addresses not only running a bunch of code in a loop fashion but also to have other features/capabilities/business scenarios as listed below (as detailed in Spring Batch documentation):
Commit batch processes periodically; Capability of committing the processed data at times due to various business reasons.
Staged, enterprise message-driven processing
Concurrent batch processing; parallel processing of a job
Massively parallel batch processing
Sequential processing of dependent steps with extensions to workflow-driven batches
Manual or scheduled restart after failure
Whole batch transaction: for cases with a small batch size or existing stored procedure s/scripts
Any modern application does not live in isolation. To realize the business requirements it has to communicate with customers of varied types and other applications in variety of ways. Application integration lets your application do this and in modern day applications, this is crucial for any application. Spring Integration aids in application integration that lets applications share data and services with each other making it connect with varied kind of users.
The Spring Integration is an open-source; simple integration framework that leverages the capabilities of widely adopted Spring Framework making application integration easy and simpler to implement.
This Chapter will help you start with Spring Integration and will aid you in achieving the various integration requirement in your application. I am sure after reading through this Chapter you will have one more weapon up your sleeves which you can use and reap benefits from its high level of integration capabilities.
Spring Integration Goals and Principles
Spring Integration is motivated by the following goals:
Provide a simple model for implementing complex enterprise integration solutions.
Facilitate asynchronous, message-driven behavior within a Spring-based application.
Promote intuitive, incremental adoption for existing Spring users.
Spring Integration is guided by the following principles:
Components should be loosely coupled for modularity and testability.
The framework should enforce separation of concerns between business logic and integration logic.
Extension points should be abstract in nature but within well-defined boundaries to promote reuse and portability.
The goals and principles of Spring Integration is as quoted in the Spring Integration Reference Manual.
Spring Integration Benefits
Spring Integration benefits can be summarized as follows:
Loose coupling between components – brings about development of small and focused components that caters to specific role and responsibility. This eases testing and promotes reuse largely.
Helps to separate integration and processing logic – Spring Integration pitches-in, handling message routing, transformation etc. and eases the application developer from this. Due to high level of configuration based integration style, easily processing can be switched between synchronous and asynchronous with no change in the code that is handy in this ever-changing business application scenario.
Promotes Event-driven architecture – No hard coded process flows and capability to easily change and expend these flows according to application requirement. Single word that can be used is adaptability.
Enterprise Integration Pattern (EIP)
Enterprise Integration Patterns is a book by Gregor Hohpe and Bobby Woolf and describes a number of design patterns for the use of enterprise application integration and message-oriented middleware. Enterprise Integration Patterns can be implemented without coding using Spring Integration or Apache Camel.
Enterprise application integration is an integration framework composed of a collection of technologies and services, which form a middleware to enable integration of systems and applications across the enterprise.
Spring Integration brings the power of Dependency Injection (DI) that Spring Framework is well known for and EIP patterns implementation together to nicely manage the resources and lets you focus on business logic rather than messaging infrastructure code.
Spring Integration Namespaces
For easing the various integration style configurations, Spring Integration has dedicated namespaces for each of them. Table 22-1 gives details of Spring Integration namespace in a tabular form for easy reading and understanding.
Defines the configuration elements for Spring Integration’s HttpInvoker adapters. NOTE: The http-invoker support is deprecated as of 2.0.x. It is recommended to use the REST-based HTTP adapters instead.
The point that i burst outlaughing when the author stated as below:-
…… Java EE 5 took a few pages out of Spring’s book and simplified the development of enterprise components with…….
Yes, JEE sure did take some very crucial and important pages out of Spring book and because of which it is becoming superior day-by-day if not by huge margin. Spring with full support from its community is not far behind and with foundation in place, its building up components one after another. Its also adding in more and more support for open source libraries with ever growing sub-projects under the Spring Framework umbrella.
Also now its is slowly becoming a norm when considering a new open source for development to see how strongly it can be integrated into Spring and how seamless Spring configurations can be used. In my web service framework comparison, you wouldn’t believe, this was considered as one of the requirements and it will be a bonus for any open source to state that “they can be integrated into Spring” with some few lines of Java or XML configuration.
Spring has an edge by keeping it open for good open source libraries to plug on at any time and replace these libraries with a new one by mere configurations (at-least theoretically possible… :)). Java theoretically is “Write once run anywhere”, but is it truly that easy for a a production application to move from one environment to a new one… Hmmm… I don’t think so… 🙂
I am sort of exhausted already writing this blog. I will have to put you all in some suspense and put everything else that i plan to write in a new blog part. Hold on tight and i am sure i wouldn’t make you unhappy. Expect third part in another 3 days time. Its weekend here and i am really looking forward to it in a big way.