Before moving to Microservices, it is important to understand what Service-oriented architecture (SOA) is. SOA is the base on which Microservices are built. As the name suggests, SOA is about services. With SOA, we try to visualize and design the application as a combination of services that can talk to each other and to the end user, and fulfill the user's requirements.

If we go back to our Employee Management System example, we can try to visualize the application as a set of different services:

• Employee Data Management
• Salary Management
• Project Data Management
• Attendance and Leave Management
• Reporting Management

Based on our needs, we can divide the application into various services.

The following diagram should help us to visualize our application:

Again, we do not need to get into complex decisions at this point, such as whether we should deploy these services as a single application or keep the data in a single database. Instead, we would like to emphasize the core idea in this section. The base of SOA is trying to think and visualize your application as a set of different services rather than a single, monolith deliverable.

Why does breaking the application into services help? A simple example is when we need to make changes to the code for salaries, the developer does not need to worry about what is happening in Employee-, project-, or attendance-related code. Also, if we were to get an error while generating a report for a manager, we would know we need to start looking for a problem in the reporting service. While testing, we will focus on only one aspect of the system. So the code becomes easy to manage and maintain.

Once we understand SOA and start to think of our application as a group of services, we can take the next step and move toward a Microservices-based architecture, which we'll discuss in the next section.