The Movement toward Microservices
Microservices fever has swept the application development world, and there are good reasons for it. Implemented properly, microservices architecture can make it possible to deliver systems that are more scalable, more resilient, more flexible, more efficient, and can be delivered with greater speed and agility than traditional, monolithic application architectures.
But microservices-based design is by no means a cure-all. This more loosely coupled architecture introduces new challenges not present in traditional development. That’s why, even more so than in other areas of software development, it’s essential to approach microservices architecture with an API-first mentality.
A service by any other name
First things first: What are microservices? The truth is that there is no firm definition. For those completely unfamiliar with the term, the excellent guide by James Lewis and Martin Fowler makes a fine starting point. In a nutshell, though, “microservices” refers to a style of development in which a single application is composed of a number of lightweight, loosely coupled services – as opposed to the traditional, monolithic development style, where all features and functions of an application are contained within a single logical executable.
API management is indispensible when managing the lifecycles of APIs
If you think this sounds a lot like service-oriented architecture (SOA), you are not off-base. Microservices and traditional SOA share some core ideas. (And strictly speaking, the idea of composing applications out of multiple small components dates back to the core design principles of Unix, if not earlier.) Where the microservices approach differs from traditional SOA is that it’s more dogmatic about keeping services small, purpose-built, decentralized, and independently deployable and scalable. By comparison, too many so-called SOA deployments have ended up as little more than a group of monolithic applications stitched together with an enterprise service bus (ESB).
Microservices architecture is useful because it makes development more agile and flexible. When a certain component of an application needs to be updated, it’s no longer necessary to rebuild and ship the entire application; just that one service can be replaced. Similarly, the consumers of a given service need not know its full implementation details, so stakeholders of individual services can maintain them as they see fit, even coding in different languages if they choose.
The trade-off for all this flexibility, however, is that microservices architecture lives or dies on the ability of developers to expose program logic as services in ways that are consistent, discoverable, composable, and secure. That’s often easier said than done, which is what makes maintaining clear, consistent, well-managed APIs so crucial to this style of development.
Serving up APIs
Even within monolithic applications, APIs are the means by which developers invoke functionality found in linked libraries and components. Because of the decoupled, decentralized, and distributed nature of microservices, however, APIs effectively become the core feature of this style of development, bringing the various components together in an easy to consume manner. APIs can hide the complexity of the microservices, to provide a uniform interface that can be manager.
The heightened importance of APIs in the microservices model necessitates a few shifts in thinking on the part of developers. The first is that development teams must recognize that APIs are products and the consumers of those APIs are their customers. The customers maybe internal to the company or external consumers of APIs.
Because of this, an API, once published, cannot easily be changed. It becomes, in effect, a contract with its customers. For this reason, the microservices approach requires that APIs be designed from the outside-in, crafting the “public face” of the microservice with its outside customers in mind.
Developers must also be conscious that managing these groups or fleets of services is seldom a trivial task. Depending on the granularity of the services being built, the proliferation of API endpoints can swiftly become too much of a good thing. An API management layer can come in handy here, by providing a consistent means by which APIs can be discovered, consumed, secured, monitored for performance and usage, and so on.
Finally, API management is indispensible when managing the lifecycles of APIs. Strong management allows APIs to be changed and improved continually while simultaneously allowing old versions to keep functioning, minimizing disruption for users and providing easy mechanisms for them to migrate to new versions when they’re ready.
Step up your API game
Of course, there’s never just one way to approach a challenge, and microservices won’t be the solution in every case. For one thing, it can often be difficult to decide how big services should be and what functions belong in which components. A bad design can lead to components that don’t compose cleanly, resulting in applications that are brittle and difficult to maintain.
Even if you’re not ready to leap feet first into microservices, however, you can still get a toe in the water. One common pattern is for organizations to develop applications that are modular, so that functions can be split off into microservices down the road to improve performance, scalability and reliability.
The key to this approach? You guessed it: thinking in terms of APIs. The lesson to learn from the successes of the microservices movement is that an API-first mentality is a powerful approach that can help developers of all types of software build code that is more reusable, create products that are more flexible and agile, and innovate more quickly for faster time-to-market. It’s hard to argue with any of those benefits.