Understanding Microservices as a Software Architecture
The exact definition of architecture has been a controversial issue in IT industry. However, it could be defined as the fundamental organization of a system, or the way that the highest level components are connected together. As a matter of fact, enterprise software architecture always evolves with advanced architectural styles in order to find better patterns to build software in a fast and reliable way. Microservices can be another new term on the crowded streets of software architecture. Nowadays, the Microservices Architecture has been introduced as a proper architecture pattern to address the drawbacks of the SOA and ESB, as well as the traditional monolithic architecture. This article will provide you with the key concepts and foundational knowledge necessary to understand Microservices Architecture.
Introduction and Overview
Basically, the definition of architecture has been a problematic issue in the software world. In IT industry, architecture is defined as the most significant aspects of internal design of a software system. In other words, it is the fundamental organization of a system, or the way that the highest level components are connected together. In addition, if a software has an inappropriate architecture, it becomes slower and more expensive for adding new features in future.
What do we mean by a software architecture? To me the term architecture conveys a notion of the core elements of the system, the pieces that are difficult to change. A foundation on which the rest must be built.
— Martin Fowler
Another important aspect for defining architecture is to decide what is important, like what is architectural. Then, you should focus on keeping those architectural elements in a proper situation.
A good architecture is something that supports its own evolution, and is deeply intertwined with programming.
— Martin Fowler
In fact, architecture plays an important role for the users of software products because it is not something that they understand immediately. This means inappropriate architecture is a main contributor to the growth of cruft, which leads to build slow features with more defects.
Eventually, enterprise software architecture always evolves with advanced architectural styles in order to find better patterns to build software in a fast and reliable way. Microservices is another new term on the crowded streets of software architecture. The microservices architecture has been widely adopted as an architectural style, which allows you to build software applications with speed and safety. It means the microservices architecture pattern has been accepted quickly in the industry as an alternative way to monolithic applications and Service-Oriented Architectures(SOA). Since this architecture pattern is still evolving, there is no much information in the software industry about what this pattern is all about and how it is implemented effectively. This essay will provide you with the key concepts and foundational knowledge necessary to understand Microservices Architecture.
The Evolution of Microservices Architecture
To understand the main characteristics of microservices, it is necessary to consider the evolution of enterprise architecture from monolithic microservice.
Monolithic Software:
In a monolithic architecture, the entire software is built as a single unit that consists of all the business logic. This can be effective on adding or modifying a functionality to a component. This means adding or modifying a functionality could be extremely expensive because of its monolithic nature. Additionally, to ease to reach the all business requirements as you need, these components must communicate with each other. These communications between these components are often built on top of some protocols and standards. They are built based on the point-to-point communication. So, this factor makes a considerable effect on changing in the architecture, and makes it much more expensive process in practice.
To understand this architecture fully, there are some typical characteristics have been mentioned as follows:
- The opportunity for reusing functionalities across a software is limited.
- Designed, developed, and deployed as a single unit.
- The entire software uses one or more centralized databases.
- As the software scope grows, maintaining the code becomes more complicated in reality.
- One unstable service can bring the whole software down.
- It would be difficult to practice Agile development and delivery methodologies.
- It would be extremely hard to adopt advanced technologies and frameworks.
- A failure in any component could affect on the availability of the whole software.
- The whole software has to be scaled, even when the business requirement is for scaling just only specific elements of the software.
Service-Oriented Architecture (SOA) and Enterprise Service Bus (ESB):
In fact, to eliminate some of the limitations of the monolithic architecture, SOA and ESB have been announced. In general, to face the challenges of large monolithic software, the SOA separates the functionalities of this architecture into reusable and loosely coupled entities that is called services. A service is a discrete unit of functionality, which can be accessed remotely and updated independently. Services use common interface standards and an architectural pattern; therefore, they can be incorporated into new applications immediately. These services can be accessible via calls over the network. In short, SOA defines a way to make software components reusable and interoperable by using service. There are some other aspects for this way of thinking in software architecture could be pointed out as follows:
- A service is a self-contained implementation of a well-defined business functionality, which is accessible over the network.
2. The separation of the service interface(the what) from its implementation (the how).
3. It would be a black box for its consumers. The consumers are just only concerned about the service interface, and do not care about its implementation.
4. A service might be composed of other services.
By using SOA approach in architecture, each business functionality is built as a (coarse-grained) service (often implemented as Web Services) with various sub-functionalities. These services are deployed inside an application server. Therefore, when it comes to the consumption of business functionalities, you probably require to integrate multiple services and other systems. Enterprise Service Bus (ESB) is used to integrate those services, data, and systems. The consumers use the composite services released from the ESB layer. Initially, ESB is used as the centralized bus that connects all these services and systems. ESB increases agility and flexibility by having high-level protocol communication. For instance, an online retail software use case can be showed as follows:
API Gateway layer:
Nowadays, displaying business functionalities as managed services or APIs plays an essential role in modern enterprise architecture; nevertheless, SOA cannot address this requirement efficiently due to the complexity of the Web Service-related technologies, such as WS-Security and WSDLs. Hence, in most modern approaches, software companies put a new API Gateway layer on top of the existing SOA implementations. This demonstrates a simple API for a given business functionality, and hides all the internal complexities of the ESB or Web Services layer. Furthermore, the API layer is used for security, throttling, caching, and monetization. For example, an online retail software use case by using an API Gateway layer can be displayed as follows:
Microservices Architecture
Obviously, with the increasing demand for complex business capabilities, particularly decentralized software needs, the previous approaches cannot be able to deal with some limitations and drawbacks in implementing productively. Thus, the microservices architecture has been announced as a better architecture approach in order to overcome these challenges in practice.
Microservices architecture is an approach in which a single application is composed of many loosely coupled and independently deployable smaller services.
The microservice architectural style is an approach for developing a single software as a suite of small services that are running in their own process and communicating with lightweight mechanisms(often an HTTP resource API). These services are built around business capabilities and independently deployable by fully automated deployment machinery. For instance, the online retail software can be changed into a microservices architecture as follows:
As you noticed from the example, each microservice at the microservices layer offers a well-defined business capability, specially via a small scope that are designed, developed, deployed, and administrated independently. Moreover, even though there have been some changes in the ESB and service layer, the API management layer relatively stays the same. In fact, we have an opportunity for separating the gateway into independent per-API based runtimes.
The Main Characteristics of Microservices
Some key characteristics for this architecture can be discussed as follows:
Using services as components
Fundamentally, a component is a unit of software that is independently replaceable and upgradeable. Typically, most companies have been building their software based on connected components. Also, we can be able to define libraries as components that are connected into a program and called using in-memory function calls. The important point is that Microservice Architecture will use services instead of library. The major reason for using services as components is that services are independently deployable. If you have a software that includes a multiple libraries in a single process, a change to any single component will lead to redeploy the whole software. However, a software built on multiple services approach, any change will be limited to one service in future. The one of the primary goals of successful microservice architecture is minimizing the changes with cohesive service boundaries and evolution mechanisms in the service contracts.
Designing your service based on business capability
Another essential concept of the microservices architecture is that your service has to be designed based on the business capabilities. It means a given service will serve a specific business purpose and has a well-defined set of responsibilities. A given service should focus on performing only one task and doing it well. Besides, if a service has a small size, it would be considered as an anti-pattern. The size of the service is not specified based on the number of lines of code or the number of developers working on that service. Some concepts are helpful for identifying and designing the scope and functionalities of a microservice, such as Single Responsibility Principle (SRP), Conway’s law, Twelve Factor App, and Domain Driven Design (DDD).
Having products not projects
Microservice tries to avoid the traditional project attitude. The traditional attitude is completing some piece of software as a software project. Then, after delivering and maintaining process the team of developers would be disappeared. In contrast, in microservice approach team should own a product over its full lifetime. A general inspiration for this is Amazon’s idea of “you build, you run it” , which a development team takes full responsibility for the software in production. This brings developers into day-to-day contact with how their software behaves in production. Also, it can rise contact with their users. There is no certain reason why this approach cannot be used with a monolithic architecture, but using services in this way make it easier to create the personal relationships among developers and their users.
Eliminating central ESB: Smart Endpoints and Dumb Pipes
Essentially, the microservices architecture introduces an advanced style of service integration called smart endpoints and dumb pipes instead of using an ESB. By using smart endpoints and dumb pipes, all the business logic that contains the inter-service communication logic resides at each microservice level ( smart-endpoints), and all such services are connected to a primitive messaging system (a dumb pipe) that does not have any business logic. Hence, the significant point is that the complexity of the ESB will not be removed. It gets distributed among all the microservices that you develop. The two protocols utilized most commonly are HTTP request-response with resource API’s and lightweight messaging.
One of the most important challenges in transforming a monolith architecture into microservices one is changing the communication pattern. A traditional form of communication uses RPC. Instead, you will require to replace the fine-grained communication with a coarser -grained approach.
Decentralized Service Governance
One of the outcomes of centralized governance is the desire to make uniform on single technology platform, but previous experiences show this attitude could not be a productive way in reality. So, by splitting the monolith’s components out into services, you have a unique opportunity to build each of them via using various standards and approaches in implementation. For example, perhaps, you want to use Node.js for a simple reports page, and C++ for a real-time component in a project. In the meantime, you want to be able to swap in different flavors of database for reading behavior of one component.
In microservices architecture, the service is built only to the point where it satisfies the contract. So, when you transform monolithic into a microservices architecture, most of the useful governance concepts are ignored, and the governance in microservices is interpreted as a decentralized process. This allows each team entity to govern its own domain as it prefers. Moreover, there are various areas in microservices architecture that the decentralized governance is suitable, such as to the service development, deployment, and execution process. Nevertheless, we can classify two key aspects of governance: first, design-time governance of services, such as choosing right technologies and protocols. Second, the runtime governance, such as service definitions, service registry and service versioning.
Decentralized Data Management
As it is clear, in a monolithic architecture, a software should store the data in single and centralized databases to implement various functionalities. However, each microservice can have an ability to have a private database for persisting the data, which requires in implementing the business functionality. A given microservice can just only access the dedicated database. So, the databases of other microservices are not accessible. The decentralized data management gives you the fully decoupled microservices and the liberty of selecting the data-management technology, like SQL or NoSQL.
Infrastructure Automation
Recently, infrastructure automation techniques have been evolved remarkably, particularly the evolution of the Cloud and AWS. This techniques has diminished the operational complexity of building, deploying and operating microservices. Furthermore, a number of software products that have been built with microservices approach have some teams with extensive experience of Continuous Delivery and Continuous Integration. This leads to use of infrastructure automation techniques widely.
Failure Tolerance
In microservice architecture, there is a lot of emphasis on real-time monitoring of the software by checking both architectural elements, like how many requests per second have been called in the database, and business relevant metrics, like how many orders per minute have been received. Also, any service failure can typically make an effect on the user experience quickly. So, as it is clear, detecting or predicting failures in a service and restoring such services is extremely important. Microservice teams should observe sophisticated monitoring and logging setups for each individual service, such as dashboards showing up or down status and a variety of operational business relevant metrics.
In conclusion
Software architecture could be defined as the fundamental organization of a system, or the way that the highest level components are connected together. Microservices can be another new term on the crowded streets of software architecture. Recently, the Microservices Architecture has been announced as an appropriate architecture pattern to tackle the drawbacks of the SOA and ESB, as well as the traditional monolithic architecture. This essay discussed some key concepts and foundational knowledge necessary to understand Microservices Architecture.
