An intro to cloud-native microservices and how to build them

Defining cloud-native microservices

Cloud-native microservices refer to an application design strategy in which developers divide applications into a series of discrete units, called microservices. Each microservice can typically operate independently of the others, but the microservices share data and interact over a network to enable application functionality.

Microservices are inherently cloud-native, because cloud-native apps are based on microservices architectures -- that is, according to most definitions of cloud-native.

Microservices architectures have been around longer than cloud-native computing. Microservices started to become popular about a decade ago, whereas the term cloud-native emerged around 2015. Part of the reason developers conceptualized cloud-native as a distinct approach to application design and delivery was because so many applications were migrating to a microservices architecture.

Cloud-native is about more than just microservice -- distributed infrastructure and consumable services are also important parts of the equation. However, microservices are arguably the most important element of a cloud-native strategy.

That said, cloud-native microservices don't have to run in the cloud. Developers can use platforms such as Kubernetes to deploy them on premises.

Microservices pros and cons

Cloud-native microservices offer several benefits, including:

• Agility. Applications that run as a set of distributed microservices are more flexible because developers can update and scale each microservice independently.
• Resilience. Microservices applications tend to be more resilient because the failure of a single microservice won't usually cause the entire application to fail.
• Development simplicity. Microservices usually break codebases into smaller parts that are easier for developers to work with.

On the other hand, microservices pose some challenges. The biggest is that they increase application complexity. An application with more moving parts is more difficult to orchestrate.

For this reason, it's often not worth implementing microservices for relatively simple applications. These include applications with small codebases, and those with minor scalability or resiliency demands.

Build cloud-native microservices

Developers can implement microservices, as an architectural style, in a variety of ways. There is no one specific tool or methodology to create a microservices application.

There are, however, some general guidelines that are helpful to design and build cloud-native microservices.

Separate microservice codebases

While it's possible to manage code for all of microservices within a single repository, it's not a best practice. Manage the code for each microservice separately to simplify development as much as possible.

Deploy microservices independently

For similar reasons, deploy each microservice into production as a separate unit, rather than all at once. Otherwise, developers can't update one microservice without affecting the rest of the application.

Segment storage between microservices

Give each microservice its own storage resources, rather than have all microservices share a database or other persistent data store. While this model requires additional effort, it enables developers to tailor storage resources to the needs of each individual microservice. It also reduces the risk that one microservice will overwrite or corrupt data associated with another microservice.

Use an API gateway

Developers can design microservices to communicate directly with external endpoints. A better approach, however, is to use an API gateway as an intermediary.

There are two main advantages to using an API gateway with microservices. First, it simplifies microservices deployment, because microservices don't need to recognize the exact location of external resources; they just recognize where the API gateway is. Second, the API gateway can validate and manage requests, which mitigates performance and security issues.

Implement a service mesh

Microservices can share data directly with each other over an internal network. A better approach, however, is to use an intermediary infrastructure layer -- specifically, a service mesh -- to manage communications.

Service meshes manage requests between microservices. They're similar to API gateways, and they offer similar performance and security benefits. The main difference is that a service mesh handles internal communications, while an API gateway serves as an interface between microservices and external resources.

Use a microservices-friendly programming framework

While it's possible to write microservices in any language, certain languages or frameworks are particularly well-suited to cloud-native microservices architectures.

For example, if you prefer Java, consider a Java framework such as Spring Boot, which caters to this use case. Go's concurrency features and modular design model make it a good choice for microservices programming. C++ also works well for microservices development, given its concurrency support and fast execution. Fast execution reduces the risk of application delays caused by microservices that are slow to handle requests.