API Best Practices: Microservices

How to ensure the rush to microservices doesn’t create silos with inconsistencies

skoppala

Sep 30, 2016

In a previous post, we discussed best practices in API security. Here, we’ll cover the important role an API platform plays in managing microservices architecture.

Nearly 70% of organizations claim to be either using or investigating microservices, and nearly one-third currently use them in production, according to research from NGINX.

Why? Because microservices enable businesses to innovate faster: development teams can independently develop, deploy, and scale components of large applications. The adoption of the cloud, containers, and continuous integration/continuous deployment (CI/CD) tools has made microservices implementation much easier, leading to more and more modern software being built as a set of microservices.

App development teams implement microservices using a variety of microservices stacks like Kubernetes, Netflix OSS, and Mesos, depending on their needs. All these microservices use web APIs as the mechanism to communicate with one another.

There’s a challenging side effect, however. As app development teams rush to implement microservices, they inadvertently create silos with inconsistencies in security, visibility, documentation, and governance. Many of the APIs that connect microservices are not secured consistently across the organization.

They might not be accompanied by standardized documentation, or access control mechanisms. These microservices and associated APIs are often difficult to reuse, analyze, or even to discover for use by other teams.

How do organizations wrangle with this problem? Many organizations implementing microservices use API management platforms to deliver consistent security, visibility, and improve discovery and reuse of microservices and APIs.

Secure and monitor your microservices

When it comes to security, there should be no distinction between internal and external APIs. A microservice could be used by another app in the cloud today and an external partner tomorrow. Teams implement APIs with varying levels of security. Some deploy microservices in the public cloud, neglect to deploy common API security standards or consistent global policies, and expose the enterprise to potential security breaches.

Companies like TrustPilot and Autodesk assume a zero-trust environment for microservices. They use API platforms to implement security and governance policies like spike arrest, injection threat protection, and OAuth2 across all of their microservices APIs.

Transition to microservices transparently

For many who adopt microservices, initial projects involve decomposing existing monolithic applications into microservices. Often, many applications take advantage of services from your monolithic apps. So transitioning to microservices has to be done in a way that’s not disruptive to other applications and developers using the monolith’s services.

Magazine Luiza, a fifty-year-old retailer in Brazil with more than 700 stores and 43 million customers, created a modern API facade with an API platform to deliver modern (RESTful, cached, and secured) APIs for the monolithic app’s legacy SOAP services and to securely expose the new microservices. This enabled mobile and web app developers to keep innovating despite the underlying transition to microservices.

Remove barriers to consumption

As app development teams implement microservices with disparate runtimes and tool environments, it can be difficult for other teams to discover and reuse these microservices.

Organizations like Autodesk use a developer portal to enable internal and external developers a single place to easily discover APIs, access interactive documentation, consume microservices, and measure performance and usage.

Gain insights into microservices usage

Without data about the usage and performance of microservices in an organization, it’s difficult to get the full benefits of this architecture. The problem is especially acute when microservices are used by other teams in a large enterprise or as external APIs for partners and customers.

Manage APIs beyond microservices

Beyond microservices implementations, organizations tend to have many APIs that expose legacy services that are used by variety of apps. These APIs might have inconsistent security, limited (or a lack of) API documentation, poor version control, and limited reusability. All of this leads to confused developers and reduced agility—the very opposite result you expected from employing microservices.

Organizations like Belly, Autodesk, and TrustPilot use API management platforms to not just manage microservices APIs, but all of their APIs. A distributed API management platform enables you to deploy and run your APIs close to your application and microservices environments, while enforcing consistent security and governance policies across all your APIs. This approach gives you a single pane of glass to monitor and manage all APIs across microservices and other monolithic apps.

Organize for success: Beyond technology

Organizations that have successfully executed microservices projects have also adopted modern software development practices.

Two-pizza teams are small, independent, and cross-functional, and they focus on delivering just a few microservices. This approach was championed by Amazon and proved to be useful in ensuring effective communication within the team and driving agility. Netflix has more than 500 microservices delivered from more than 30 independent teams.

Agile/scrum methodologies deliver functionality faster rather than the lengthy waterfall development processes. As the pace of arising business needs has increased significantly, agile scrums enable IT to deliver software that better satisfies those needs.

Using microservices, innovative organizations have found a path to enjoying the agile benefits of building software fast, while enabling the reuse of shared services. Getting started the right way requires a consistent security, visibility, and discoverability framework using an API management platform.