What Are Microservices?

Microservices architecture, also known simply as “microservices,” is an approach to building software with modular services that are distinct and independent from each other. 

In recent years, microservices have become a popular choice for designing and deploying applications. They allow apps to be broken into smaller and loosely coupled pieces (microservices) that are independently tested, maintained, and deployed—thereby granting development teams more autonomy and creative control over how they build.

In this post, we’ll explore what microservices architecture is, analyse its benefits and drawbacks, and look ahead to the future of microservices. 

But first, it’s worth understanding other development methods—and how they compare to microservices today.

What is monolithic architecture?

In the early days of app development, the entire source code was built into a single deployment unit; this is known as the “monolithic” approach. Back then, making even small changes to an existing app would require a fresh wholesale version update with its own quality assurance process, increasing the app’s deployment time and the workload of multiple contributing teams. If these updates introduced errors, then the whole app would have to be taken offline, deconstructed, and fixed. 

For growing enterprises with multiple business areas, flaws in monolithic architecture can cause downtime across the breadth of your services—a risk that could be unviable to take.

Monolithic vs. microservices

Monolithic apps are built as one central unit, with all functions sharing the same runtime environment. Microservices, on the other hand, break down the environment according to function or business area, and separate development teams take ownership of each service.

What is service-oriented architecture? 

Service-oriented architecture (SOA) emerged in response to these inefficiencies. SOA structures apps into separate components that communicate through an enterprise service bus (ESB), which provides business logic using a business process language (e.g., BPEL). Meanwhile, individual services are each organised around a specific business process and adhere to a common XML-based communication protocol (e.g., SOAP) for sharing via the ESB. 

While SOA allows developers to build, test, and refine each service as needed, the heavy SOAP protocol and XML payloads would limit the technology to support all use cases. The ESB is also a single point of failure for the system; issues with the ESB can disrupt the entire suite of apps, diluting the benefits of a faster development cycle.

SOA vs. microservices

While SOA components talk to each other using an enterprise service bus—which creates a single point of failure—microservices use APIs to communicate with each other.

Where do APIs fit in?

In 2014, microservices surged in popularity after the publication of “Microservices”—a foundational positioning article by James Lewis and Martin Fowler. In it, the authors provide a thorough definition of microservices architecture and contextualise how it evolves from SOA: as an alternative to the ESB, microservice components talk to each other via APIs, which also allow for integrations with third-party apps. 

That same year, we saw the release of Spring Boot—a defining, Java-based open source framework used to create microservices and provide a faster way of developing applications. The following release of Spring Cloud 1.0 crystallised the popularity of microservices, giving the Spring and Java development communities access to the architecture principles that Netflix was early to champion.

Microservices and APIs

Microservices are an architectural style for app development that give you the option of offloading functionalities to third-party systems. APIs are what allow these microservices to share information with each other. They act as doorways for internal and external developers to access the data of a microservice or use its functionality.

Many of today’s leading companies are built using microservices, and they harness the API economy and developer communities to provide advanced and highly integrated services. A rideshare app, for instance, may use Stripe APIs for payments, Google Maps for mapping technology, and Twilio for sending text messages. 

By using APIs, microservices architecture gives developers the opportunity to offload functionalities and enrich their apps with services from industry experts. In the above microservices architecture example, the company can use Okta’s Authentication and Authorisation APIs to embed secure identity and access management to its app.

How does microservices architecture work?

While there’s no universal model or style, many microservices share the following characteristics and therefore work in a similar fashion:

• Multiple components: Each individual service in this structure can be deployed, refined, and redeployed independently without compromising the whole application.
• Structured around business units: Organizationally, microservices typically revolve around business capabilities and priorities. Each team takes ownership of making a specific product or service work and incorporates a cross-functional mix of skills to do so. This contrasts with monolithic development, where teams each focus on a function for the whole app suite.
• Simple routing: Microservices use APIs as a lightweight means of receiving and processing requests, and issuing responses. This eschews the complexity of using ESBs, which often rely on advanced systems for routing messaging and applying business rules.
• Decentralisation: Microservices incorporate a variety of technologies and platforms, making them ill-suited to centralised governance. As microservice developers often aim to produce useful tools that others can use to solve problems, they typically consider decentralised governance to be favourable. Microservices also favour decentralised data management, where each service manages its own database.

What are the benefits of microservices?

Microservices architecture brings a variety of benefits to your development process, including:

• Agility: A small, independent team of developers takes ownership of each service. This empowers each team to act autonomously and issue updates faster to the service they’re responsible for, shortening the development cycle
• Scalability: As a network of small components, each service can be scaled independently to meet the demand for the application feature it supports. This helps teams to accurately measure the cost of a feature, plan around infrastructure needs, and support availability if a service sees a spike in activity.
• Specialisation: Each microservice is designed to provide a certain set of capabilities and to solve a specific problem. To that end, there’s no uniform approach to designing microservices—developers are free to choose the best tools to solve each problem.
• Easy deployment: Since microservices are modular and support continuous integration and delivery, it’s relatively easy to update code, experiment with new ideas, get new features to market, and rollback updates if something doesn’t work.
• Flexibility: Developers can use services written for certain functions as the building blocks for other features, and also have the flexibility to use public APIs to integrate functions from third parties (e.g., Twilio, Okta, Stripe). As a result, developers can create new capabilities without writing code from scratch.
• Evolution: Microservices architecture is evolutionary, making it ideal for systems where you can’t fully anticipate the types of devices that might access your app. Many apps start based on monolithic architecture but gradually revamp into microservices that interact through APIs.

What are the drawbacks of microservices?

Despite the benefits of using microservices, it’s important to be aware of the challenges:

• Maintenance: While the failure of one service won’t impact the entire system, each service individually is at risk. As a result, microservice apps require constant monitoring to detect failures quickly and restore services as soon as possible. Stress testing each service is also advisable to test its resilience and monitoring capabilities.
• Security: Each separate service represents a point of risk, so you need to effectively secure each microservice for your app to be truly secure. This means using products like Okta’s Advanced Server Access to provide authentication and authorization support to secure the infrastructure behind the scenes of your app. 
• Identity and access management: With microservices, users sign in to multiple APIs instead of a single service. These user identities often exist in disparate directories, with duplicated profiles that contain contradictory data. Users need to be authenticated and authorized across these distributed components, and while each microservice needs to function independently, it’s risky for each component to secure identities itself.

What does the future of microservices hold?

As microservices architecture continues to evolve, here are three advancements we see becoming increasingly prominent:

Serverless architecture

Today, developers can deploy code in serverless providers that execute code on-demand without requiring developers to think about server capacity, redundancy, and runtime environment. This helps developers rapidly build, test, and deploy new services without the need for large upfront investments. AWS Lambda and Google Cloud Functions currently provide these services to developers.

Edge computing

Edge computing aims to improve performance, reduce latency, and enable microservices applications to run more efficiently and with increased processing power. Edge computing takes advantage of modern technologies like Single Page Applications (SPAs), and Content Distribution Network providers like Cloudflare and Fastly to bring services closer to people.

More opportunities for creativity

Microservices architecture has proven compatible with community development and reiteration. As the public API economy continues to grow, and more code is written as reusable across different services, we expect developers to gain access to a growing number of resources they can use to embed new and interesting features into their apps.

Getting started with microservices

While there’s no one way to get started with microservices, we’ve got a comprehensive library of resources to help you build and secure your apps.

Check out the following to learn more about microservices architecture and how to secure it:

• Okta Developer Blog (Microservices tutorials and guides)
• GitHub (Projects and example apps)
• Security Patterns for Microservice Architectures (Blog post)
• Advanced Server Access (Product page)