Building and deploying miroservice applications

How, when, and why to migrate from a monolithic to a microservice architecture

Download white paper

Understand the advantages

Many mid-size and large enterprises, such as Walmart, Netflix, Amazon, and eBay, fully embrace microservice architectures for new application development. Applications ranging from moderately to extremely complicated benefit. Let's take a closer look at the upside of microservices.

Build and update quickly

Microservices enable higher quality code by encouraging more focus. Since a microservice is much smaller than a monolithic application, its scope is smaller, and there is less code to maintain. Experimentation, evolution, system verification, and testing are not as taxing. Commonly, the overall code-line count for an entire microservices solution is larger than a comparable monolithic application. However, the componentization of the code offers a higher degree of flexibility and maintainability. Isolated code within each microservice translates into conceptual simplicity and ease of use.

New team members learn to quickly understand the objectives of each microservice and begin contributing earlier. The risk is much lower for the application to become an inscrutable black box. Feature updates and testing are less arduous. Incremental updates to individual services typically present less business and technological risk. Many development teams report that microservices are easy to maintain and update, translating directly into better quality and greater agility.

Reshaping a team toward microservice development often results in better development practices. If a team rearranges its architecture into a set of services that correspond to smaller tasks, less effort is needed to focus on isolated functional accuracy. Much of the concerns stemming from pre or post functionality can be set aside. Of course, it is vital to establish and conform to a simple decoupled messaging system, such as a REST API.

Standard interfaces and expectations also simplify the microservice development process. Each microservice must communicate with the messaging system in a standard format that any other service will precisely understand. Decoupling encourages experimentation and makes comparing different versions of code in the same environment less daunting. The simplicity and modularity of each microservice also maximize the incentives for reusability.

Embracing a microservice architecture is not necessarily a cliff-hanger endeavor, providing maximum flexibility in software development. There are many options. One migratory approach is to incrementally add microservices to an existing monolithic application to add more capabilities and progressively eliminate existing features. For extensive legacy platform modernization efforts, it's often quite sensible to incrementally migrate a monolithic application into a microservice architecture to achieve the benefits covered in this paper. Though somewhat similar to SOA, one key difference is that a microservice architecture can transform applications so that each becomes manifestly more manageable.

Pick and choose various development technologies

Technologically, there are few limitations on how to build each microservice. Choose virtually any layer in any stack and use different technologies that interact with microservices built with other technologies. Separate service development teams with varied skills and specializations easily collaborate between teams on how each service will interact. It's easier to evaluate and adopt new development technologies.

Future technological adoption becomes a pleasant prospect. Instead of struggling with disruptive system-wide technology standardization, teams can experiment and adopt new technologies. There is more flexibility because of the team's ability to decide whether or not to update only some of the microservices and evaluate if it's sensible to proceed or choose another path. Additionally, a microservice architecture enables added flexibility with respect to technical skills. A team can engage with a broader talent pool since any microservice can be built with virtually any programming language and reside in different environments.

Experience rapid, parallel, iterative deployment

One of the limitations of deploying a monolithic application is the number of potential discrepancies between development and production environments, plus between the versions of supporting technologies in the same environment. In a typical deployment pipeline, there are many interdependencies among OS versions, library versions, middleware versions, system specifications, etc. For complex applications that entail many dependencies, a team likely encounters significant deployment problems that are grueling to identify and remedy.

Microservices are small, with few environmental dependencies, which makes for easier deployment. Typically, there are far fewer problems with the deployment of experimental and incremental microservice updates. The architecture is ideal for modern deployments that use popular technologies, such as cloud computing, cloud object storage, Docker containers, and Kubernetes. Moreover, reducing dependency problems gives a significant advantage for a containerized environment.

Since microservices are simple and small, it takes less effort to deploy with containers and other virtualization technologies. This approach further reduces the potential for dependency conflicts. Combining a containerized deployment with Kubernetes as the orchestration system simplifies deployment even further by efficiently allocating microservices to available resources.

Deployment works in various configurations, whether on-premise, in the cloud, at the edge, or in a virtualized environment, such as Docker, and quickly finds a home in a serverless environment, on a single node, or a cluster. Indeed, microservices are maintainable in a geographically dispersed configuration to exploit specific available local resources.

A significant development advantage that heavily favors a microservice architecture is the ability to independently manage parallel teams and get new features to market fast. There's often no need to synchronize updates with other microservices. As long as the messaging protocol and the data format remains intact, redeploying any mix of microservice updates works without a negative impact on different parts of the system. If any problem occurs with a new microservice, DevOps can immediately and automatically revert to the previous version.

Indeed, microservice deployment makes migrating to a continuous delivery deployment pipeline easier. The modularity and flexibility of microservices is a major catalyst in moving toward full automation of a deployment pipeline.

Easily fix, maintain, and extend the system

Together with good development practices, a microservice architecture facilitates higher levels of fault tolerance, rapid problem identification, and lower maintenance efforts. In contrast, troubleshooting a monolithic application can be extremely involved because it’s often unclear how the data is processed internally. Isolating the root cause requires a relatively deep understanding of the entire code base. When analyzing a microservice application, it is easier to examine each service's inputs and outputs to pinpoint and remedy a problem quickly.

Say, for example, a team discovers that the final calculations in a microservice-based system produce incorrect results. It can trace the data path backward from those results and execute progressively one microservice at a time until the problem reveals itself. The scope of each microservice is small and simple to envelop in an automatic test suite that can run iteratively or after each debugging session. Also, keep in mind that the microservice testing scope becomes much smaller with isolated code changes. Tests run faster and require less effort.

Continuous, incremental updates to a microservice system eventually become relatively easy and low risk. Teams can either insert clean code revisions to improve an existing feature or add new code that extends the system's functionality. In the long run, the quality of the overall code base improves more rapidly than a comparable monolithic architecture. Major comprehensive system updates that impact multiple microservices become less scary with a microservice architecture.

Simplify cross-team collaboration

A major challenge in large-scale software development effort is the risk of intensifying the level of web of integration points. Developers frequently become lost in what seems like a thick, black forest. Here, a microservice architecture offers yet another advantage.

For any particular microservice, the internal workflow is less complicated: read data from a source, inspect and process the data, and then send the output to one or more destinations. When designing the microservice, it’s unnecessary to anticipate what data should be shared on which integration points, which is essential for an SOA. Typically, a microservice manages a small amount of data at a time, requiring less effort to verify, manage, and distribute the output. Simplicity in functional scope, data size, and processing translate to simplicity when managing the entire microservice system. As a result, microservice development teams collaborate more effectively.

Microservices depend on a lightweight messaging protocol. After all the developers agree on standard message formats for all of the microservices, communication between each becomes reliable. If the scope of each microservice is such that it only performs a specific task on the data, there is no need for a complex output.

Maintaining simplicity in the messaging protocol is also an advantage if there are future changes to the data format. If the format changes are kept simple and consistent with microservice development best practices, it is manageable for other microservice development teams to accommodate changes.

Achieve better scaling and higher performance

Microservices enable an extensively distributed architecture that is dynamically scalable and capable of high levels of throughput. Each microservice can be extensively duplicated in the production environment for both fault tolerance and parallel processing. For some resource-intensive microservices, additional instances could start to run on other computing resources. Microservices are independently scalable. System resources can be monitored and boosted incrementally to support specific microservices. If a bottleneck arises in the production environment, operations can deploy more instances of critical services manually or with Kubernetes in a containerized environment.

The ability to readily manage performance and scalability with microservices becomes about meeting SLAs, load-spike contingencies, or planning for future growth. Microservices also enable rapid innovation, especially on product pipelines, which require frequent experimentation to increase competitive viability. Microservices development provides the ability to experiment, deploy, revert, and iterate while reliably maintaining operations and simultaneously exploring new opportunities.

Keep in mind that such performance and scalability benefits only apply to code within the microservice architecture. Limitations often arise with external resources, such as a database management system or a remote third-party API. It's necessary to understand the capabilities of external systems and how they impact the performance of one or more microservice.

Continue to:Tackle the challenges