A micro approach to a macro problem?
The microservice hype is everywhere, and although the industry can’t seem to agree on an exact definition, we are repeatedly told that moving away from a monolithic application to a Service-Oriented Architecture (SOA) consisting of small services is the correct way to build and evolve software systems. However, there is currently an absence of traditional ‘Enterprise’ organisations talking about their adoption of microservices. This blog post is a preview to a larger article, which explores the use of microservices in the Enterprise.
Interfaces – Good contracts make for good neighbours
Whether you are starting a greenfield microservice project or are tasked with deconstructing an existing monolith into services, the first task is to define the boundaries and corresponding Application Programming Interfaces (APIs) of your new components.
The suggested granularity of a service in a microservice architecture is finer in comparison with what is typically implemented when using a classical Enterprise Service Oriented Architecture (SOA) approach, but arguably the original intention of SOA was to create cohesive units of reusable business functionality, even if the implementation history tells a different story.
A greenfield microservice project often has more flexibility, and the initial design stage can define Domain Driven Design (DDD) inspired bounded contexts with explicit responsibilities and contracts between service provider and consumer (for example, using Consumer Driven Contracts).
However, a typical brownfield project must look to create “seams” within the existing applications and implement new (or extracted) services that integrate with the seam interface. The goal is for each service to have high cohesion and loose coupling; the design of the service interface is where the seeds for these principles are sowed.
Communication – Synchronous vs asynchronous
In practice, we find that many Enterprises will need to offer both synchronous and asynchronous communication in their services. It is worth noting that there is a considerable drive within the industry to move away from the perceived ‘heavyweight’ WS-* communication standards (e.g. WSDL, SOAP, UDDI), even though many of the challenges addressed by these frameworks still exist, such as service discovery, service description and contract negotiation (as articulated very succinctly by Greg Young in a recent presentation at the muCon microservices conference).
Middleware – What about the traditional enterprise stalwarts?
Although many heavyweight Enterprise Service Bus ESBs can perform some very clever routing, they are frequently deployed as a black box. Jim Webber once joked that ESB should stand for “Egregious Spaghetti Box,” because the operations performed within proprietary ESBs are not transparent, and are often complex.
If requirements dictate the use of an ESB (for example, message splitting or policy-based routing), then open source lightweight ESB implementations such as Mule ESB or Fuse ESB should be among the first options you consider.
I usually find that a lightweight MQ platform, such as RabbitMQ or ActiveMQ is more suitable because we believe the current trend in SOA communication is towards “dumb pipes and smart endpoints” In addition to removing potential vendor fees and lock-in, other benefits of using lightweight MQ technologies include easier deployment, management, and simplified testing.
Deploying microservices – How hard can it be?
However you choose to build microservices, it is essential that a continuous integration-style build pipeline be used which includes rigorous automated testing for functional requirements, fault-tolerance, security and performance. The classical SOA approach of manual QA and staged evaluation is arguably no longer appropriate in an economy where ‘speed wins’ and the ability to rapidly innovate and experiment is a competitive advantage (as captured within the Lean Startup movement).
Behaviour of your application can become emergent in a microservice-based platform, and although nothing can replace thorough and pervasive monitoring in your production stack, a build pipeline that exercises (or tortures) your components before they are exposed to your customers would appear to be highly beneficial. As I’ve argued in several conference presentations, a good build pipeline should exercise services in the target deployment environment as early in the pipeline as possible.
Summary – APIs, lightweight comms, and correct deployment
Regardless of whether you subscribe to the microservice hype, it would appear that this style of architecture is gaining traction within practically all software development domains. This article has attempted to provide a primer for understanding key concepts within this growing space, and hopefully reminds readers that many of these problems and solutions have been seen before with classical Enterprise SOA. We would be wise to take care not to reinvent the proverbial ‘service-oriented’ wheel.
Please click here for the complete original article, which provides additional information on microservice implementation options on the JVM platform, and also discusses the requirement for Continuous Delivery. A version of this article was originally published in the DZone 2014 Guide to Enterprise Integration.
References
A full list of references and recommended reading can also be found in the original article and a recent article discussing the business implications of microservices.
| Reference: | Microservices in the Enterprise: Friend or Foe? from our JCG partner Daniel Bryant at the The Tai-Dev Blog blog. |
