buchachon - Fotolia

Tip

How to design APIs for hybrid cloud architecture

Hybrid cloud is complex, particularly because it's the application -- not the server -- that manages API flows. Review some strategies for API management in a hybrid scenario.

Every enterprise will likely use a hybrid cloud model in some capacity, so development teams need to consider how to approach building software for this environment. Developers should explore common hybrid cloud architecture models, which will ultimately lead them to the specifics of hybrid cloud API design and management.

As a baseline, there are some standard API practices. First, architects should prefer RESTful APIs overall, including in hybrid cloud environments. Second, they should use the GET method only to inquire and not to do something that represents an update or, in stateful services or microservices, brings a state change. Only use POST, PUT or DELETE for updates and state changes. Third, support field selection so all API users don't have to provide all possible fields in the data model of the API. Finally, use a recognized data packaging approach -- JSON for Java implementations, or XML.

If you prefer to start API design with a design pattern, consider the pattern titled API Management for Modern Hybrid Ecosystem. This pattern harmonizes a microservice front end with a traditional application back end by using a service bus or message queue as the linking element. Because most enterprise hybrid cloud applications don't rebuild the back-end business applications, this pattern is a good framework to assume as your overall model. Then, consider the microservice APIs in your cloud portion based on the adopted specific application model.

Microservice frameworks

APIs for microservices deployed in a hybrid cloud architecture should satisfy microservice deployment's basic requirements -- supporting scalability and discovery -- and also be based on a common microservice framework.

A microservice framework is a class of middleware that creates a uniform platform on which to run microservices. The framework's goal is to simplify and harmonize the implementation of common elements. This is critical to speed microservices development and deployment without introducing a major operations burden. Microservice frameworks are typically aligned with the specific application model, such as web front-end or event processing.

Frameworks divide into two categories: proprietary, like Microsoft's .NET, and cross-platform, such as Java. The most popular frameworks for hybrid cloud front-end APIs are Dropwizard, Micronaut, Moleculer, Restlet, Spark, Spring Boot and Vert.x.

Frameworks don't change the basic structure of the API, but they do have features that can be set to specialize the API's implementation according to preference. Therefore, it's important to look at how each of the frameworks balance their features, which could influence the way you implement your APIs.

Most of the frameworks can support any level of service, microservice and even monolithic structure. Restlet is the most general framework, and Micronaut is the newest and likely the most microservice-specific. Moleculer, Vert.x and Micronaut are generally considered the best for high-performance applications. Meanwhile, Spring Boot is the most popular of the group.

Resource pool and service mesh models

The next most popular model for hybrid cloud architecture is the resource pool model, where components deploy in either the public cloud or the data center -- or both, depending on conditions. This model requires more control over both the APIs and the implementation. When used by components that can deploy in either a cloud or data center, data resources must reflect the delay and cost associated with crossing a cloud boundary, and API implementations may require more extensive security features.

If your pooled resources are front-end elements to current transactions, but more portable in hosting terms, then your setup qualifies as a web front-end model, to which this advice doesn't apply.

Resource pool microservices that aren't front-end-related don't necessarily need a weblike framework. Therefore, developers may not want to write them in Java or use JSON to package data. However, RESTful API structures can help to ensure traffic passes through firewalls and frames your interactions in a stateless way. To maximize agility, try not to use the same API to represent multiple microservices, because this can force the need to scale and redeploy in synchrony.

For this microservice application model, consider adopting a service mesh. Think of a service mesh as a heavyweight model of a microservice framework that provides nearly everything but the actual microservice logic.

The two most popular service meshes available are Istio and Linkerd. But two versions of Linkerd exist, and its latest one -- based on Conduit -- is most comparable to Istio. Of these two common service mesh services, many expect Istio will prevail to become the Docker or Kubernetes of the service mesh market.

A service mesh frames service-to-service communication and discovery, so it's most valuable in a complex hybrid environment workflow or where components deploy in different hosting environments in an elastic or variable way. All service mesh technologies will introduce overhead in the movement of work. They affect performance relative to a simpler microservice framework, especially one designed for higher performance.

It's worth considering an API manager for hybrid cloud deployment, but whether you actually need one may depend on the specific hybrid model. If the hybrid cloud treats public and private resources as a single pool with at least considerable bursting or redeployment across the hybrid boundary, then it may be useful to have an API manager. Apigee is a popular API manager approach, and it also can link with Istio.

Event-driven application scenarios

Event-driven applications fall into two categories. There is IoT-like real-world event processing and reactive programming, where all services are dynamically coupled by an exchange of messages, as opposed to being orchestrated into a fairly consistent workflow.

Cloud providers often include microservice frameworks for event-based applications in their serverless computing or managed microservices features, but Akka is an example of a useful independent framework. It's a lightweight message-coupling framework that imposes less structure on implementation.

Most of the previously mentioned microservice frameworks can work for event-driven applications. But focus on frameworks, such as Micronaut, Molecular or Vertx, because they're designed to be high-performance, like Akka. Micronaut said it offers a combination of performance and features, but it's relatively new, so take care to assess its current capabilities and level of support.

Dig Deeper on Enterprise architecture management