How do you kick off building microservices? Like any new project, you’ll start by thinking through the larger distributed system. By “design,” we mean the pipeline to come up with plans or specifications to construct this system.
Consider: What do you want the individual service to do? What is the business case? Who is the user (alternatively, what are the different user personas)? How does the node fit within the broader ecosystem? What data do you have, and what do you need? These design choices will set up long-term success for the microservice.
You will want to come up with a list of capabilities that this system will have. Then you can break down these capabilities into the roles of the different modular services, as required by your system.
If you begin to build without the appropriate design, it becomes difficult and costly to go back and redefine service interactions and data structures.
When you’re writing out specs, as well, you ought to think about application programming interfaces (APIs). The microservice will be delivered through API calls, so your service and API must work well together.
Some potential microservice architecture design tools and services include:
This free diagram-making software can help you visualize your architecture, network diagram software, and create UML online. The useful program is easy to customize and easy to collaborate on. Plus, you can save the visualization right on GitHub or GitLab.
GraphQL is an open-source query language that’s particularly helpful for APIs. It is a strong-typed system that defines the capabilities of an API. The defined structure loads data from a server to a client — it's a way to get data into your application quickly, without over-fetching or under-fetching.
In application development, this structure allows frontend and backend teams to work asynchronously: Frontend teams can test their applications by mocking the required data structures, and once the server is set up, flip the switch to let the client apps load data from the actual API. There are a few GraphQL client libraries available for developer use.
The OpenAPI Specification, previously known as the Swagger Specification, is a format to describe, develop, test, and document REST-compliant APIs. (REST APIs are APIs that conform to the design principles of the REST, or representational state transfer architectural style. They’ve become a standard for designing web APIs in the past few years because they provide a set of rules that can deliver fully functioning web services.) It's operated by the OpenAPI Initiative (OAI), under the umbrella Linux Foundation.
OpenAPI documents are human-readable, which enables anyone working on the project to easily determine how each API works. They’re also machine-readable, and can be used by: 1) documentation generation tools to display the API; 2) code generation tools to generate servers and clients in various programming languages, and 3) testing tools, plus many other use cases.
gRPC is a universal open source high-performance Remote Procedure Call (RPC) framework that can run in any environment. This communication protocol is an alternative to REST APIs. It’s a lean platform using a lean transport system to deliver lean bits of code: in particular, the communication between microservices happen through stubs that gRPC handles.
gRPC can efficiently connect services in and across data centers with support for load balancing, tracing, health checking and authentication. It also has multilingual support (Java, Python, Go, C++, and more). Major companies such as Square, Lyft and Netflix have adopted gRPC for microservices communication.