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
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
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
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:
Figure 1 Customizing the Monolith
Essentially the Order Capture System has been customized and
includes a workflow to complete the following business process:
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.
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:
As we use an integration platform, we discover that we have
not eliminated the monolithic pattern completely and we do have some
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
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.
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.