What are microservices?
1. What are microservices?
Today, many new enterprise applications are being designed using a microservices architecture. What are microservices? First, we should understand how applications were traditionally designed. Early enterprise applications were developed as large, self-contained applications. These applications included the user interface, business logic, and data access code, with data persisted in a large, relational database. These applications were designed to handle many tasks, and the codebase was necessarily complex. Each major change to the application tended to make the codebase even more complex. And, because the code was all in a single application, the application code was often tightly coupled. This interdependent code was hard to maintain, making it difficult to fix bugs without introducing new ones. We now call these monolithic applications, or monoliths. Service-Oriented Architecture, or SOA, was an attempt to solve the challenges of monolithic applications. SOA is an architectural style that focuses on building reusable software components called services. Each service in a service-oriented architecture should execute a discrete business function, ...and communication between services was implemented using messaging over defined service interfaces. SOA was typically implemented at an enterprise level. Organizations would map business activities into services, and mandate interoperability and discoverability standards for their services. SOA did provide tangible benefits, but it typically produced mixed results. One clear benefit was that services were smaller and more loosely coupled than in large monolithic applications. Smaller services often led to smaller development teams focused on a single service and a smaller problem domain, which could improve efficiency. Service reuse was also a large focus of SOA. Applications were created by combining services. The messages between services were handled by a messaging middleware component called the Enterprise Service Bus, or ESB. By managing connectivity, security, and message routing and transformation, the ESB enabled applications to be integrated, even for applications outside the organization. Applications would connect to the ESB, and the ESB would transform protocols, route messages between services, and transform data. Though SOA reduced complexity in the service code, the complexity was typically shifted to ESB integrations. ESB integrations became the bottleneck in successfully launching and updating applications. The ESB was typically managed by a central team, and ESB integration work could face significant delays because all application and service teams needed ESB work. Changing an integration for one application might destabilize other applications using the integration. Even updates to the ESB software itself could break existing integrations, so ESB updates required significant testing. Microservices are an alternative, decentralized approach to decomposing applications into services. Microservices are separate services, limited in scope. In this example, each of the business domains (orders, products, and reviews) is in its own microservice with its own database. A microservice specifies an interface, typically an API, that is used by other services when calling the operations of the microservice. The separation of microservices tends to lead to loose coupling between the microservices. Loosely coupled services are easier to maintain, update, and deploy. When you're starting to design a new application, you may decide to start with microservices instead of a monolith. One of the most difficult parts of architecting a new microservices application is designing the service boundaries. If you're designing an application and do not have expertise in the problem domain, choosing the separate services to create might be difficult. If you start with a monolithic application, you can build your application before you fully understand how to separate the services. You can migrate to a microservices architecture later as you gain more experience with the problem domain. It's easier to deliver microservices in an agile fashion than it is to deliver monoliths. If you require the ability to quickly release changes to your services, it probably makes sense to start with microservices. If you plan to grow the size of your team, microservices allow new team members to focus on smaller parts of the overall application. Team members aren't required to learn a large monolithic codebase. A microservices application provides natural service boundaries that allow for smaller teams, with each team having reduced scope. When starting with a monolith, design your application to be modular so it's easier to migrate to microservices in the future.2. Let's practice!
Create Your Free Account
or
By continuing, you accept our Terms of Use, our Privacy Policy and that your data is stored in the USA.