X

The Integration blog covers the latest in product updates, best practices, customer stories, and more.

  • August 7, 2015

Microservices and the Integration Platform

Robert Wunderlich
Product Strategy Director

In case you have not already heard of microservices, yet another evolution is upon us in the world of
software development. A microservice is
the antonym of the monolith and is a relatively new name for some concepts that
have been around for some time. Microservices
push us further toward the dream of decoupling with a promise of simpler,
easier and cheaper services that are more reusable. As we get started, you can find a great
primer on microservices through Martin Fowler’s blog at http://martinfowler.com/articles/microservices.html

Before I continue, I should point out that I am the Product
Manager for Oracle Service Bus and
that may cause you to wonder why I would be talking about microservices. As a matter of fact, Martin Fowler in his
blog states “The microservice community favours an alternatitive approach: Smart
endpoints and dumb pipes”. Others
position microservices as an alternative to SOA even going as far as saying
that microservices can be SOA done the right way.

You might think that as a product manager for an enterprise
service bus product, I might be inclined to defend my product against this
movement, but I don’t think that is necessary. I think this is not an either-or question, but rather a hybrid approach
to integration and service delivery is a more realistic direction to take. Quite simply we will need to leverage microservices,
and SOA and we can learn and apply principles from both.

In this post, I’ll very briefly discuss the evolution from
the monolith to services. I’ll compare
and contrast SOA and microservices, mainly because of how monolithic elements
have grown in SOA over the years. I’ll
point out some of the pain-points of both SOA and microservices and will
conclude with how choosing a hybrid approach can realize the benefit of both
SOA and microservices while helping to reduce the pain-points.

Our long journey in software development began with the
mega-monolith, the mainframe. From the
very beginning, business rapidly came up with new requirements for software and
the need to bring new features to production faster continues to grow every
day. In the early days, when mainframes
ruled, the change cycles were extremely long.

An example of this comes from very large insurance company
that I worked for. Just to make a small
change in their claims processing system would take from months, up to a year
or longer, and would be exceptionally expensive to complete. That change never happened because even
though it would have helped the “human workflow”, it was just too expensive to
implement. In those days of the mega-monolith,
human users simply had to adapt to the machine even if it was not the most
efficient approach, rather than to incur the cost of changing the system.

Our approach has evolved quite a bit since the early days of
the mainframe. We determined that rather
than change a large monolith, we could make incremental changes and integrate
systems together in order to support business processes more rapidly. From the early integration patterns, we
progressed to Service Oriented Architecture (SOA).

Over the years however, we have witnessed SOA
implementations that have taken on a more monolithic approach so some observers
have associated SOA itself as being monolithic.

I do believe that there is a place for monoliths and it is
important for the practitioner to strike a balance of when to use a monolithic
approach, and when to use a microservice approach. While we may be more familiar with SOA, let’s
discuss some of the characteristics of MSA.

Microservice Architecture (MSA) is mostly an organizational
approach to developing and delivering discrete functionality that is highly de-coupled. If anything is tightly coupled, it is the
functions of development and operations which we will talk more about shortly.

Microservices are typically designed, created, delivered and
supported, by one developer or a small, cross-functional team. These services are generally aligned by
business function rather than technology. Instead of structuring teams under categories such as database,
applications, middleware, etc, the teams may be structured as Accounting, and
Finance comprising of members who are skilled in different technologies.

Services are thought of more as a product rather than a
project. The team that delivers a microservice
does not simply turn it over to operations when it is deployed but rather that
team continues to own and support that service through its lifecycle. This means that a developer cannot create
functionality and “throw it over the wall” to the operations team. That developer is responsible for providing
support of her product even if that means 24x7 on-call availability!

This model creates a culture of full-lifecycle thinking
where a developer will not only create functionality, but will be consider more
about how to make that service tolerant of real-world conditions and much
easier to support. Check out the
interview with Adrian Cockroff (http://www.infoq.com/interviews/adrian-cockcroft-microservices-devops)
where he discusses his experience with Netflix and how a microservice approach
brings about DevOps into the organization.

Microservices provide some distinct benefits in that with
their inherently smallish nature, they can be easier to implement. Instead of standing up some sort of
application server, a microservice can be quickly created using nothing more
than a shell script or other technology such as JavaScript. As a matter of fact, commands we typically
use in UNIX such as ls, grep, sed, etc can be thought of as microservices. They perform a specific function by
themselves and can be used together in a larger choreography service (shell
script) in order to achieve broader functionality. In and of themselves they are wholly
independent.

Microservice Architecture (MSA) is coming in at a time where
other technologies and methodologies have changed the way we design services
and develop software. While Service
Oriented Architecture (SOA) matured using Simple Object Access Protocol (SOAP),
Microservice Architecture (MSA) is entering the stage at a time when
Representational State Transfer (REST) is gaining widespread adoption and being
seen by many as the preferred choice over SOAP. We should not associate SOA with SOAP because we can and do use REST
with SOA. We have to be careful to
separate the technical implementation from the pattern when we are considering
an approach.

Let’s look at a few patterns in the flow that may be found
in an online retailer. Quite simply an
Order Capture system may receive orders. That system needs to validate the payment details and to do this, needs
to leverage a Credit Validation Service. Once the payment is validated, the order needs to be sent to a
Wharehouse Management System which is an internal system in the
enterprise. Finally when the order is
picked and packaged a shipping service might need to be called select a shipper
and create the shipping label.

The topology might look like the following:

Customizing the Monolith

Figure 1 Customizing the Monolith

Essentially the Order Capture System has been customized and
includes a workflow to complete the following business process:

SalesOrderProcess

Figure 2 SalesOrder Process

This may be considered a simple, contained unit and may be somewhat
easy to implement if we have a good skill-set in our Order Capture System and
even more so if our Order Capture System provides for extensibility. Generally a conversation with the application
provider will tout how easy it is to use the extensibility framework to
implement a business process. We are
faced with a few challenges in this approach however.

  • The transformation logic
    can get rather complex and most applications lack solid support for
    data-mapping.
  • We will have a monolith in
    both design and runtime. Our Order
    Capture System will now have dependencies on the other systems as it is
    tightly coupled. If there is any
    change to any system, then all of the systems have to be considered and
    may have to be re-deployed. As a
    matter of fact, with such a heavy customization of the application, even
    patching of that system has to take those customizations into account.
  • Dev teams tend to bundle
    the whole offering as one deployable unit to ensure the dependencies are
    managed but ends up causing a “waterfall” approach.
  • Management and monitoring
    often has to be developed into the customization and is often leverages
    the facilities within the app itself from logging, to alerts, to business
    events, etc. This results in silos
    of information as this is likely not the only application that needs to
    integrate.
  • Not all participating
    applications have standard connectivity. Special steps may need to be taken and custom connectors may have
    to be created in order to get information between systems.
  • Scalability can be a
    concern because the monolith has to be replicated or a load-balancing
    mechanism has to be developed

Service Oriented Architecture came about to promote loose
coupling for reusability. In a nutshell,
SOA is an architectural pattern where the services are self-contained units
that communicate with each-other via communication protocols.

As Service Oriented Architecture gained popularity, software
vendors delivered “integration platforms” to help create services and to
integrate applications. Let’s look at an
example of using an integration platform below

Figure 3 Using an Integration Platform

As we review Figure 3, we can see the following benefits:

  • Fewer
    customizations/extensions to the integrated systems. As a matter of fact, the system simply
    sends a SalesOrder to a webservice and will at some point receive a
    call-back to tell it either the payment was rejected and therefore cancel
    the order or that the payment was shipped and to update the status
    accordingly.
  • Integration platforms
    often have extensive support for data-mapping and can help standardize the
    approach.
  • Integration platforms
    often provide management and monitoring out of the box for exception
    handling and tracking of business processes.
  • Integration platforms
    often provide policy based security lifting the burden from the developer
  • Integration platforms
    often provide a wide range of connectivity adapters to allow developers to
    easily connect to participating applications.
  • The Integration platform
    can provide scalability support with clustering, caching and throttling.

As we use an integration platform, we discover that we have
not eliminated the monolithic pattern completely and we do have some
challenges:

  • The cost can be higher as
    a middleware offering has to be set up and to train developers and
    administrators to use it. This cost
    goes down as more services are implemented however
  • This approach can still result
    in a “waterfall” development approach as the solution stretches across the
    applications and middleware.

With the challenges in mind, some may now claim that
Microservices architecture now completes what SOA intended so let’s take a look
at our example from an “extremely microservices” approach.

Figure 4 Microservice Approach (Event Driven Architecture)

As you look at this diagram, you may say “Wow! That looks like a huge mess of spaghetti
integration” and on some levels, you may be right. Let’s walk through this diagram to understand
what is happening.

First, like our Integration Platform approach, the Order
Capture System has been extended with the same points with “Order Created” and
receiving either a “Payment Rejected” or “Order Shipped” response but with a
slightly different implementation.

Before we continue, we should note this is what we would
call choreography vs. orchestration. Our
monolith and our integration platform both execute an orchestration where a
business process or workflow is controlling all of the calls. In choreography, each service or system is
fully autonomous and simply puts and listens for events from topics.

Let’s look at some of the benefits of the microservice
approach.

  • Every system is fully
    decoupled: If one system is pulled
    out, all other systems will continue to compile and operate within their
    own domain. Of course the process
    would not complete, but each system would continue to perform its
    respective function. The benefit here
    is a high degree of tolerance for failures.


    For example if the PaymentValidation service were to go down, the
    OrderCapture system would continue to operate and would simply be raising
    events. Those orders of course
    would be sitting in the “OrderCreated” stage as there would be no
    “PaymentRejected” or “OrderShipped” events until all of the other services
    were restored.


    Furthermore, each service can be complete isolated to run in its own
    space. This means that if one of
    the services starts “acting up” it will not affect the other
    services. Each service could run in
    its own JVM, container, or even a complete virtual machine!
  • In the middle is a message
    broker: This is the concept of
    “dumb pipes” in that the middle-layer does not process the messages and
    does not employ any translation, transformation, or routing logic. These are simply events/messages that
    are being placed onto topics and are being consumed by interested parties. This means that there is no real
    monolith. Each microservice can be wholly
    owned and managed by individual developers or small teams.
  • In general, the startup
    cost to creating microservices is quite low: There is no real need to install an
    integration platform before creating services.

Unfortunately, microservices are not quite a panacea of
integration. As with all approaches
there are no “silver bullets” and microservices do bring some challenges that
we have to consider.

  • There are many more
    services to manage: With extreme
    decoupling there are more services to manage and more service invocations
    which can result in extra overhead. Microservices are self-contained units that can consume more
    resources over time due to the fact that they may run in their own JVMs
    and/or VMs.
  • There is no built-in
    security: Developers are responsible
    for making sure their services are properly secure.
  • There is no built-in
    management and monitoring: What happens if the ValidatePayment service
    goes down? The OrderCapture system
    or more appropriately the PaymentDefinition service will remain unaffected
    and will simply continue to raise events.


    How do we detect there is a problem? Well, we have to build in management and monitoring logic, say a
    heartbeat that will raise an alert if the service goes down. We have to implement circuit breaker
    patterns in some cases to manage our error conditions.
  • Mediation can be more
    difficult: In our diagram we are dealing with multiple domain models and
    we have to use translation services. We may ask, why not just have the PaymentValidation service for example
    understand what a SalesOrder is, but that would be a tighter coupling and
    we may use the PaymentValidation service for other functions that are not
    like the SalesOrder, like recurring billing, etc.


    We do not have a common data-mapping facility, therefore we have to
    hand-code all of our transformation logic and that logic and we can be left
    with many mediation services and increased complexity.

As we have looked at three approaches, the monolith, an
Integration Platform, or microservices, which one is best for integration? First, I think that the monolith is
appropriate only within an application suite and perhaps very limited service
invocation to the outside world. Most
companies have multiple monoliths in the form of applications like ERP and CRM
systems and there is always a need to integrate these systems. I advocate a hybrid approach between an
Integration Platform and microservices based on specific use-cases and use both
to the best of their abilities.

Here is a potential topology that mixes a microservices
approach with an integration platform

Figure 5 Hybrid Approach

In the above example, we used Service Bus for a couple of
benefits. First, our Order Capture
System might not be able to interact directly with the message broker we are
using for our microservices. With the
widely available adapters and transports, Service Bus can translate between the
application and the message broker.

Using the Integration Platform, we can take advantage of the
common data-mapping features to quickly create our transformations without
having to develop each one by hand. We
also gain the benefits of common management and reporting to capture a level of
metrics about our overall integration all the while keeping all of our microservices
highly decoupled. Using an Integration
Platform like Oracle Service Bus and Oracle SOA Suite helps us fill the gaps in
microservices to allow us to leverage the best features of between Service
Oriented Architecture and microservices.

I think one of the very best features of microservices is
that the practice of Development-Operations (DevOps) is now beginning to take
center stage. Adrian Cockroft makes a
great point that the services begin to become much more resilient when
developers are responsible to support them in production. Microservices comes at a time when we are
trading SOAP for REST and moving from waterfall to continuous delivery. As we create services to meet ever changing
requirements, microservices mandate that we take on a complete lifecycle
view. While microservices won’t
necessarily save the world, I think we all can learn from and adopt the
practices of microservices. 

Going forward, we can use some of the new and exciting features of microservices while still taking advantage of our experience in SOA to use the best that both have to offer.


Join the discussion

Comments ( 10 )
  • Sam Friday, September 25, 2015

    Very good explanation of how SOA and MSA are useful in hybrid topology. Thanks!


  • Tom Tuesday, October 6, 2015

    Excellent analysis Robert!


  • vijayaraghavan Saturday, March 26, 2016

    Very good explanation


  • Harinath Gandhi Monday, August 22, 2016

    Excellent Write up Robert.


  • W Brian Leonard Thursday, September 8, 2016

    Excellent Robert!


  • sandeep Wednesday, September 21, 2016

    I haven't seen a better explanation of microservices and it's pros and cons in the Internet . Period.


  • kiran Saturday, October 15, 2016

    Excellent explanation with example


  • guest Wednesday, October 19, 2016

    Hi Robert,

    Excellent article! With but extensive push towards cloud, companies just want to write small function and pay for this execution time! Dont want to bother about a platform or its setup, just pay for service execution.

    So in this world, how do you see Oracle SOA Suite or Service Bus growing? Do we have plans to generate services from either products which can run on its own in entirety without need for a complete platform?

    Thanks


  • Shailender Nanra Friday, November 10, 2017
    Very good explanation. Explain the bridge between SOA and microservices nicely.
  • Pete Tuesday, May 29, 2018
    Hi, very nice Article. Some further thought about integration vs. microsevices.

    You wrote: As we use an integration platform, we discover that we have
    not eliminated the monolithic pattern completely and we do have some
    challenges:

    The cost can be higher as
    a middleware offering has to be set up and to train developers and
    administrators to use it. This cost
    goes down as more services are implemented however
    This approach can still result
    in a “waterfall” development approach as the solution stretches across the
    applications and middleware.

    Here is my comment:
    In both cases SOA and Microservices there are cost for implement and operate integration or/and message broker platform.

    If using model driven aproach and in advance define service artifacts, there is no need for watterfall based development. Everyone can do his own services in parallel.

    About monolitic and service granularity:
    Developing and running (micro)atomic services and running them outside of SOA (ESB) platform in a distributed way, it could be one possibility to operate & scale every of those atomic services and be not preformance related coupled to soa platform.

    About communication (process) & integration logic:
    -could be made via soa layer
    -via API Gateway Layer (there are mixing funktionality of ESB inside this layer on the market)
    -as a separate integration (micro-) service
    -inside of every microservice, and with all logging, security... code. In that case I would't call it microservice anymore.

    In the last case, there is a challenge to keep in track the whole process related informations.

    Kind regards
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.