An API Architect’s Guide to Microservices
Accelerating development and securing microservices with API tools
from CA Technologies
What are Microservices?
Monolithic applications are no longer efficient in the digital economy. Development teams across enterprises are struggling to
deal with large applications with respect to development time, deployment and scalability. With the widespread adoption of
DevOps frameworks and agile methodologies, development teams felt the pinch to break down complex application silos into
simpler code blocks, which gave birth to microservices.
Architects have devised design patterns to turn complex applications into simple and fine-grained yet reusable and
interoperable processes that can be modified and deployed independently of each other. These fine-grained processes are
called microservices.
A microservice has five important characteristics: independence, deployability, scope, scalability and interoperability.
A microservice will be:
• Loosely coupled, enabling it to be completely autonomous of any other process or service
• Deployed independently of any other process with which it may be communicating
• Bounded by a domain context, i.e., specific business capabilities that help in avoiding data sharing across microservices in
order to make them independently deployable
• Scalable instantly and independently, such that capacity can be added by focusing on specific capabilities and not the entire
monolithic application
• Interoperable with other autonomous and loosely coupled services through message-based communication
So, by definition, a microservice is an independently deployable component of bounded scope that supports interoperability
through message-based communication.
Why Does My Enterprise Need Microservices?
Every digital enterprise trying to thrive in the digital economy is aspiring for two things: speed and scale. If a company’s need
to get to market faster is critical, it’s equally important to be able to scale up appropriately to support increasing customer
demand. But the key mantra here is: speed and safety at scale. You can only succeed when you attain speed and scale
without losing safety.
Agile and DevOps models support decentralized and distributed ownership of software assets and promote faster turnaround of
changes and quick deployment. However, in order to intelligently break down complex, monolithic applications into autonomous
units, you need a design strategy, namely, microservices. By breaking your huge application into microservices, you’re enabling
your development team to be more nimble with updates and autonomous deployments. This removes dependencies to create
large and complex builds, and it eliminates the need for over-sophisticated architectures to step up scalability to meet
volume demands.
2 | AN API ARCHITECT’S GUIDE TO MICROSERVICES ca.com
How Do I Enable Microservices Within My Enterprise?
Assess the maturity of the agile enterprise. If your organization is on a higher level of agile maturity and you are thinking of
or have adopted DevOps, your enterprise is quite ready for microservices.
Create smaller groups of developers. Empower smaller teams of developers to own and work effectively on a smaller set of
services/APIs. This inherently encourages loose coupling and autonomous deployments.
Adopt a domain-driven design. Break down large applications into simpler services based on business capabilities or functions.
The more fine-grained the services are, the better they work for this design.
What’s the Connection Between APIs and Microservices?
Microservice components only become valuable when they can communicate with other components in the system; they each
have an interface or API. Just as we need to achieve a high level of separation, independence and modularity of our code, we
need to make sure that our APIs, the component interfaces, are also loosely coupled. Otherwise, you won’t be able to deploy two
microservices independently, which should be one of your primary goals in order to balance speed and safety.
There are two practices in crafting APIs for microservices worth mentioning here:
• Message-oriented. By adopting a message-oriented approach, developers can expose general entry points into a component
(for example, an IP address and port number) and receive task-specific messages at the same time. This allows for changes in
message content as a way of refactoring components safely over time.
• Hypermedia-driven. In implementations leveraging hypermedia, the messages passed between components contain data
as well as descriptions of possible actions (e.g., links and forms). Now, the actions, not just the data, are loosely coupled.
Securing Microservices With an API Gateway
A common pattern observed in virtually all microservice implementations is teams securing API endpoints, provided by
microservices, with an API gateway. Modern API gateways provide additional, critical features required by microservices:
transformation and orchestration. Last but not least, in most mature implementations, API gateways cooperate with service
discovery tools to route requests from microservices clients. Microservice architecture is one with a significantly high degree of
freedom. In mature microservices organizations where the architecture is implemented for complex enterprise applications, it’s
common to have hundreds of microservices deployed. Security will be a very critical factor to consider in that case. Virtually,
in all microservice implementations, we see API endpoints provided by various microservices that are secured using a capable
API gateway. APIs provided by microservices may call each other, may be called by front-end, (public-facing) APIs, or may be
directly called by API clients such as mobile applications, web applications and partner systems. The widely recommended
approach is to secure invocation of public-facing API endpoints of the microservices-enabled system using a capable
API gateway.
3 | AN API ARCHITECT’S GUIDE TO MICROSERVICES ca.com
An API gateway is a key component of any microservices From a microservices perspective, CA API Gateway addresses
architecture and acts as a common bridge between the some key objectives:
service implementation and any consuming clients.
• Security. As mentioned above, the solution can act as the
API Gateways provide:
central policy enforcement point. It’s better to always secure
• Centralized security enforcement for authentication, any API/microservice access with an API gateway, and in
authorization and threat protection most cases, the negligible overhead of introducing an API
gateway in between service calls is well worth the benefits.
• Routing and mediation to protected resources across
various protocols • Transformation and orchestration. CA API Gateway allows
you to declaratively, through configuration, create API
• Service level management for enforcing business-level
interfaces that can orchestrate backend microservices and
rate limits and quotas
“hide” their granularity behind a much more developer-
• Service orchestration for reducing service invocations friendly interface to eliminate chattiness.
• Service façades for exposing application-specific interfaces • Routing. CA API Gateway hides the complexities of routing
from monolithic back ends to a microservice from the client apps. The solution can
interface with either HTTP or DNS interfaces of a service
Tools from CA Technologies for discovery system and route an API client to the correct
service when an external URI associated with the
Microservices microservice is requested.
CA API Gateway delivers industry-leading gateway
CA Live API Creator creates and exposes domain-driven
functionality for enterprise-class microservices by combining
microservices and REST/JSON APIs as application back-ends to
policy management with runtime policy enforcement and
provide access to existing data and functionality from legacy
delivering a central policy enforcement point between the
and modern data sources and apps. The solution enables
business and the end user—no matter where they’re located.
developers to create new REST endpoints that join data across
With the CA API Gateway, enterprises can selectively open
diverse data sources using a point-and-click approach. API
their data and applications to both internal and third-party
owners can extend the API with declarative business rules,
developers, integrating with existing IAM solutions for a
JavaScript event processing, role-based security and
plug-and-play solution. The CA API Gateway deploys in a
interactive testing. CA Live API Creator also enables
variety of form factors including Docker, which is ideal for
companies that have embraced API management to expand
microservices because it easily scales and can be deployed in
the scope of their API lifecycle beyond management and
a failover environment for high availability. The solution also
enforcement in existing gateway and portal offerings toward
includes protocol bridging, providing full translation between
the creation of APIs closer to the data layer.
a variety of protocols—from legacy to REST and JSON—and the
bridge from legacy to mobile, cloud and social.
4 | AN API ARCHITECT’S GUIDE TO MICROSERVICES ca.com
With CA Live API Creator, you can rapidly create application
back-ends for internal applications, mobile development
Next Steps
projects, data-as-a-service exposure, Internet of Things (IoT) Today’s DevOps and agile-loving enterprises are striving for
enablement and partner integration. From a microservices fast changes and quick deployments. To these companies, the
perspective, the solution addresses some key objectives: microservices architecture is a boon, but not a silver bullet.
Organizations can enable smaller development teams with
• Modularity. Use CA Live API Creator to decompose large
more autonomy and agility, and as a result, the business will
applications into self-contained units called resources,
notice IT being more in tune with their changing demands. IT
delivering everything necessary for app delivery: data
will need to align its API strategy with the microservices that
integration, business logic and a robust API interaction layer.
developers produce. Securing those microservices should be of
Resources are message-based, RESTful APIs that are
the utmost importance; leveraging API Gateways in this
independent of the underlying schema.
context will benefit IT. And always remember that if you’re
• Speed of delivery. Resource definition is point and click, looking for speed and scale, safety is equally important.
integrating multiple objects from multiple databases.
• Zero deploy. The solution completely eliminates the delays
associated with deployment. Defined resources are To learn more about microservices, please
immediately executable as soon as you click save—no download our eBook:
compile, no deploy.
“Microservice Architecture: Aligning
• Automated deploy. Alternatively, you can export a
Principles, Practices, and Culture”
microservice (e.g., from development) and employ scripts to
import it (e.g., to production).
• Cohesion. Dependencies are automated, so deploying one
microservice does not affect others.
• Separation of concerns. CA Live API Creator separates
microservice creation from business logic, which is defined
on underlying domain objects and automatically applied to
all microservice requests.
5 | AN API ARCHITECT’S GUIDE TO MICROSERVICES ca.com
To learn more about CA API Management,
visit ca.com/api
Connect with CA Technologies at ca.com
CA Technologies (NASDAQ: CA) creates software that fuels transformation for
companies and enables them to seize the opportunities of the application economy.
Software is at the heart of every business, in every industry. From planning to
development to management and security, CA is working with companies worldwide
to change the way we live, transact and communicate—across mobile, private
and public cloud, distributed and mainframe environments. Learn more at ca.com.
Copyright © 2016 CA. All rights reserved. Java and all Java-based trademarks and logos are trademarks of Oracle Corporation in the
United States, other countries, or both. All other trademarks, trade names, service marks and logos referenced herein belong to their
respective companies. CS200-221714_0916
