The emergence of the ‘Opinionated’ Microservices Platform continues apace.
We are told that business systems should be REST/Microservice based. We are told that containers should be used everywhere and container images are the deployment artefact du jour: I mean lets face it Virtual Machine Images are so last year! And of-course Reactive is the new cool.
A depressing state of affairs. These messages are at best half-truths. At worst – the IT industry’s ongoing equivalent of Snake Oil.
- Microservices: As long as used appropriately – no complaints. However, REST based Microservices are a popular corner case one which should be addressable by a more general and coherent approach to system modularity!
- Reactive Systems: These concepts are important. However a system cannot be truly reactive if is not modular in composition. “Containers + REST” != Reactive Systems.
- Containers: Nothing new here – been around since Mainframes LPAR’s and Solaris Zones. Great for isolation and partitioning resources! However deployment of applications via inter-related sets of opaque container images is just about the worst idea imaginable. Today’s issues with operational complexity and VMI sprawl will soon be magnified 1000 fold. And all caused by the current “containers are the answer” dogma.
Paremus has been providing a reactive distributed OSGi platform since 2006 – before Amazon, and before SpringSource acquired Cloud Foundry. Yet today in 2016 the Paremus Service Fabric is still unique. Well of-course the name “Service Fabric” is no longer unique – these days Microsoft also have a Service Fabric. However the Paremus Service Fabric is still unique in most other respects.
Our Fabric is an Agnostic. No API lock-in, no application architectural restrictions. The Service Fabric is also middleware neutral. Whether Java / OSGi or polygot / Docker – your application architecture is your concern. Whatever your ‘Opinion’ today, or your ‘Opinion’ tomorrow the Service Fabric will deploy, configure and maintain your business systems.
Paremus Service Fabric’s raison d’être:
- To be as operationally simple as possible: To be manageable by mere mortals – not some new genetic breed of DevOps.
- To be as robust as possible: No smoke and mirrors, no hidden points of failure. And because high availability requires fast recovery: install, repair and recreate operational tasks must be as simple as possible.
- To be as flexible as possible: Because there is no one single “ANSWER”. Business requirements change and so optionality is always a requirement. The Fabric can orchestrate REST based Microservices – but also has sophisticated asynchronous, messaging, eventing and streaming options.
- To be based on solid industry standards and not some hip open source project that is currently fashionable.
The Paremus Service Fabric is built from the ground up leveraging OSGi / Java. We engineering the Fabric with Java / OSGi – not because the technologies are ‘cool’ – but because we require Longevity and Agility from our platform.
- To achieve Longevity & Agility the Service Fabric must be Evolvable (DARPA Brass).
- To be evolvable the Service Fabric must be modular at all structural levels.
So the Paremus Service Fabric is actually highly Opinionated, my engineers are even more Opinionated, but only on the inside. To the outside world the Paremus Service Fabric and Paremus are Agnostic – our role is to simply serve.
This philosophy made sense in 2006 and I believe it still makes sense today in 2016. Indeed – the Paremus Service Fabric remains the only standards based modular evolvable runtime platform.
- The Service Fabric supports ‘Microservices’.
- The Service Fabric is highly Reactive.
- The Service Fabric can orchestrate sets of Microservices deployed to Docker containers.
But perhaps most importantly – in addition to support today’s fashions – the Paremus Service Fabric will remain relevant to tomorrows business challenges.