What is a microservices architecture?
Microservices architecture refers to a technique that gives modern developers a way to design highly scalable, flexible applications by decomposing the application into discrete services that implement specific business functions. These services, often referred to as “loosely coupled,” 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 were inextricably interlinked and could only be scaled together.
As each service has a limited functionality, it is much smaller in size and complexity. The term microservice comes from this discrete functionality design, not from its physical size.
Why a microservices architecture?
Microservices architecture has risen in popularity because its modular characteristics lead to flexibility, scalability, and reduced development effort. Its 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.
Benefits of a microservices architecture
- Application components can be built in different programming languages
- Individual continuous development and deployment streams can be sustained
- Extremely scalable applications can be built
- Use of cloud-native function-as-a-service deployment options is possible
- Lower operational costs often result
- Isolation and loose-coupling enables compartmentalized upgrades and enhancements
Example 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, tools/technology are used 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 it work. In a more cohesive DevOps environment, both sides work together. A developer would own the app’s lifecycle from start to finish, which means, for example, being on-call during the release. Consistent communication between the two groups is necessary to make sure everything is successful and you get the benefits of DevOps (speed to market, easier development cycle, more accountability, etc.).
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, for example, RESTful APIs. REST operates on a request-response type of communication. The problem with this synchronous approach is that you have to wait for a response; the services become dependent on each other. If one service is running slower or doesn’t respond, it means 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 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. Take Netflix as an example. On occasion, you might notice that the “continue watching” button doesn’t appear. This is because a 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 available, 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.
