What are Microservices?
Microservices, also known as microservices architecture, refers to a software development method that structures an application as a combined collection of services. Essentially, this suite of applications is deployed as a complete application in its own right and these services all work together to make up the entire application. Microservices all follow these patterns: They are organized around business capabilities, they are loosely-coupled, they are independently deployable, and they are testable. Because they are loosely-coupled, microservices can then be built, deployed, and scaled independently.
Each service communicates with other services through standardized application programming interfaces (APIs), enabling the services to be written in different languages or on different technologies. This differs completely from systems built as monolithic structures where services are inextricably interlinked and can only be scaled together.
As each service has a limited, generally singular, functionality, it is much smaller in both size and complexity. The term microservice comes from this discrete functionality design.
By decomposing the application into discrete services that implement specific business functions, microservices give modern developers a way to design highly scalable, flexible applications.
Why Microservices?
Microservices have risen in popularity because their modular characteristics lead to flexibility, scalability, and reduced development effort. Their deployment flexibility, and the rise of cloud-native serverless and function-as-a-service deployment options (such as AWS Lambda and Microsoft Azure Cloud Functions), have created the perfect environment for microservices to flourish in today's IT landscape. These cloud platforms enable microservices and functions to be scaled from inactivity to high volume and back again while customers pay only for the compute capacity they use.
As businesses are continuously looking to be more agile, reduce bottlenecks, and improve application delivery times, microservices architecture continues to rise in popularity.
In the past, companies developed specialized enterprise applications that had three main components:
- A client-facing interface, usually HTML pages running on a user’s machine
- A database, typically many tables in a relational database management system
- A server-side application that handled all requests such as data retrieval, HTTP requests, and populating HTML browsers.
For the user, everything seemed to run through a single point of contact. Development, testing, and deployment used a deployment pipeline, and you could horizontally scale up by running multiple instances.
However, they were quite costly to develop, any changes required a full system redesign, rebuild and redeployment, it was hard to keep a clean, modular structure as the organization grew and changed, and scaling up required the full application to be retested, scaled and redeployed for any change no matter how small the revision. All of these issues led to an expensive, non-agile system that the rapidly-changing technological landscape quickly outgrew.
One way to think of these traditional monolithic systems are as ready-made dollhouses. While you can edit the structure or the layout, it is not easy, and you are limited in the overall size unless you buy another dollhouse and attach it to the legacy dollhouse.
With microservices, the entire application does not need to be redeployed, just the services that need it. Instead of a singular structural entity, like a dollhouse, think of microservices as a pile of Lego bricks. Technically, they’re all independent, but when put together, they form an entire structural application. If you want to add a compartment or terminate something, it can easily be removed, added, scaled up and edited to suit changing needs quickly and efficiently without having to shut down the entire application.
Benefits of a Microservices Architecture
There are a number of significant benefits for businesses looking to adopt microservices and integrate them into their offerings, which will be explored in greater detail below.
Faster Time to Market
Being able to add and remove functions quickly means that the business can become incredibly agile. Adding new functionality can be done at-speed, keeping up with business growth. Unlike traditional monolithic software, changes to code in one part of the system will not affect other modules, so there is no need for extra testing, shutting down the entire application, or having to redeploy everything.
Higher Functionality and Lower Operational Costs
Because the modules in microservices are all separate, there is a far less risk of potential bugs or errors causing the entire application to fail. Unlike traditional software systems, where a change in one part of the functionality may cause a flaw or bug in another part, isolation and loose-coupling enables the implementation of compartmentalized upgrades and enhancements. Microservices also allow for the use of cloud-native function-as-a-service deployment options, which can significantly reduce operating costs.
Easily Scalable Applications
Scaling decisions for microservices are made at a granular level, allowing for the most efficient decisions for system optimization. By adopting microservices, when the time comes to scale up, organizations are able to make the choices that are best for them, right in the moment.
Continuous Integration
Microservices are developed using individual continuous development and deployment streams. These streams can be sustained so there is no disruption in another service when one team implements a change based on customer feedback, which means higher end user satisfaction.
Dedicated Developer Teams
Unlike monolithic systems, which cannot sustain multiple development teams, microservices have the ability to support teams dedicated to certain, specific parts of the system. Because the software modules do not interact with each other, there’s no risk of bugs or cross-team overlap of work, so microservices teams can have specialized software developers, as well as teams working across different timeframes or geographic locations.
All of these benefits add up to perhaps the most significant one: business agility. Small and simple changes can be made quickly, allowing for experimentation of processes. The ability to take a huge leap forward in business, or at least fail fast and react in real-time, becomes possible with microservices. In addition, studies have found that within months of deploying microservices architecture, a third of organizations start to achieve advantages. That means timeframes for development are decreased, and with less errors in code and increased capabilities, the positive impact on business operations can be felt almost immediately.
Characteristics of Microservices
- Loosely-coupled
- Independently deployable components
- Automated deployment
- Decentralized data and language control
- Highly-maintainable
- Easily-testable
- Organized around the needs and capabilities of a business or organization
- Each service tends to be owned by a small team
Challenges with Microservices
While microservices do solve a number of problems, there are still some difficulties and issues one might encounter with the architecture, as well as with initial adoption.
Decentralized Data Management
Unlike monolithic systems, microservices usually do not rely on one database that acts as a single source of truth of your data for the company. Customer data might be in one place, while vendor data is in another. Maybe inventory information is stored with the online sales portal, but the ordering system is kept in a separate database. This can create issues with your data quality and consistency, unless you make a specific point of planning for this.
Corporate Culture and Internal Organization Challenges
It can be difficult to get companies to accept and adapt to new software systems. Often management may have a reluctance to relinquish control, or a department will be defensive of their silos. Whatever the reason for the pushback from teams having to accept new systems, the bottom line is that sometimes, people just don’t like change.
To get microservices adopted organization-wide, it’s pivotal to recognize that introducing new systems and processes can be disruptive, but it’s also just as important to remember that the benefits are worth it. When beginning the transition to microservices, it’s best to involve the affected teams when planning the architecture. Have a plan to evaluate the solutions that are available, and ensure the best fit is chosen for the business requirements.
Microservices Can Lead to Complexity in Your Architecture
While the individual services that make up microservices can be small and simple by themselves, when combined, the overall application can end up having a lot of moving parts that can become hard to manage. With hundreds or thousands of interconnections, microservices can quickly increase in complexity.
It is recommended that when implementing microservices, a significant amount of forethought and planning go into the design and basic implementation. Many complexities can be avoided with a good basic architecture design that allows for growth and change in the future.
Examples of Microservices Architecture Use Cases
Adopt cloud-native deployment options: leverage serverless and function-as-a-service for more efficient and scalable operations.
Migrate functionality from legacy applications: decompose services from large monolithic applications so they can be independently maintained and scaled.
Leverage modern application architecture: embrace event-driven, loosely-coupled microservice application patterns, with the ability to leverage different programming languages depending on use case needs. For example, go for computationally heavy functions, Node.js for quick web apps, etc.
What Is DevOps and Why Is It Often Associated With Microservices?
DevOps can be explained as a tool-centric ideology. Essentially, it’s a set of practices that combines tools and technology to simplify the work that needs to be done by developers. Alongside improved tooling, cooperation between the operations and development teams helps drive projects to completion faster and more efficiently.
For example, let’s say you are building an application that lets users check their account balances. Oftentimes in the past, the app development cycle had developers building the app and then handing it off to the operations team without responsibility for the end result. It was the operations team’s job to make the app work. In a more cohesive DevOps environment, both sides work together. A developer owns the app’s lifecycle from start to finish, which means being on-call during the release. Consistent communication between the two groups is necessary to make sure everything is successful and to get the full benefits of DevOps, such as speed to market, easier development cycle, and more accountability.
The new DevOps workflow model creates a major cultural shift. Just using new tools does not make a DevOps plan successful. If anything new tools could inhibit success if they cause you to believe without doubt that everything will implement appropriately.
Due to the nature of microservices, having strong DevOps processes is often necessary for deployment. The increased use of tooling and stronger shared practices alleviates teams from being overwhelmed by all the small moving parts. You reduce the disruption or burden of this shift while continuing to receive the benefits.
The Future: Event-Driven Microservices, Serverless Computing, and FaaS
When people first start experimenting with microservices, they often default to using familiar techniques, such as RESTful APIs. REST operates on a request-response type of communication. The problem with this synchronous approach is that since you have to wait for a response, the services become dependent on each other. This means that if one service is running slower or doesn’t respond, the service that called it will run slower or fail. This coupling can mean losing some of the benefits of a microservices architecture, creating a more interdependent structure akin to a services-oriented architecture (SOA) style.
If you design your services using beyond-REST or an event-driven model, you can ensure that parts of your application continue to work, while other parts may not be involved, as opposed to the entire application becoming unresponsive. Netflix functions as a perfect example of this. On occasion, you might notice that the “continue watching” button doesn’t appear. This is because that specific service isn’t available. However, that doesn’t mean all of Netflix stops. Users can still browse for shows and watch previews, so other aspects of the Netflix service are still functional and available for use, even though one service may not be.
Developers that fully embrace a microservices approach realize that true scalability is enabled with loose coupling and event-driven architecture. A service can be asynchronous, performing an action, broadcasting a message, and continuing on with its primary function without having to wait for a response from another service.
How Do Microservices Work?
Microservices are not a new idea. More than three decades ago, Unix developed an SOA that used a similar design principle, but was costly to implement and failed too often to be considered a good option for businesses. Twenty years later, microservices arrived with much better consistency across services and the adoption has since been far more successful.
As to how microservices actually work, first, software functionality is broken down into small, isolated modules. These modules have defined, stand-alone tasks. Then, the system works by linking these small pieces of software together using application programming interfaces (APIs).
APIs are segments of code that get two unrelated programs to ‘talk’ back-and-forth to each other. One example of APIs in action would be an app or website that has Google Maps embedded on it. An API sits between Google Maps and the app sending information back and forth, allowing users to see their map in real time, give the driver instructions, and also alert your trusted contact to your location. While Google Maps remains a separate entity, the API allows for communication back-and-forth between the map and the app. So rather than a prefab dollhouse, where everything is planned, rigid, and hard to change, you have those useful little Lego pieces that click together using APIs as connectors. Standardized technology platforms can be constrictive, but not every problem is a nail, nor every solution a hammer. Microservices allow the right tool for the job.
There are certain benefits to microservices, and companies that have successfully adopted them as an architecture model have reaped the benefits of faster, more agile business IT structures. However, some organizations have found the system to be a killer for productivity and a burden to operate. The difference between success and failure lies in two parts: the culture of the organization and its willingness to accept and use the microservices, and the planning and forethought put into the map of the microservices.
Often, the true benefits or costs of a new system are not realised for many years. Monolithic architecture will sometimes already have been outgrown or have started decaying within those years. There is less opportunity for that decay within microservices, and patching up a problem is a much simpler matter.
One solution for a variety of these potential issues is to start with a monolith. This allows for a base software to bolt other things onto as you scale up, making a kind of dollhouse with Lego extensions. While this may not be the most elegant approach, it is a way for a business to proceed, especially with an existing database or program at the heart of operations.