What Are Microservices?

What are microserivces?

In short, they break large applications down into small  services. Microservices enable advances in agility and flexibility for developers. But microservices architectures are not exempt from challenges. In the following paragraphs you'll learn about how microservices work and cite examples and suggested practices to help ensure the successful adoption. We will also discuss the role of APIs in microservices architectures. And look at how helpful an API management platform can be.

Background reading >>What Are APIs?, What Is API Management?

Microservices Basics

Microservices define both an abstract concept and a set of concrete objects. At a high level, the microservices pattern is a new way to build applications. It consists of sets of independent microservices implementations. We will try to focus on describing the concept as the microservices pattern, and the concrete service implementations as microservices.

The microservices pattern represents an approach to creating applications. It combines the concepts of service-oriented architecture (SOA), containerization, and DevOps. The pattern combines the principles of SOA with bounded contexts to create small, autonomous microservices. They work together to efficiently scale overloaded systems. Microservices are most commonly built by small agile teams, using continuous integration and delivery. These teams often leverage containerization for rapid deployment. As a result, the microservices pattern enables scalability, speed, efficiency, and agility.

Let’s get a clear sense of how microservices work best and the ways to implement them. When we look at the leading trends in enterprise architecture, the microservices pattern presents a bucket of opportunities along with some challenges. Implementing a successful microservices architecture can mean rethinking a number of enterprise architectural workflows. 

What Are Microservices, Exactly?

The microservices pattern breaks a large application down into small, independent services that are not language-specific. It offers IT organizations tools for agility and cost reduction. This assumes the organization is sufficiently mature to be able to follow the core guiding principles.

The term “microservices” refers to a style of software architecture where complex applications can be composed of small independent services. The independent “services” (or processes) exchange data and procedural requests. Microservices implementations use application programming interfaces (APIs). They use events that are most likely standards-based and language-agnostic. Regardless of the language used within your organization, you can implement a microservices architecture.

Microservices use lightweight communications protocols and are highly focused on providing one capability. The “micro” refers to narrowness of focus, not size. They are usually built by small “Two Pizza” teams to ensure adequate focus on the capability.

What Are Microservices vs. SOA?

Microservices versus SOAs are unique, but similar. They exist at the intersection of SOA, the mashup of agile development and IT operations known as DevOps and containerization. Figure 1 shows this concept as a Venn diagram. However, microservices go beyond the actual architecture. When you combine fast-moving software development that uses principles of SOA and containers, those are microservices.

Microservices differ from SOA. Although the two architectural styles share a common history and a number of traits. SOA was designed to be technology-agnostic. But over time SOA has become very standards-and-vendor-driven. Vendors drove SOA down the path of SOAP and enterprise service buses (ESBs). While microservices reaffirm many SOA principles, they are almost a reaction against that traditional vendor-driven SOA. The heavy SOA architecture is the opposite of today’s lightweight microservices. Microservices are decidedly anti-ESB.

Related reading >>Steps to SOA

Microservices vs. APIs

Some people in the API world might argue that microservices are just APIs. But they are focused on solving very different problems. APIs are concerned with how to manage digital transformation and support a large ecosystem of developers and partners. They do this by making it easy for them to consume data or applications. They provide connectivity and integration for easier and better consumption of services. Often by web and mobile apps.

The difference between an API and a microservice is not based on technology. APIs and microservices are complementary. Microservices provide agility and scale to applications that are increasingly surfaced via APIs. Essentially, the API is the result of building an application and an application could be built using microservices.

Fundamentally, for api vs. microservices:

• SOA services are provider-centric, focusing on the re-use of business capabilities between applications.
• APIs are consumer-centric, focusing on enabling the consumption of business capabilities by external, partner, and internal developers.
• Microservices are application-centric, delivering specific capabilities for one application in a scalable, distributable manner.

Read more in our guide >>Microservices and APIs

Why Microservices?

Microservices enable IT organizations to be more agile.  And build more scalable applications. Microservices translate into faster development and change cycles. As Figure 2 suggests, breaking down a large application into smaller services makes the development workflow faster. Tasks can move more quickly through the microservice’s smaller funnel.

As a small development effort, a microservice can be built faster than the typical large-scale software development project involving a monolithic application. Microservices are more fluid. They move independently at their own pace. There are no waterfalls in the development process. They are the polar opposite of a monolithic application. Due to their independent nature, microservices can be developed using any programming language. And they have better variability. With containerization, microservices can be quickly deployed on-demand as part of a continuous delivery process.

Microservices failures are also less catastrophic. With monolithic apps, a failure in one part of a stand-alone application can take down everything else. A system-wide diagnosis may lead to releasing another version of the application to fix that particular error. In a microservices architecture, the function provided by the microservice may not be essential. Therefore it's quicker and easier to fix problems. The agility of the design helps you to identify, isolate, and compensate for errors. If you have a microservices architecture, you can scale microservices to overcome a performance constraint. Another attribute is being able to quickly build a new version of the faulty microservices. And to do so without dealing with the cumbersome operational cascade that usually exists within a monolithic application.

Microservices give you better reliability, range, and flexibility. For example, you can scale up any one part of your application. If a login is suffering because the system is getting too many new users, you can scale that particular part of the application with a microservices architecture. Before microservices, you would have had to stand up new app servers. 

With microservices, if you have a spike in logins, the microservices architecture provides a menu of elastic solutions. In this case, containerization allows IT to quickly deploy as many new instances of the login microservices as needed. And then load balance across them all.

Microservices: How?

Some architects believe migrating old applications to microservices means breaking existing applications apart. Then, those component parts go back together in a new way. This would streamline the architecture. However, architects should stop thinking of microservices this way.

The idea is not about taking monoliths and completely re-implementing them as a set of microservices. Rather, architects should look at isolating services that make sense to develop as microservices. And incrementally branch out from there.

The biggest impact of adopting a microservices pattern is organizational. When adopting microservices, the organization has to change structure and approach. Otherwise they will run afoul of Conway’s Law. Microservices require training and new skillsets. They affect design, development, and testing. Thoughtful staffing of the development and testing teams and scoping out of parameters will help inform design and implementation of microservices. This works best when ops are mature, including properly functioning DevOps APIs and competent adoption of containerization.

Secure the Edge API and Microservices Mesh

You can't risk malicious assaults or distributed denial of service (DDoS) attacks. That's why you need to secure the microservices mesh. In our white paper — Securing the Edge API and Microservices Mesh — we share exactly how to do this.

Get the White Paper

Microservices affects many familiar processes. The following table highlights key needs in the areas of development, data, and testing.

Martin Fowler and James Lewis provide an outstanding rundown on new skills and practices that IT organizations must master in order to succeed with microservices. In their view, the following concepts offer a solid idea of what and how to choose and implement the right kind of microservice. As Fowler and Lewis note,

“You can take a bad application and build a bunch of bad microservices out of it.”

 

If you consider the following principles, it is possible to avoid a bad outcome:

• Componentization via services: Knowing how to create an interface that leverages the best technology for the job, e.g. REST.
• Organize around business capabilities: Microservices need to be organized around distinct business capabilities. The microservices developer creates products not projects. Given that the service will have its own complete lifecycle, it's a matter of product management not software development.
• Deliver smart endpoints and dumb pipes: You will have to orchestrate or choreograph the different endpoints. Load balancing is built into the framework and the end points. The registry contains end points. The content has decentralized governance. The registry is built into the service itself. The data management will become decentralized, moving to a more functional domain-driven design context versus a traditional data model.
• Automate the infrastructure and design for failure: The architecture needs to be continually adjusting for and compensating for failure. Ideally, you build failure into the testing of the microservices infrastructure. This way while you’re doing testing, services fail. Containers disappear or shut down. Things start running more slowly. The infrastructure has to scale automatically.
• Design: Traditional design and the oversights that you had are no longer relevant. Everyone will use the best tools to create the microservice. You will need to control the microservice definition and the interface, but you cannot control all the moving parts of the process.
• Designing microservices the right way: You need to facilitate design time review of available services and find a way to force people to request the service. This is why you need to have a registry that enables people to look for services. If you don’t find them, then you have to request a new service or a new interface. At this point, somebody will say, “Yes. That looks like a good interface. Let’s build that as a microservice.” Of course, there will probably be some approvals to go through.
• Adopt conventions: You will need to adopt certain conventions around the interface that you are exposing. For example, you will need to have an end point. These conventions must be established around the design of your interfaces. Then the conventions have to integrate within your framework and infrastructure to enable making those lasting choices and decisions during runtime.
• Design for robustness: Microservices affect design and the design pattern. You might have a proxy end point, for instance, that enables you to do the routing and resiliency on the back end, with awareness of distributed data design and the main driven design around the data. Ultimately, data has to be separated into a microservice.

Microservices and API Management

The result of an application built using microservices is often an API. API management can ensure the reliability, security and performance of that API.

The Akana API Management platform provides the functionality to deliver applications as a series of microservices. The platform streamlines management, deployment, development and operation of APIs. It enhances microservices security and regulatory compliance through authentication, authorization, and audit capabilities.

In many cases the API Management platform, specifically the API gateway, can take the role of the ingress controller by distributing requests across a series of microservices.

Akana's platform lets users take advantage of lightweight container platforms for microservices deployment. At the same time, it provides the core capabilities required by an enterprise services environment. This includes central definition and management of security, routing, orchestration, mediation, auditing, threat protection and other operational governance policies across multiple instances. This makes it possible for microservices to comply with security policies. This is a common goal of many architects struggling to adopt microservices in security and compliance-intensive enterprises.

Akana gives administrators the ability to scale microservices independently based on real-time usage needs. Akana’s tools make it possible for IT to provide high-availability with load balancing over just enough redundant microservices instances to support load, should one instance fail. Users can create managed container instances for easy deployment of secure microservices, automating the registration and discovery of microservices instances with container configuration tasks.

Read more >> Akana's Microservices Solution

Conclusion

Microservices give architects a way to build flexible, scalable web-scale applications. They do this by breaking a large application down into small independent services. This process enables greater agility because changes and development can be executed faster. They are best approached incrementally, eating the elephant one bite at a time. Transforming entire applications into microservices is not an optimal approach. Given the technology’s impact on developing, testing and deployment, it is best to be selective about which application components should be first made into microservices.

The API is the application. Applications built using microservices architectures will often result in an API. For this reason, the choice of an API management platform is critical to making a microservices architecture function as envisioned. An effective API management platform can act as the ingress controller while simultaneously monitoring performance and providing security and governance.

Experience the Akana Solution

See how intuitive it is to use the Akana API management platform to handle your API and microservices needs with a 6-month trial.

Try Free

👉 Become an Expert

Explore additional resources:

• Performance Testing Microservices with JMeter
• API Basics
• Microservices and APIs

Note: This blog post was originally published as a white paper in November 2016 and has been updated for accuracy and comprehensiveness.