微服务架构定义

Microservices Architecture – The Definitive Guide | LeanIX

Get to know everything about what Microservices Architecture is, what the key benefits are, and what the differences between Microservices and SOA, Monolithic or API are.

Shortcuts

1. Introduction to Microservices
2. What is Microservices Architecture?
3. How do Microservices work?
4. What are the key benefits of a Microservices Architecture?
5. How do I get started with a Microservices Architecture?
6. Examples of Microservices Architecture
7. What's the difference between Microservices Architecture and SOA?
8. What's the difference between Microservices and Monolithic Architecture?
9. What's the difference between Microservices Architecture and an API?
10. Microservices and Kubernetes governance
11. Conclusion

Introduction to Microservices

In recent years, there’s been quite a buzz around so-called microservices, also known as microservices architecture. And this truly doesn’t come as a surprise. With software applications becoming increasingly complex, they have also become bulkier and more difficult to manage, update, and maintain.

Microservices architecture is a relatively new software development approach that addresses this problem by splitting up complex software into independent building blocks or services. These modular services can be deployed and managed individually, making large applications more robust to change.

Microservices as an architectural style dates back to 2005 when Peter Rodgers, the originator of Resource Oriented Computing, first coined the term “Micro-Web-Services”. In an attempt to create a more flexible and service-oriented software architecture, he successfully outlined the principles of a well-designed microservices platform. Two years later, software architect Juval Löwy expanded on the idea of a granular use of services and inspired several expert-led case studies with promising outcomes.

Today, microservices architecture is not only considered a hot topic but the future of efficient software development and maintenance.

What is Microservices Architecture?

Microservices architecture describes a particular style in which software applications are designed. In contrast to traditional architectural styles that aim to build software like a single unit, microservices architecture is based on a modular approach. Thus, applications are developed as suites consisting of multiple microservices that can be independently deployed and managed.

But what are microservices exactly? Even though there is no clear definition for microservices per se, there are certain characteristics that are associated with this revolutionary software development approach.

One of the main characteristics is the way the architectural style componentizes a complex application. The software is broken down into multiple components that are built as independently replaceable and upgradeable services. These services can be defined as processes that often communicate over a network using protocols that are technology-agnostic.

Microservices are also built to suit business capabilities. And since they are decentralized and small in size, they offer a lot of flexibility when it comes to programming languages, hardware, and software environment.

How do Microservices work?

The idea of loosely coupled services that are highly maintainable and testable sounds intriguing to companies that face IT challenges due to complex applications. But before uprooting the system in place, it is vital to understand how microservices actually work. In order to create a functioning modular architecture, a business needs to first identify its capabilities and define the services that will run independently from each other.

A microservice architecture diagram is needed to expose dependencies that would inhibit the flexibility of each service. It is critical to ensure that an error in an individual part wouldn’t impact the whole system.

But even though microservices are designed to work independently, they sometimes still have dependencies on other microservices and need to communicate with each other. This communication occurs through the use of APIs (Application Programming Interfaces); synchronous or asynchronous protocols like HTTP/REST or AMQP. Ideally, each microservice has its own database in order to decentralize responsibility and manage updates individually. When using the “Database per Service” pattern, a saga, which is a transaction that spans multiple services, is put in place in order to maintain data consistency.

However, it is not uncommon that each microservice develops more and more service dependencies over time. This is a normal occurrence once services begin to grow and start affecting the number of instances, locations, and protocols.

API gateways help avoid problems that arise from these changes. And this is how it works: An API gateway takes all API requests and then routes every single one to the most appropriate microservice. It also invokes backend services and aggregates the results to identify the best path. It serves as the entry point for every request, organizes all input, and creates a simplified user experience.

What are the key benefits of a Microservices Architecture?

There are a number of benefits microservices can offer a company. After all, big data applications are all the rage and call for a software architecture that best suits the needs of business operations, the developing team, and the end-user.

The ten main advantages of a microservices architecture are outlined below:

1. Access: Since microservices are deployed separately and communicate through API, code and applications become more accessible for employees outside of development. The modular design approach also helps to understand the different services a company offers including their specific functions without having to worry about other parts.

2. Error management: If a microservices architecture is implemented correctly, finding and isolating bugs becomes much easier. Whenever an error occurs, developers know exactly where to look, which saves valuable time and effort. And fixing only one independently run service means that other code won’t be affected and there is no need to deploy the whole application.

3. Maintenance: This benefit goes hand in hand with the previous two. Microservices architecture facilitates the maintenance and management of the services. In fact, each service can be managed by a different team since it stands for a unique process with its own database. Plus, individual updates can be performed without bringing the whole software system to a halt.

4. Adaptability: Microservices are only loosely coupled and have a standardized way of communicating with each other. But since they’re built separately, they don’t have to share the same programming language or technology. This means that each service can be designed in a way that best corresponds to the functions it needs to perform.

5. Evolutionary: Business requirements are subject to change which creates a need to add new features to offered services. In traditional architectural approaches that treat software as a whole, this means meddling in the entire business logic and potentially breaking existing features. With its modular approach, microservices architecture avoids this problem.

6. Scalability: One of the main benefits that microservices have to offer is their ability to be scaled horizontally. This means that any deployed service can be duplicated in order to avoid bottlenecks due to slow execution. Another option to increase performance is to run the service on more powerful hardware or multiple machines that process data in parallel.

7. Testing and monitoring: Single software components are much easier to test than a complex application. If each microservice is tested properly, the software as a whole tends to be more robust and reliable. And being able to isolate only parts of the application allows for better monitoring and security management.

8. Delivery: Over the past couple of years, automation techniques have drastically improved, which has also driven the evolution of the cloud and AWS. Thanks to infrastructure automation techniques and the principle of continuous delivery, the operational complexity of creating, implementing, and testing microservices have been significantly reduced.

9. Integration: A software should be able to integrate as many new features and services as needed. Even though this sounds logical, the integration of new software components into an existing application can be a challenge in traditional software development. Through the use of continuous integration tools, microservices have completely revolutionized this process.

10. Reusability: An often forgotten but great benefit of microservices is the fact that the independent components that make up the entirety of the software can be reused for future projects. By reusing successful processes and only modifying them slightly, a development team doesn’t need to reinvent the wheel and consumes fewer resources.

How do I get started with Microservices Architecture?

Switching from traditional software architecture to a new architectural style can seem intimidating at first. However, since microservices architecture has already been tried and tested by other companies – more concrete examples later on – there are some best practices that have emerged over the past decade or so.

But before getting started, it’s important to remember that each microservice can be developed in a different programming language and technology. Thus, the technology for implanting individual services is far less important than the overarching technologies for integration and communication.

Getting on the same page: When transitioning to a microservices architecture, every team involved needs to be thoroughly prepared. Ultimately, this architectural style is not just about splitting up one big application, but it entails a shift in company culture and mentality. Each team needs to be truly independent and at the same time, communication standards, shared API documentation, and logging formats are absolutely essential for successful execution.

Defining the target architecture: Microservices architecture is designed to make a company’s software landscape less complex. But if it isn’t designed or managed properly, it can create more complexity or even chaos. Before starting out with microservices, it’s crucial to define what the target architecture should look like. Eliminating contradicting dependencies and making sure data remains consistent across all microservices is key. A network upgrade might be necessary to avoid traffic between the services.

Never stop monitoring: Breaking up one large application into multiple individual applications means that each and every single one of them produces a large number of logs that need to be analyzed. That’s why it’s important to draw out a clear-cut plan for monitoring the individual microservices on a regular basis through response time or service error notifications. Dashboards, logs as well as monitoring, and value stream management tools facilitate these tasks and create a much-needed overview.

Examples of Microservices Architecture

In 2009, tech giant Netflix pioneered microservices architecture by breaking away from a traditional monolith architecture. In fact, this was one of the deciding factors that paved the way for the platform’s phenomenal growth: Microservices minimized the risk of server outages and allowed developers to fix small components of code without affecting the frontend interface. So it really isn’t surprising that other companies followed Netflix’ lead:

• Spotify: The music streaming platform serves over 75 million users per month. With more than 90 teams, 600 developers, and 5 development offices worldwide, Spotify needed to reduce dependencies to avoid synchronization. Through small microservices and autonomous teams, system failures are kept small and don’t affect the user experience.
• Zalando: The European e-commerce company is another example of a microservices transition gone right. When Zalando adopted the modular approach, it also introduced STUPS, a Platform-as-a-Service toolset on AWS that can be used by multiple autonomous teams. The toolset allows departments to iterate quickly and meet their reporting goals.
• Gruner + Jahr: Over the past couple of years, the German publishing company Gruner + Jahr has decentralized its applications by using more and more cloud vendors, including AWS, GCP, and Microsoft Azure. With the help of LeanIX Value Stream Management, the company managed to create a bridge between its EA landscape and a large number of new cloud services.

What’s the difference between Microservices Architecture and SOA?

Even though microservices architecture and service-oriented architecture (SOA) have some things in common, there are quite a few differences in the architectural pattern and approach. Both microservices and SOA use services as architectural elements that communicate through protocols over a network. However, while data storage is shared among all services in SOA, each service has its own database in the microservices approach.

Microservices are also significantly smaller in size and scope and are independently deployable. In SOA, the enterprise service bus (ESP) that provides point-to-point connections between services could potentially cause an entire system failure. However, it’s important to note that SOA can also be designed in a monolith pattern.

What’s the difference between Microservices and Monolithic Architecture?

Monolithic architecture can be considered the counterpart to microservices architecture. It is the most traditional approach in software development where an application is designed as one single unit vs. loosely coupled units, the main characteristic of microservices architecture.

A monolithic software consists of one database, a user interface, and a server-side application, and is, therefore, a single logical executable. This also means that one failure can affect the entire system and development teams need to deploy a new version of the server-side application whenever alterations are made.

Microservices eradicate these problems by being small, functional stand-alone applications that can be managed and updated independently.

What’s the difference between Microservices Architecture and an API?

When talking about microservices, it’s only a matter of time until APIs are mentioned. But what are APIs exactly and how do they differ from microservices? API stands for application programming interface and can be seen as a contract of actions that are requested from a particular service.

Microservices architecture on the other hand is a software development technique while a microservice can be defined as a small self-contained application.

APIs are an important portion of a microservices architecture. They allow the different services to communicate with each other through standardized protocols as well as direct interaction with the service itself.

Microservices and Kubernetes Governance

While the governance of monolithic systems is centralized, microservices governance is completely decentralized and therefore needs proper governance mechanisms. Thus, many companies use the open-source container-orchestration system Kubernetes for hosting their microservice-based implementation.

Originally designed by Google, it was built to provide a flexible platform and CI tools for efficient microservices governance. But what does that look like in practice? Kubernetes enables users to containerize applications so they can integrate them into a cluster environment.

One container comprises all the packages that are necessary for running a service. That way, microservices are much easier to configure, scale, and deploy.

Conclusion

There are many reasons why more and more companies see the need to switch over to a microservices architecture. One of them is directly linked to the uncoupling of services by resorting to cloud service providers. And not to forget, the difficulties of maintaining an ever-growing monolithic software bears debilitating risks and can significantly hamper business growth and success.

However, it is important to remember that a transition to microservices needs to be well-thought-out. After all, a successful execution doesn’t lie in every single service but the overarching technologies and tools that are used for governance, integration, and communication.