Microservices, also referred to as microservice architecture, are a way to structure software applications.
Microservice architecture arranges an application as a collection of loosely coupled services. These services, divided up by function, are made as granular as possible to maintain relative simplicity within each service module.
Microservices have been used to design and deploy applications since 2012, although the idea (based off of service-oriented architecture, or SOA) has been around for some time; a rough version was first presented publicly in 2005. The idea is a distinct departure from monolithic architecture, which was the primary application structure in use until microservices were developed.
The core difference between the two structures is that monolithic applications house all of their functions in a single structure that is based off of one relational database while microservices split individual functions into different containers.
Before we dive into the details of the microservice platform architecture, its use cases and benefits, let’s go over what we mean by “architecture” within a software context.
As traditional architecture refers to the design and structure of a building, software architecture refers to the design and structure of a piece of software. There are different design principles, but all software development schools of thought are concerned with the integrity of the end product. A poorly designed software application will collapse just like a poorly designed physical structure. The design principles guiding the application must be sound or there will be issues down the road with deployment, maintenance and updates.
The basic principles that guide software architecture and design are:
A prime example of good software design is Netflix. Netflix is a complex enterprise application that handles over a billion requests every day from a large number of different devices. The company architecture is successful because it adheres to the principles outlined above, separating concerns and maintaining loose coupling between granulated services. As a result, it is able to properly handle the massive amount of inbound requests it receives.
Microservice architecture is simply another name to describe microservices; the two are interchangeable because microservices are the structure of a software application or program. When we talk about the “architecture” of an application or development method, we are referring to how the application or service is structured.
Microservice architecture represents a distinct departure from the traditional monolithic structure. Each structure has its own utility and unique strengths when it comes to building software applications.
Monolithic architecture refers to the traditional, unified design of an application. Each part of the application is tightly interconnected and the success of the program depends on each part running as intended. The entire application and the services it provides run off of a single relational database. The concept is analogous to variable displacement in multi-cylinder internal combustion engines. With variable displacement, the engine uses less cylinders during light-load driving, which is when the driver uses around 30 percent of the engine’s power. Each cylinder can be thought of as an application component, and an API gateway will inform each cylinder/component when it is needed.
Because of this, in order to alter one portion of a monolithic application the development team must update the entire application. This is acceptable when the codebase is small and the number of services is small, but as the application and number of services grow, maintenance becomes increasingly cumbersome.
With microservices all the rage currently in the devsphere, why would anyone starting a project in 2018 and beyond use monolithic architecture? The answer is that monolithic architecture remains a useful development structure, particularly for smaller (non-enterprise level) applications.
The major advantages of using monolithic architecture stem from its simplicity. It is straightforward to develop, deploy and scale. Within monolithic architecture, it is also easier, relative to microservice architecture, to test and debug a program because of the intelligibility inherent in a single structure. Queries have one database to call on for information, and at smaller scales there are fewer of the complexity-caused issues associated with larger monolithic structures.
One of the major limitations attributable to monolithic design at the enterprise level is the daunting codebase size. Onboarding developers takes more time as the application grows, and both new and current developers must learn a huge amount about the monolith in its entirety in order to contribute.
As the application grows, monoliths become increasingly inflexible and difficult to scale. Monolithic architecture forces your team to stay with the “stack” of technology used at the beginning of design and deployment.
If you or your team remain shackled to the stack used during the initial stages of development, you cannot take advantage of new frameworks or languages that may be better suited to building out your software.
A monolithic application is built in three parts. There is a user interface running on a web browser, a server-side application and a relational database. Below is a visual representation of an application built using simple monolithic architecture.
Microservice architecture is an application structure that divides services into separate modules which are loosely coupled together. Loose coupling means that each application component has little to no knowledge of the definitions of the other components that make up an application. Each service uses its own database and functions independently of the larger application. Because services are run independently of one another, different programming languages and frameworks can be used for each service.
A simpler service like a Windows runtime component can be built with a more basic language like Java while something more complex may be built using Scala or another function based language. The ability to use multiple languages is beneficial because a single programming language can be great for building one type of component and not as great for others.
The ability to use multiple languages during development means that each component can be built using the language and framework suited for that specific component. Additionally, teams can use new languages and frameworks as they are released to build out new components and services.
Microservices’ flexibility is the key to the value they provide, and their modularity enables their flexibility.
Microservice architecture makes continuous deployment easier and quicker because of the smaller size of individual modules. The separation of services into modules means DevOps can roll out new features, bug fixes and product changes within each module. This separation increases the safety and speed with which the development is able to deploy application alterations.
The modular structure of the microservice architecture makes continuous deployment easier. Small changes, bug fixes and updates can be rolled out each sprint or short dev cycle as opposed to every six months like larger monolithic applications tend to do.
Scaling up an application is easier with microservices because development teams deal with a single service and do not have to understand the program in its entirety to grow an application. Instead of growing the single relational database and swelling the application to an untenable size, a new service can be added and built out separate from the application as a whole. With microservice architecture, DevOps members do not have to acquire tribal knowledge in order to solve unintuitive application problems.
Dealing with a technology stack that worked fantastically for years but has become unfit for the functions your application is now tasked with providing? Choose a different one. While monolithic architecture shackles you to your original programming framework and languages, microservice architecture frees you from those bonds.
Developers are no longer fettered to a language or a framework that doesn’t fit the direction their application is headed. DevOps can build new services using entirely different frameworks and programming languages that are better suited to building out a given service. For example, a simpler service may be built using JavaScript or Ruby, while a more complicated service could be built using Scala or another function-based language.
If a fault occurs in one module, it doesn’t affect the others. Microservices makes it easy to isolate any technical problems and confine them to a single module. Fixing the isolated fault is also easier because you’re dealing with a smaller codebase and don’t have to worry about any fix messing up other services.
Software architecture does not subscribe to the notion that one size fits all, and microservices are not a perfect fit for certain applications. While the individual services within the microservice architecture are relatively simple because of their size, the interactions between services are complex.
This complexity means a slower initial deployment for the application and the possibility of mistakes being made by development teams. Every change requires a redeployment of the entire application, and changes within one portion of the architecture can affect other areas. The more complex an application becomes, the easier it becomes for mistakes to be made because there are so many tightly interconnected moving parts that rely on each other to function.
“Distributed transactions” refer to actions an application undertakes that require it to break out of its own domain. While there are multiple advantages to breaking down an application into separate services, actions that need information pulled from multiple services are more complex and difficult to carry out. Splitting services into separate modules makes running functions that require information from multiple services within the application more difficult.
The cost of implementing microservice architecture is much higher than that of a monolithic design pattern because of the number of moving parts involved. Deploying the application for the first time involves much more testing and maintenance than in the deployment of an application using monolithic architecture.
We’re not talking about rotting apples when we mention decomposition in a software context; rather, how to break down an application into services.
The DevOps team using microservices must decide how to divvy up the application into separate modules/services. Well-defined services are vital to creating a properly functioning application.
The primary use for microservice architecture is in developing enterprise-sized applications that are expected to perform a wide variety of functions.
Enterprise companies have started to use microservice architecture as they have scaled. Uber, for example, was originally constructed using the traditional monolithic pattern. The first incarnation of the application worked perfectly when Uber was offering a single service in a single city; a single codebase that handled all of their core business functions was clean and easy to handle.
As its user base grew and the company expanded into different cities with an increased range of service offerings, the monolithic architecture became a hindrance to growth. The development team swelled; onboarding became a nightmare because of the sheer size of the requisite knowledge base new developers had to familiarize themselves with before being able to contribute. According to Uber, “Adding new features, fixing bugs, and resolving technical debt all in a single repo became extremely difficult. Tribal knowledge was required before attempting to make a single change.”
Microservices were the way for Uber to expand its business and stay agile in an increasingly competitive marketplace. You’d be well-advised to stay up to date with the trends related to microservices as adoption rates increase and enterprise organizations make it the development standard in 2018 and beyond.
There are well-designed microservice frameworks for developers using Java. Here are three that you may find useful as a seasoned or budding Java developer looking to develop an application using microservices:
| Spring Boot | Jersey | SwaggerHub | |
| G2 Crowd Star Rating | 4.6 / 5.0 | N/A | 4.3 / 5.0 |
| No. of Reviews | 29 | N/A | 10 |
Running queries is more difficult when using microservices as opposed to a monolithic structure because there are multiple databases to query. Querying these databases can cause all sorts of merge issues if done in the traditional way, where command and query functions are performed together. The solution to this issue is splitting the two functions by using command query responsibility segregation (CQRS).
The basic tenet of CQRS is that the application is split into two sides: the command side and query side. The command side updates the data while the query side searches it. CQRS is beneficial when using microservices because of the vast amount of functions that the application is expected to provide to end users.
CQRS works by setting up two different stores of information: the event store and the data store. The event store is a record of all of the inputs handled by the service, while the data store is a database end users can query in order to obtain a snapshot (materialized view) of the information they are looking for. The command service gives the event store input in the form of changes or updates and the query service accesses the information in the data store. Below is a diagram that outlines the basic structure of CQRS in action.
Monoliths fit the traditional waterfall development philosophy, while microservice architecture enables businesses adopting an agile philosophy. The flexibility developers have when using microservices allows businesses to pivot and add services as necessary to position themselves well in the rapidly changing tech industry.
Microservices have burst onto the DevOps scene in the past few years, with enterprise players taking advantage of their flexibility to stay on top of industry trends. G2 will be keeping tabs on how microservice architecture is shaping organizations as the year progresses.
Here’s a riddle: what does a box of Legos and the future of technology suites have in common? ...
by Casey Paxton
What is “architecture?” Four walls and a roof? A shiny tower?
by Nicholas Van Antwerp
Kubernetes has experienced tremendous growth in its adoption since 2014. Inspired by Google's...
by Samudyata Bhat