Microservices

API Best Practices: Microservices

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

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.

Trustpilot uses out-of-the-box, fine grained analytics and reporting capabilities available in an API platform to measure API usage, developer and partner engagement, microservices adoption, and traffic composition. Organizations use API analytics to monitor API performance by analyzing total traffic, throughput, latency, and errors.

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.

Continuous integration / continuous delivery processes and tools help organizations benefit from microservices. This makes it easy to independently deploy microservices. Amazon, for example, deploys code to production hundreds of times of day.

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.

To learn more, read the Apigee eBook, "Maximizing Microservices."  

Connecting Microservices and APIs to Business Value

My company, HP Inc., is a “new” company—the world’s largest startup, if you will—having formed last November upon the separation of Hewlett Packard Corp. So we’re still building out our company’s publicly-visible API-product stories and developer assets on our developer portal at https://developers.hp.com (HP PrintOS, for example, has its APIs documented here, among other assets).

Our culture is rooted in engineering (“Keep Reinventing” is our motto), but it isn’t always easy to connect the nuance of containerized microservices, for example, to efficiencies in product lifecycle or customer delight. Platform thinking, where well-documented patterns, and automation help projects integrate vertically through technology layers, helps us keep on course.

But we still ask the question: how do our software platforms and their APIs best support our new business ambitions, from executing on product strategy all the way to measurable customer success?

The nimble mindset

A frequent challenge is identifying the appropriate opportunities, both in product thinking and in underlying architectures, to ride the wave of API-exposed services and microservices thinking—and to compete. The hill where I plant my flag is the one where our company’s solutions are developed with a nimble software-product mindset, as opposed to a classic scheduled-project approach.

That means a dynamic backlog, all those “agile” behaviors we know and love, and a serious embrace of the customer’s intent while constantly listening for actionable feedback. And, those patterns must always be balanced by a strong product manager’s will to articulate the product’s identity, vision, and roadmap.

Rolled up, business agility is what I prefer to call this network of ideas. Through CI/CD, through test automation, through cloud- and API-driven infrastructure deployment (especially via containers), and through an open-platform mindset, we are accelerating toward viewing each other’s web-services as approachable and accessible—and more open for business than ever.

APIs: beyond tactics

With APIs at the center of our work, I believe this mindset holds doubly true. APIs aren’t just a tactic or a box to check on the design-spec of a new service. Rather, APIs are, I believe, the product—the face of a company’s services to the developer community. Done well, led with a product manager’s mindset, and promoted with savvy enthusiasm, APIs are where ecosystems arise.

Evan is a platform architect and engineering lead for cloud-computing practices and business delivery at HP Inc. His team is helping build out HP’s API and SDK portfolio at https://developers.hp.com.

Developers Who Use Their Own Products Build Better Products

I have always admired Google :). The company delivers kick-ass technology, but it also delivers a kick-ass experience. Take Google Docs. Instant changes, no “Oh crap, I forgot to Ctrl-S, I am screwed.” I’m typing this in a Google doc. While it’s not the only reason (or even the main reason), I do believe that an important reason for Google’s quality is that Googlers use their own product, and they’d never let an embarrassment go out.

Contrast this with enterprise software. I have built database technologies for decades—yet, for a long time, I never used it (I mean really used it, as opposed to testing or demoing it). This is true for tons of enterprise software technologies. The developers who build it and the developers who use it are not one and the same.  

What about open source software like Cassandra? Isn’t it built out of needs, and aren’t the developers who build it the developers who use it? Only partially. Apps use databases. Database developers build databases, whether it’s DB2, or Cassandra. Neat architecture, pretty bad user experience.  

Technologies that work well are technologies that are built and used by the same developers. No ifs, ands, or buts about it.

That brings us to what I am doing now. I am immersed in microservices and API management. There are some things our developers will never have a good feel for. SAML 2.0 for connecting to SAP R/3? How could a developer in a 300-person startup have that intuition?

We have to call upon general product management, security, and enterprise software knowledge to build something that we hope is functional and usable, and then have a good feedback loop. The developer building the technology and the developer using the technology are different.  

But microservices and APIs are different. We produce software for other folks to deploy APIs on. How do we do it? With small teams that aspire to the right set of microservices principles. With clean APIs. Each service needs to scale up and down.

The deployment of these services can have errors, so we have to implement the right blue-green deployment infrastructure. Teams are independent, so they need clean APIs, with documentation as contracts between them. Our developers employ microservices and API best practices. The software they build is a reflection of what they need, day in and day out.

Whenever you evaluate software, ask the vendor: “Do your developers use it?” It will help you make better decisions.

Image: The Noun Project/Kevin Augustine LO

Are ESBs Relevant in the Age of Microservices?

Webcast replay

Centralized control over a monolithic IT architecture is giving way to agile microservices that are easily consumable and scalable. How should businesses in the middle of this transition think about the move to microservices?

Nikhil Hasija, CEO of cloud services orchestration provider Azuqua, joined Apigee's Alan Ho to share how companies make the transition and gradually shed older toolsets.

This webcast replay covers:

  • a brief history of ESBs, API integrations, and microservices 
  • best practices for creating and consuming microservices
  • how to empower self-service through distributed management
  • recommended tools and technology to help with microservices implementations

 

 

What's Better Than Microservices? Serverless Microservices

Webcast replay

Autodesk is transforming its services architecture to lightweight microservices using a combination of Amazon Web Services and Apigee. In this webcast replay, Autodesk technologist Alan Williams and AWS solution architect Asha Chakrabarty join Apigee's Alan Ho to discuss:

  • real-world microservices examples
  • how to use AWS Lambda and Apigee to build serverless APIs
  • how to manage microservices in the cloud

 

The Internet Doesn't Run on a Bus—Your APIs Shouldn't, Either

There is no bus in the internet. It is the caller’s responsibility to make the right call. Yes, there's a broken link or two on the internet, but then one of the two parties fixes it and the problem doesn't last too long.

The world of internal APIs looks like the figure on the right, not the one on the left. Don’t move into the future using a bus architecture. DON’T.

  • The scale of thousands of microservices and billions of internal calls rules out the monolithic architecture on the left.
  • Connectors are legacy; every service will expose clean, RESTful APIs.
  • Orchestration is pushed to code and logic within the services; what remains is much less onerous.
  • Stable interactions are less common; things change in months, not years.
  • Centralization of interaction is an antipattern

Keep your current integration architecture. Definitely. But build your future around APIs, and not integration architectures masquerading as APIs.

For more on this topic, check out the eBook, "Beyond ESB Architecture with APIs: How APIs Displace ESBs and SOA in the Enterprise."


Thoughts? Comments? Questions? Join the conversation (or start one) in the Apigee Community.

 

The 12 Goals of Microservices

In a previous post, we suggested that microservices are essentially implementation components that communicate with each other using network protocols. Understanding what they are is helpful, but, to some extent, it also misses the point. More important is what microservices enable us to do.

Here are twelve goals that we are trying to achieve with microservices:

  1. Independent deployment of components
  2. Independent scaling of components
  3. Independent implementation stacks for each component
  4. Easy self-serve deployments of components
  5. Repeatable deployments of components (external configuration management)
  6. Deployments without service interruptions
  7. Protection of system availability from individual Instance failure
  8. Automatic replacement of component instances when they fail (self-healing)
  9. Easy scaling of components by adjusting a simple parameter value
  10. Canary testing
  11. "Red/black" or "blue/green" deployments
  12. Instant reversal of new revision deployments

Breaking your application into microservices does not by itself deliver these benefits. Several specialized run-time and tool environments—including Mesos/Marathon, Kubernetes, and Netflix OSS—have emerged to manage microservices.

Numerous other teams have rolled their own. Most of the value lies not in microservices themselves, but in these supporting runtime technologies and tools—they are what deliver on the 12 characteristics. If you’re spending significant time worrying about the difference between a service and a microservice, or the relationship between microservices and SOA, you are looking in the light, but under the wrong lamppost.

The microservice runtime environments mentioned above use a combination of patterns and technologies to deliver the 12 characteristics. Although there are differences between them, their fundamental approaches have much in common. In that commonality, you’ll find a significant new architectural style for deploying and managing larger systems. It is this architectural style that makes microservices interesting, and merits the introduction of this industry term.

Why are microservices not just SOA done right? Join the conversation on this topic on the Apigee Community.

To learn more, read the Apigee eBook, "Maximizing Microservices."

Image: Flickr Creative Commons/Terence Lim

Microservices: A Bad Name for a Good Idea

Although the word microservices is in broad use, there isn’t much clarity on what it means. Microservices are not about services and are not about being small, so it’s not surprising there is some confusion.

Microservices are a way of dividing the implementation of an application into a set of components. Microservices are not about identifying a function that is common to multiple applications, and creating a single, shared deployment of that function.

An accurate, if clumsy, name for microservices would be "network protocol-based components." The "network protocol-based" qualifier is important because an essential characteristic of these components is that they talk to each other using the sorts of distributed network protocols that are used for communication between physical or virtual machines, or between isolated containers within a machine.

Replace "microservices" with "HTTP component"

In principle, any network protocol can be used for communication between microservices, but the vast majority use HTTP. Because of this, it is usually correct to mentally substitute "HTTP component" for "microservices" in discussions. If you do this, you’re likely to get better insight into the uses, benefits, and challenges of microservices.

So why did we end up with the word microservices? Because these components—like all components—expose some sort of API to one another, they can be viewed as offering services to each other, and so they can be called services. While this is true, it is not their most important characteristic. The fact that they are implementation components is more illuminating.

How "micro" is micro?

The "micro" modifier was added to the term to indicate that these components only offer services to other components of the same application—if they offered services to multiple applications, they would just be regular services.

Many people have mistaken the term "micro" to mean an indication of size rather than scope, which has led to a lot of discussion about what the ideal size of a microservice is. This is equivalent to discussing the ideal size of a component in general, which is about as useful as discussing the ideal length of a piece of string. By definition, microservices are smaller than the larger application of which they are a component, but other than that their size is not very relevant.

Understanding what microservices are is a first step to understanding what they are about. To get a full understanding, we have to look at what we do with them, and how that is achieved, as we'll cover in an upcoming post on the 12 characteristics of microservices.

Are microservices really just small services? Join the conversation on this topic on the Apigee Community.

Image: Flickr Creative Commons/frankieleon

Is Microservices SOA Done Right?

Webcast replay

How does microservices differ from the service oriented architecture we saw a decade ago? Find out in this webcast replay, in which Pivotal's Matt Stine and Apigee's Alan Ho discuss:

  • real-world examples of microservices best practices
  • microservices anti-patterns and traps
  • recommended tools and technology to help with microservices implementations

 

gRPC: The Story of Microservices at Square

Webcast replay

Square's Manik Surtani joined Apigee's Alan Ho to discuss the mobile payments and merchant services provider's collaboration with Google to launch gRPC, an open source RPC framework backed by protocol buffers and HTTP/2 and based on real-world experiences operating microservices at scale. If you build microservices, this webcast is for you.

Manik and Alan discussed:

  • a technical overview of gRPC 
  • use cases and applicability in your stack
  • a deep dive into the practicalities of operationalizing gRPC
  • Square's experience moving from a proprietary RPC framework to gRPC