How to architect an application with microservices (part 2)

This 6-part series on microservices application development provides a context for defining a cloud-based pilot project that best fits current needs and prepares for a longer-term cloud adoption decision.

Gartner analysts recently emphasized the importance of doing cloud-native development as soon as possible after any initial migration of existing workloads.

Explore the Gartner report

Here in part 2, we lay out the common capabilities of an architecture for rapidly developing applications based on a microservice. You’ll need these capabilities whether you’re transforming a monolith or developing a cloud-native application.

For an overview of microservices and cloud-native, see “Microservices: A Complete Guide” and “Cloud-Native: A Complete Guide.”

A guide to the overall series

  • An overview of microservices (part 1), after providing context for business pressures requiring faster app development and delivery, steps through the process a team went through in transforming a specific monolithic application.

  • Architecting with microservices (this part) lays out the common capabilities of an architecture for rapidly developing applications based on a microservice.

  • Implementing a microservices application (part 3) provides a method for implementing your own microservices project.

  • Using microservices development patterns (part 4) presents common development patterns available for implementing microservices applications.

  • Using microservices operations patterns for resiliency (part 5) presents common operations patterns for achieving resiliency in your microservices applications.

  • Designing and versioning APIs (part 6) offers best practices for managing the interfaces of microservices in your application.

Common capabilities of microservices

Application components run as microservices in the cloud, communicating with each other through the microservices fabric. Though patterns differ depending on the type of application, all microservices-based applications include some common larger-scale components and capabilities.


Reviewing the diagram right to left, we note that the backend microservices are exposed via APIs and consumed through an API Gateway. An API Gateway can be as simple as a proxy of endpoints or more sophisticated; employing security at first contact, monitoring and API versioning, and full API management systems with a developer portal for third-party consumption.

Microservices success using DevOps

Creating a successful microservices architecture requires a strong automation strategy using DevOps, addressing provisioning and continuous deployment/release.

  • Provisioning: Each microservice component of your application runs in its own self-sufficient container. The cloud platform instantiates a container with each microservice and all its software dependenices, and orchestrates how the set of containers are assigned underlying infrastructure. For example, running a container infrastructure over an Infrastructure as a Service layer using Docker orchestration engines like Kubernetes or Docker data center automates how those environments provision containerized software over a virtual machine or bare metal server. Usually, a software development and operations team uses a vendor’s cloud platform as a service (PaaS), which manages all the provisioning complexity.

  • Continuous deployment and release: To rapidly iterate a microservices application, you must setup an efficient system for building and versioning Docker. With a multicloud strategy, your build and deploy automation needs to abstract away the differences in how you do things like auto-scale or apply cloud policies. IBM Cloud provides ready-made toolchains for doing so.  As with continuous deployment, your cloud platform must support a process of both test-driven development of functional units, environment validation testing, and automated functional and performance testing of the overall application.

Compute options for microservices

Depending on what best fits your application and workload, you can choose different compute options on a platform as a service. IBM Cloud offers this range of options for running microservices:


  • Docker containers provide the most portability across cloud and on-premises environments, and Kubernetes offers an extraordinary range of controls for managing the complexity of microservices applications running at scale.

  • Cloud Foundry is an open source platform that abstracts the microservices software from all platform operations below the runtime level. This provides a powerful advantage for teams with different levels of polyglot coding skills that don’t want to manage any runtime operations.

  • Serverless, based on Apache OpenWhisk, is an open source, event-based programming platform as a service that both abstracts operations and supports sequencing of small independent functions that run based on defined events, rules, and triggers. Developers deploy simple event handlers to respond to events that occur in the cloud platform. All virtualization is abstracted.

  • Virtual machines (VM) are another options for creating and running microservices-based applications that require much more manual provisioning and DevOps to succeed. VMs and bare metal offer the most flexibility.

To build microservices on a secure platform, read this guide for selecting a cloud provider.

Continue to part 3 for a method to implementing your own microservices project.

Additional resources:

Kyle Brown (IBM Distinguished Engineer/CTO) and Rick Osowski (IBM Distinguished Engineer/CTO) collaborated with Roland on this post.


More from devops

IBM Cloud Continuous Delivery Now Supports Event Notifications

2 min read - We are pleased to announce that IBM Cloud Continuous Delivery now includes a tool integration with IBM Cloud Event Notifications. This integration allows administrators to configure toolchains to send notifications of events in a toolchain or a tool integration to other users or human destinations. In addition, these event notifications can be sent to other applications (such as IBM Cloud Functions) to build logic by using event-driven programming using webhooks, for example. With the new Event Notifications integration, toolchain administrators…

New Java, Python and Node SDKs and APIs for IBM Cloud Continuous Delivery

2 min read - We are pleased to announce the general availability of new language support for Toolchains-as-Code capabilities in IBM Cloud Continuous Delivery. The new IBM Cloud Continuous Delivery Java, Python and Node.js SDKs allow developers to programmatically interact with the IBM Cloud Toolchain and Tekton Pipeline API services and add to the Go language support that was previously available. In a previous blog article, we discussed the benefits of managing your Toolchains- and Pipelines-as-Code, which include the following: Easier management of multiple…

Deploy Resources and Toolchains with Terraform

3 min read - The journey to modernize our delivery pipeline continues. Learn how we moved to a Tekton CI/CD pipeline that is deployed using Schematics-managed Terraform (Toolchain as Code). The IBM Cloud solution tutorial Apply end-to-end security to a cloud application, like many, comes with code and a related GitHub repository. As a reader, you can either follow all the steps and manually create services and deploy the application, or you can take a shortcut and use an automation. Over time, the automation…

IBM Cloud Continuous Delivery Is Now IBM Cloud for Financial Services Validated

2 min read - We are pleased to announce that IBM Cloud Continuous Delivery is now IBM Cloud for Financial Services Validated. IBM Cloud for Financial Services Validated designates that a service has evidenced compliance to the controls of the IBM Cloud Framework for Financial Services and can be used to build solutions that might themselves be validated. Through the shared responsibility model of the framework and the surrounding standardized processes, financial institutions and ecosystem partners get benefits like the following: Less time spent…