Microservice Hybrids and Alternatives
Microservice Hybrids and Alternatives
Join the DZone community and get the full member experience.Join For Free
Insight into the right steps to take for migrating workloads to public cloud and successfully reducing cost as a result. Read the Guide.
While there was a lot of excitement and buzz around microservices at this week's O'Reilly Software Architecture Conference, there was also some expected push-back. Like any general strategy, it's not going to be the answer for everyone. I talked with speakers Mark Richards and Simon Brown about microservices and they told me about some alternatives and hybrid microservice options. Here were some of the interesting things I learned
Mark Richards is a seasoned veteran in the Java space who led the New England JUG for many years, re-wrote O'Reilly's JMS book in 2009, and ran a two day workshop on essential skills for architects.
He noted that there are four attributes of the mainstream definition for microservices:
- Applications are distributed
- Applications are separately deployed
- Maintains the concept of service components (may have 3-4 modules in one service component)
- Bounded context (at least for the modules, if not the data)
Richards went on to explain that there are also ways to get some of the benefits of microservices by just adding a few of those attributes to your architecture. He said there are three things that can diverge from the pure microservices definition to create what he calls hybrid microservices.
Service Granularity - Services may be a little bigger than the single concern/function that standard microservices encompass.
These were given the name "Macroservices" by an attendee at this conference. I can see the hashtags already… #macroservices
Shared Database - You don't have to split up the database, but know that you're tightly coupling all services to that database. Refactoring a large, shared database (especially an RDBMS) is extremely hard, so this is an understandable temporary solution.
Integration Hub/Message Bus - You could possibly keep an existing central integration hub or framework, but hub-and-spoke certainly not the form that true microservices take. This might be a common variation for organizations that already had a tightly-coupled early SOA with an ESB at the center (this was actually the architecture that overrode the original concept of SOA and gave the methodology a bad name). This is probably the least palatable part to keep in a hybrid microservices setup, so don't plan to stick with this solution forever.
Distributed Services Inside a Monolith
Simon Brown pointed out a perfectly viable alternative to microservices in his presentation and in our previous conversations: a monolithic application that has loosely-coupled, modular components. He points to this Bob Martin quote as an apt description of how many of the benefits inherent in microservices are simply the result of long-known, best architectural practices. Here's the quote:
The code within the components of a Clean Architecture has no idea whether:
...That means that there is no such thing as a micro-service architecture. Micro-services are a deployment option, not an architecture.
- it is in a micro-service running on an independent server communicating with other independent servers over the internet,
- or in a small executable among many running on a single machine communicating over simple sockets,
- or in a lightweight thread communicating with other lightweight threads in the same virtual machine using mailboxes or queues,
- or in a simple Jar or DLL communicating with other components using polymorphic function calls.
Brown adds that a monolith will only loose the benefit of component deployability. It still needs to be deployed all at once, but if it's composed of (relatively) loosely-coupled modules/components, it will still have many of the benefits that microservices provide: the code is quick to modify in the face of changing requirements and fairly fault-tolerant.
Stepping Stones to MicroservicesAnother key point both speakers made about these alternatives was the ability to them as stepping stones to having a full microservices model. Simon Brown said it best in his talk: "If you've already been building a 'big ball of mud' for your architecture, trying to do microservices won't help you. You'll just have distributed big balls of mud." You need to focus on making the components of your architecture loosely-coupled and flexible, regardless of your deployment model.
So whether you have a loosely-coupled monolith, or a parts of a microservices model with some of the variations Mark Richards mentioned, it's still better than keeping a brittle architecture that's hard to update.
Opinions expressed by DZone contributors are their own.