Sunday, 12 November 2017

2nd vs 3rd Generation API Platforms - A Comprehensive Comparison

Earlier in the year, June to be exact, I published the OTN article 3rd-Generation API Management: From Proxies to Micro-Gateways -based on a concept I presented in an Oracle OpenWorld 2016 Presentation titled API management in the year 2026.

In summary, the article talks about how in the digital era requirements have changed when it comes to getting access to information. Fact that modern applications demand information in real time and expect it to be available 24x7, and also the side effect of cloud adoption which is causing information to become more and more federated amongst multiple cloud applications (from different vendors) and on-premises systems -as they won't go away that easily.

The article continues by explaining that although REST APIs play a critical role in providing such critical access, the underlaying technology stack that have traditionally enabled SOA architectures, typically based on monolithic middleware, will struggle to satisfy the aforementioned needs. The article concludes by explaining that a new form of platform, one that is light-weight, portable, hybrid and cloud-agnostic, REST/JSON native, Microservices Architecture ready, a 3rd generation, is ultimately required.

You might recognised the following picture from some tweets and articles:

2nd vs 3rd Generation API Platforms Conceptually
Although the article has been very well received, one question I get asked frequently is around what exactly is difference between 2nd and 3rd Generation API Platforms. Furthermore, I took notice that the question is often asked for one of the following reasons:
  1. An investment has recently been made in an API Management stack and there is a desire to understand if it is 2nd or 3rd generation, or at least verify if the desired capabilities are in the product roadmap.
  2. The need for a more sophisticated API platform, one that can go beyond traditional use cases (i.e. API Gateway in DMZ) but also easily satisfy hybrid (cloud/on-prem) scenarios, has been recognised.
  3. A Microservices Architecture initiative has been kick-started and the need for an API Gateway has been identified, however individuals within the initiative favour modern, lightweight, scalable, and affordable solutions over traditional, monolithic , heavy and also expensive API gateways.
That said and in order to address this question, I am sharing a comparison based on the second chapter of my coming book Enterprise API Management -where I talk about my learnings, approach and experiences implementing API strategies and platforms for large organisations.


Characteristic 2nd Generation API Platforms 3rd Generation API Platforms
What is it? Based on a monolithic stack. Most-likely derived from an ESB or an adaptation/extension of XML-based appliances. Support for Web APIs (REST/JSON) and associated technologies comes as an ad-on as capability wasn't originally in the product.  Built from the ground up to support Web APIs and modern API requirements such as API-first, hybrid deployment models, elastic scaling and Microservices Architecture. They tend to be lightweight and portable. Many based on async I/O based  engines which makes them extremely efficient and scalable.
Business value of APIs 2nd Gen API Platforms pre-date the rise of the API economy therefore capabilities available in this space (i.e. monetisation) will be, as earlier said, an adaptation/extension of the tooling, not out of the box. Built from the ground up to help organisations realise the business benefits that APIs have to offer. 3rd Gen API Platforms are rich in capabilities to help the business (not just IT) realise benefits. For example, better discoverability of APIs via API developer portals, API specific web-pages, developer self-service and API monetisation.
Deployment model: Centralised vs Federated Typically centralised -most likely in on-prem DMZ infrastructure. Deployments with multiple instances across many different data-centres and geographies are not the norm. Design with federation in mind. Deployment of gateways in multiple data centres and geographies fairly straight-forward, not a massive and complicated engineering undertaking.
ESB-less / XML appliance-less As earlier said, 2nd generation tend to be extensions/adaptations of monolithic stacks such as ESBs or XML appliances. For this reason, satisfying modern requirements such as independent runtimes, rapid scaling and elasticity, rapid installation, multi-cloud and on-premise (hybrid) deployments, will be difficult to satisfy. API platforms built from the ground up to support modern API requirements. Not an adaptation of old technology. Supporting requirements such as rapid scaling, use of Docker containers, infrastructure as code (meaning automating the entire setup/config/maintenance process) and hybrid deployments are one of the key differentiators.
Fat vs light middleware Comparable to a Swiss army knife, 2nd generation platforms can do a lot. From message routing and data transformation, to complex service orchestrations and business rules. Thus in order to deliver such diverse capabilities, the footprint of the platform tends to be large. Such rich capability also means that the Gateway itself is used for all sort of things, including implementation of business logic implementation -considered a bad practice in modern architectures (smart endpoints and dump pipes). Laser focus on satisfying API mediation requirements such as HTTP routing, Authentication/Authorization, API throttling, rate limiting, API load balancing and a few others, but certainly not to satisfy complex data transformation, orchestration or business logic requirements. For this reason amongst others, 3rd Gen Gateways are lightweight (definitely lighter weight than 2nd Gen).
Native Hybrid (any cloud + on premises) On-premise technology by birth. Cloud (if supported) resulting from an adaptation or a cloud-wash. Several constraints most likely imposed by vendor if cloud deployment is supported.

Also note that 2nd Gen gateways claim to be docker-container ready, however when digging deeper one may find that use of containers is either not recommended for production, or the size of the container itself is so large that makes them impractical for use.
Can be deployed in any infrastructure, cloud (any vendor) and/or on-premises without much complication. Straight forward deployment. Docker containers support out of the box.


Native end to end /JSON Not native, in fact many 2nd generation Gateways will convert JSON to XML (or something else) internally for processing and then back to JSON. A good sign that an API Platform is a 2nd Generation one, is the rich support available for XML-based standards such as SOAP/WSDL and WS-*.  Understands/handles JSON end to end natively because it was built for this. Full support for standards such as OpenAPI (aka Swagger)  and API Blueprint in place by default.

XML support rare (perhaps just for converting SOAP to JSON).
API-design first As an extension, not native. In many cases simply not available. There tends to be a lack of proper API design and documentation capabilities which means that many of the APIs are not properly documented. Which means developer experience is not the best. Fundamental part of the product. Rich support for API-design first therefore supporting open standards such as OpenAPI and API Blueprints for defining and mocking APIs. Capabilities to create API dedicated web-pages and publish them in self-service developer portals is the norm.
Microservices Archiecture Precedes Microservices Architectures. Wasn't built for it and therefore there is a natural mismatch in terms of what a Gateway should and shouldn't do. For example, in Microservices Architectures, one would expect the heavy lifting to be implemented in the service, not a Gateway. Therefore most of the capabilities of 2nd Gen Gateways wouldn't (shouldn't) be used. Microservices Architectures one of the core use cases for 3rd Gen API gateways address. For example service discovery and client-based load balancing is a core capability of such gateways. Also 3rd,Gen API Gateways are very lightweight and won't force any specific service implementation stack. Ideal for polyglot programming which is one of the fundamental principles of Microservices Architectures.
Software release Traditionally an on-premise offering, therefore not cloud-first. Typically software patches/upgrades/new releases or have to be downloaded and installed -which could be a complicated task. For this reason software can rapidly become outdated. Also major updates/releases not too frequent (some times once a year). Cloud-first. Release cycles are frequent (monthly or quarterly), and rollout process straight forward. In most cases happens automatically and fully executed by cloud vendor. In other cases new patch/releases are container-based.
Licensing model Typically CPU-core based. Very expensive when it comes to large deployments. Subscription model based on used (i.e. throughput based). Not CPU based.
Full API lifecycle Partly. Requirements such API-first, control-planes (see next point), API-spec validation, Registry-based Service discovery (in a Microservice context), not typically available into the product but require extensions. API lifecycle tends to be fully separated from the Service lifecycle. Either already out of the box, or easily extensible to be combined with other solutions or already considered and visible as part of the product backlog (roadmap)
Control plane API / DevOps ready If control plane APIs (also known as management APIs) exist, these were built afterwards and not all functionality available via UI consoles is available via APIs that can be used for a control plane. Products tend to be API-first, meaning that all sort of functionality is also accessible via the product API. Therefore ideal for Infrastructure as Code and DevOps.
Centralised management and analytics Each domain and/or cluster would typically have its own central management and analytics console. So in large deployments, additional software, one that can plug into all these domains and clusters, would be required. Part of the product architecture by design. 3rd Gen platforms are built for federation and scalability. Many 
Developer centric Tend to be complicated, both in terms of use and setup/config. Typically product SME's are required to install and support the platform.

Also developer-centric tools such as developer portals, tend to be an add-on of the core offering, they are installed and configured separately, not an intrinsic part of the platform.
Built with Developer Experience in mind. The tooling usability is meant to make the life of the developer easier. Does not require product SME's to set up, use and/or configure -just good developers. Developer centric tooling such as API documentation and developer portals are fundamental components of the product architecture.

Sunday, 8 October 2017

My key takeaways from Oracle OpenWorld & JavaOne 2017

I've just literally arrived from Oracle Open World and JavaOne 2017 and my head still hurts with so many interesting announcements and cool new things I want to get my hands on and learn. This blogpost provides a short summary of my impressions and key takeaways from both events.

General overview:

This year OOW and JavaOne was full of changes from previous ones. For starting most of the sessions took place between Moscone South, Moscone West and the Marriot Marquis, as opposed to all over the place. I understand that this was mainly due to renovations that took place in Moscone which meant that more rooms were available.

JavaOne this year took place in Moscone West (as opposed to Hilton Union Square). First thing that really stroke me was the vast amount of people that seemed to have attended the event (see below tweet from Adam Bien). Not sure if more people attended JavaOne than OOW, but my first observation is that sessions in JavaOne were better attended than those in OOW (at least in the areas am interested on and from what I could see -this is a personal view so don't get offended if you disagree).

My second observation from this year's event was the increased focus to the Developers audience. A clear change of direction from previous years (in my view for good), and it shows that Oracle is committed and trying hard to engage the broader developer communities (not just Oracle's traditional one). In my view Oracle is taking solid and promising first steps towards achieving this goal and hopefully this article highlights some of them.
Overall, really liked the vibe of the event, specially in Moscone West. I was also very pleased to see an open source project am part of (omesa.io) been mentioned a few times :)


Lastly I am happy about how my four sessions went (uploaded the decks already so hopefully they will be made available soon), but specially very happy about the last one (only one I did in JavaOne) as it was well attended even though it was the last of they (before the concert). Developers care about APIs :)
Following my key takeaways in the different areas am interested on:

Key takeaway on application development space:
  • Project FN: Recognising that one of the key challenges in the serverless space is lack of cross-vendor standards, Oracle announced the release of a new fully open source serverless project named named Project FN. This is a solid attempt (also well received by many -including myself) to fill a gap in the industry and create a non-proprietary, Java based, solution for serverless applications that can run in any cloud and on-premises. I personally find this a supper exiting announcement and can't wait to get my hands into it. 
  • Oracle Container Native Application Development Platform: based on the Cloud Native Computing Foundation (CNCF) project, this open source platform delivers a comprehensive, complete and robust solution for building cloud-native microservices anywhere (any cloud and/or on-premises).The solution is composed of the following services: 

My key takeaways in the Integration space: 

  • Oracle Integration Cloud: not to be confused with ICS, this is a new offering that brings together multiple integration products to deliver a comprehensive and complete iPaaS platform. I am actually very pleased about this as I had previously wrote about what an iPaaS platform should look like (click here for the article) and this new offering definitely addresses it.
  • I am a big fan of APIs (if you know me then this is not news!) and I was also happy to capture some key new announcements for the recently launched Oracle API Platform Cloud Service
    • API Plans will be available in about 3 months and will allow for different charging models to be applied to APIs.
    • Native OAuth integration. Not just an OAuth policy (as most API gateways support), this is full blown OAuth Authentication Service (AS) capability that will make it a lot easier to implement different OAuth authorisation flows.
    • Notifications and web-hooks -really cool feature.
    • Partnership + integration with the following products: 
      • API Fortress: For full end to end functional testing of APIs (i.e. OAuth login flows, multiple API calls, etc) 
      • APImatic: for creation of client SDK’s for APIs (in multiple languages) from the API Platform developer portal 
      • Both the above will be sold separately however at a proportional price of platform 
    • Ongoing commitment to continue to fully integrate Apiary into the platform was reiterated several times, including licensing wise (which has been a bit of hassle until now). I am also positive that although Apiary will be fully integrated with the broader API platform,  it will continue to be sold separately so developers using non-Oracle API gateways can continue to leverage Apiary design-first capabilities.
  • Oracle Integration Platform Cloud (OIPC): A comprehensive data integration solution that brings together into a single managed platform in the cloud: Oracle Data Integrator (ODI), Oracle Golden Gate and Oracle Enterprise Data Quality (this latter as I understood only for the OIPC Governance Edition) 
  • Oracle Application Container Cloud supports for Java EE and Go Land. Not a huge announcement but interesting indeed

Headline keynotes takeaways:

  • Larry's main announcement this year the Oracle’s Autonomous Database: from 18c Oracle introduces the world's first autonomous database that claims to Fully automated patching, upgrades, backups, and availability architecture perform all routine database maintenance tasks—without the need for human intervention 
  • Universal credits: put simple, monthly or annual credits that can be used across all Oracle PaaS/IaaS services (including Cloud@Customer). This is an interesting announcement as it'll make the process of purchasing cloud services a lot easier and will also ensure that credits are actually used.
  • Bring Your Own License (BYOL): ability to re-purpose existing on-premise licenses of Oracle database in Oracle PaaS.
  • Lastly also sharing some useful tweets that summarise some of my favourite keynotes:
    • Oracle JavaOne keynote:
  • Oracle PaaS key announcements by Amit Zavery:




Wednesday, 10 May 2017

Oracle API Platform Cloud Service Overview

Oracle has recently announced the release of Oracle API Platform Cloud Service.

Here the official press release.

This new platform -not to be confused with Oracle's previous solution, has been built almost entirely from the ground up to satisfy modern API management requirements.

I have been lucky enough to be part of the beta programme and have actually been implementing the product for the last 4 months or so (but trying it for almost a year now). In this blog post I share some of the insight and experiences I've gained in the process.

What is the Oracle API Platform Cloud Service?
Is a 3rd generation API Platform that delivers a 'true hybrid' model that allows for APIs to be created, deployed and managed centrally (from the Oracle Cloud) whilst API gateways (engines that run the APIs) can be deployed in any cloud (i.e. Amazon, Azure, Oracle Cloud, IBM Softlayer/bluemix, etc) and/or on-premises.

In addition with the incorporation of Apiary into the portfolio, the platform also incorporates a solid/world-class API-first solution so developers also get the tools and means to properly design APIs either using Swagger or API blueprint (Apiary's own API design notation), whilst interacting with the API consumers and therefore ensuring that before any code is built, the API contract is fit-for-purpose.

API Platform Architecture
The platform consists of 7 key components as the diagram illustrates:


  • Management service: The management service is the cloud-based system that underpins the management console, developer portal and platform API. It's the engine of the entire platform. The brains.
  • Management Console:  As the name suggests this is where APIs, Gateways and User/Roles are managed. It's a role-based application so what a user can do pretty much depends on the role the user belongs to.
  • Developer Portal: A web-based application where developers can search and subscribe to APIs. This is where all of the API documentation can be found and also where application keys are provided after a subscription to an API takes place.
  • Platform API: The entire platform was built following an API-first model. In fact, it can be argued that management service is in fact an API, as everything that can be done (and more) via the management and developer portals can be done by directly invoking the Platform API. The platform API is also consumed by the gateways when phoning home to retrieve new API's, policies and also send analytics information.
  • Apiary: As previously mentioned, Apiary is a platform for designing APIs that encourages API designers to maintain an active dialogue with API consumers. Both the management and developer portals are already integrated with Apiary so when a user finds an API in the portal, the API specification (i.e. API blueprint) can also be accessed from one single place.
  • API Gateways: These are the engines that run the APIs and can be deployed anywhere. In any vendor's cloud and/or on-premises. Gateways communicate to the management service iby making API calls (feature known as "phone home"). In this model, it's the gateways responsibility to establish the communication to the "mother ship" (management service) and not the other way around. Because of this, the management of gateways becomes a lot easier as there is no need to open firewall ports (i.e. opening firewall ports) as all communications are outbound triggered.
  • Identity Cloud Service: Most organisations already have their own LDAP directory (i.e. MS Active Directory) where users and roles are managed. The Identity Cloud Service is used to allow the API platform to use an organisation's existing directory as the source for users and roles.
API Platform Roles
The platform by default support 5 types of roles.

  • Administrator: Super user of the platform. Has all rights to deal with user settings and also create/manage APIs and configure gateways.
  • Gateway manager: Role responsable for the gateway operations including deploying, registering, and managing gateways.
  • API manager: The API implementers roles as it gives users full lifecycle rights, including design, create and deploy APIs and also manage the API grants.
  • API designers: Individuals who take on a full or part-time responsibility (i.e. an architect or developer) to define APIs (either in swagger or API blueprints) using Apiary. 
  • Application developer: In other words, these are the API consumers. Users with this role can log into the portal and search/subscribe to APIs.
  • Gateway runtime: Not really a user role, it's a service account used by the gateways to communicate with the to the management service via the platform API. Users assigned this role can’t sign into the Management Portal or the Developer Portal.
User can be created and assigned to any of these roles (excluding Gateway runtime which is a service account). Platform restrictions will apply depending on what role a user belongs to.

Tutorials and Presentations
As mentioned earlier, I've had the opportunity to use the Oracle API Platform for a while now. Below two insightful presentations based the experience implementing the platform:

API Management and Microservices, a Match Made in Heaven
Oracle Code: London, April 2017


Oracle API Platform Cloud Service Best Practices & Lessons Learnt
PaaS Community Forum: Split, March 2017



Other related presentations:

UK Oracle User Group 2016 (Birmingham): Enterprise API Management

Oracle Open World 2016 (San Francisco): Microservices and SOA

Oracle Open World 2016 (San Francisco): Implementing Enterprise API Management in the Oracle Cloud

Oracle Open World 2016 (San Francisco): API Management in the year 2026

AMIS Beyond Horizon (Utrecht) Microservice Approach for Legacy Modernisation

Conclusions
Since I got my hands into this product, I have been really impressed with the elegant, simplistic yet powerful architecture of the Oracle API Platform. It's a considerable step forward from it's predecessor solution but most importantly it was built with modern requirements in mind -meaning that the product doesn't really have any major baggage.

The platform in addition to be lightweight does not enforced an API implementation path. Customers will not be locked into an end to end vendor-stack. For example when using the Oracle API Platform, API applications can be implemented using any technology of choice. This is ideal in microservice architectures where the majority of developers prefer a polyglot programming style. Other vendors for example will force you into a specific implementation path to implement, test and deploy your API applications -which results in vendor lock in.

Because gateways are also fairly lightweight (although I've already heard that future releases of the gateways will be even more lightweight), they really are microgateways and cannot be compared to the traditional appliance-centric, heavy-weight, second generation API platforms.

One more feature that really makes the product unique is the "phone-home" feature of the gateways. What it means is that gateways make a call to the management service to get all instructions regarding APIs to deploy and policies to apply. Meaning that more and more gateways can be added without the typical operations burden of opening firewall ports and troubleshooting failed deployments by looking at logs...

Lastly, the acquisition and incorporation of Apiary into the solution, truly is the icing on the cake! as the solution not only has a simple -yet robust runtime environment, but also a best-in-class API-first design capability.

Well done Vikas, JakubDarko, and Robert and the rest of the Oracle product development and engineering team for finally releasing a world-class future-ready API platform.



If you need help or want to know more about Capgemini's Oracle API Platform offering, please refer to this link.


Friday, 3 March 2017

iPaaS. What is it exactly? is it on-premise software running on IaaS?

As cloud adoption continues to rise, the so called 'second wave' of cloud computing becomes less of a prediction and rather a reality we have to deal with. In the past 2 years or so for example, almost in every customer engagement I've had, 'the cloud' has been at the very least a topic of discussion. In most cases it has actually been within the scope of our activities.

This is not surprising of course as the term 'cloud' itself can mean ten different things to ten different people. The sad part is though, that is has been years since the first wave of cloud (started by Amazon) and there's still a fair degree of confusion in the topic.

In fact, I still often refer to the NIST definition of cloud to explain what cloud computing and PaaS actually is and how traditional on-premises middleware installed on IaaS isn't PaaS or iPaaS. This is in fact one of the main motivators of this post.

iPaaS

The term Integration Platform as a Service, or just iPaaS, is generally used when referring to integration capabilities delivered entirely on PaaS cloud infrastructure.

In terms of integration capabilities, iPaaS can deliver the same (and in many cases more) capabilities than the ones available in traditional on-premise middleware. Such capabilities should be sufficient to satisfy the main types of integration requirements:

Types of Integrations
It is perhaps because of such similarities that, in my experience, there still is a fair amount of misunderstanding of what iPaaS actually is, what it brings to the table and how it's different to traditional on-premise integration middleware.

Some for example wrongly believe that installing a traditional integration product (i.e. IBM BPM or Mule ESB) on IaaS infrastructure will make it iPaaS.

Well this is far from truth. Let me elaborate on why:

iPaaS characteristics

The following diagram is a summary of NIST definition of PaaS, it characteristics and how iPaaS relates to it:

iPaaS Characteristics
As the diagram suggests, for an integration capability (aka integration platform) to be truly iPaaS, it must comply with NIST's 'essential characteristics of cloud computing'. Following my own interpretation of such:
  1. On-demand and self-service: it should be possible, at any given point in time, to go to a cloud vendor website (i.e. https://cloud.oracle.com/en_US/integration), browse through the different iPaaS offerings, select the one wanted/needed, purchase it online, using a credit card of course, and in minutes get an email with all details of the instance (already installed and running), how to access it and even use it. No need to talk with a sales representative, negotiate license costs, provision infrastructure, install/configure the software, and so on.
  2. Broad network access: This is perhaps one of the most important characteristic. Network connectivity to/from iPaaS to other applications has to be fast, reliable and secured. Open internet connection can be unpredictable therefore the cloud vendor must provide alternative means to deliver dedicated high-speed connectivity. For example Oracle Cloud provides a service called Fast Connect, and Amazon a similar one called Direct Connect.
  3. Resource pooling: Compute resources (i.e. cpu, ram memory, disk space) should be allocated on-demand (without human-intervention) based on resource utilisation or via configuration if desired. It should be possible to increase or reduce resources either on demand and/or based on pre-configured rules.
  4. Rapid elasticity: During periods of high demand (i.e. black Friday), predicting resource usage can be almost imposable. A true iPaaS platform should be able to autoscale based on configurable rules and resource demand. Idea is that transaction peaks can be handled by scaling horizontally or vertically -without human intervention. When transaction throughput becomes stable, platform resources should reduce automatically to its original size. It should not be the case that it's possible to rapidly add more capacity, but not the other way around... 
  5. Measured service: pay-per-use / subscription-based charging model with complete transparency and visibility over usage and billing. For example, if a given iPaaS is charged based on number of connections to other applications, it should be possible to know exactly how many connections are being used -at any given point in time. If the number of connections is reaching the limit, a notification should be sent so it's possible to allocate more connections. If on the other hand, the number of connections is in average less than subscribed for, a notification should be sent suggesting to reduce the number of subscribed connections.
  6. Automatic application patching and upgrades: Although not explicitly mentioned, this is another key characteristic and possibly the one that makes iPaaS more distinctive from traditional on-premises middleware. Cloud vendors should be fully responsible for periodically applying patches and/or software upgrades to the purchased cloud infrastructure. It is the vendors responsibility to ensure that patches and upgrades applied are backward compatible and won't break any application.
Considering the aforementioned characteristics, it should hopefully be clear that iPaaS can't be simply delivered by installing traditional on-premise software on cloud infrastructure. 

Be watchful though: Some vendors might try to sell you 'the wooden bicycle' by simply rebranding their on-premises software as iPaaS when all they're doing is provisioning exactly the same on-premises software but on cloud infrastructure (i.e. Amazon EC2). This is known as Cloud Washing.

iPaaS & on-premise integration platforms co-existance

Even though iPaaS can independently satisfy cloud-to-cloud integration needs, it doesn't actually mean that on-premises middleware is no longer required. Quite the contrary.  Most organisations have already made considerable investments in on-premises integration capabilities. In such organisations, even the thought of replacing such capabilities will raise a few eyebrows. 

Instead, on-premise capabilities can continue to be leveraged not only to satisfy on-premises only integration use cases, but also to co-exist with an iPaaS solution to satisfy cloud to/from on-premises integration requirements.

The following diagram illustrates how typical integration patterns can be satisfied with a combination of iPaaS and on-premises integration capabilities.

Hybrid Integration Patterns
Another thing to bear in mind though, given that most software vendors are moving towards a cloud-first delivery model, new products, features, capabilities and even bug-fixes will be made available first to cloud applications and then (if so) to on-premise software.

Therefore in scenarios where for example a new integration capability (i.e. API management) is required which is not already available on-premises, it makes complete sense to consider the adoption of an iPaaS solution instead. Specially those that deliver flexible deployment models whereby runtime engines can be deployed on any infrastructure (cloud and/or on-premises) whilst the management console remains on the cloud.

Conclusion

The adoption of cloud (in all of its flavours: SaaS, PaaS or IaaS) combined with need for organisations to become more digital and user centric, mean that data is not only becoming more and more federated but accessing it in real time and from virtually anywhere is an absolute must. 

However there is no need to 'boil the ocean'. Organisations should continue to leverage their existing integration investments but in parallel define new integration strategies that identify what new capabilities are or will be needed in order to satisfy emerging integration requirements resulting from the adoption of cloud computing and digital transformation.

When possible iPaaS capabilities should be considered not only because they provide more cost-effective licensing models, but also because capability wise, they are better equipped to handle modern and emerging integration requirements. iPaaS also requires less effort to install, configure and run -as most of the work is done by the cloud vendor, including on-going patching and upgrades.

Lastly, avoid cloud washing by ensuring that the selected iPaaS platform satisfies all NIST's 'essential characteristics of cloud computing'. Read my previous blog for a nice comparison of different iPaaS vendors.

Wednesday, 24 August 2016

Comparing Oracle ICS connectors with Workday, Mule, Boomi and Azure

As SaaS adoption continue to increase in organisations of any size, it's only expected that different cloud vendors will stretch their cloud capabilities to try and increase their SaaS/PaaS/IaaS footprints in a clients landscape. This is particularly true for iPaaS related capabilities, as it seems that every cloud vendor has its own related offering and they are pushing it really hard to customers even if there really isn't a one to one fit.

The challenge is though, that organisations that don't carefully elaborate a cloud integration strategy and properly think this through, will almost certainly end up implementing point solutions using whichever iPaaS capability is available for the individual project.  This not only results in vendor lock-in but also increases the complexity and cost of integration.



To avoid this, the first step is to of course create a carefully thought cloud integration strategy with a clear objective in mind. This should be delivering a platform capable of supporting all integration needs (cloud-to-cloud, cloud-to-on-premise) in a seamless and consistent fashion without redundant infrastructures and capabilities. The concept should be something like this:



However the devil is in the detail, or so it goes.

One of the key reasons vendor lock-in occurs is simply because of misinformation. From my point of view, SaaS integration is all about connectivity. So without properly understanding 1) what are the connectivity requirements and 2) what platform best fits these connectivity needs in the short and long term, there is high probability that a solution will not be the right one (may be it will solve the short-term needs, but in the long-run it will probably add more complexity, cost hence risk).

The following table compares Oracle's Integration Cloud Service (ICS) connectors to other major iPaaS vendors (or at least the ones I've come across recently). The table is specially useful if you're in an Oracle SaaS adoption project and want to explain/justify why using ICS will make life easier.


# Connections Oracle Integration Cloud Workday Integration Cloud Mulesoft Anypoint Dell Boomi Microsoft Azure Connectors
1 Adobe eSign (in Using the Adobe eSign Adapter) Y N Y N N
2 Advanced Queuing (AQ) (in Using the Advanced Queuing (AQ) Adapter) Y N N N N
3 Concur (in Using the Concur Adapter) Y N Y N N
4 DocuSign (in Using the DocuSign Adapter) Y N Y N N
5 Email (SMTP, POP3 or IMAP) Y N Y Y Y
6 Eventbrite (in Using the Eventbrite Adapter) Y N N N N
7 Evernote (in Using the Evernote Adapter) Y N N N N
8 Facebook (in Using the Facebook Adapter) Y N Y N N
9 File (in Using the File Adapter) Y N Y N Y
10 FTP (in Using the FTP Adapter) Y N Y Y Y
11 Gmail (in Using the Gmail Adapter) Y N N N N
12 Google Calendar (in Using the Google Calendar Adapter) Y N Y Y N
13 Google Task (in Using the Google Task Adapter) Y N Y Y N
14 Integration Cloud Service Messaging Y N N N N
15 JMS (in Using the JMS Adapter) Y N Y Y N
16 LinkedIn (in Using the LinkedIn Adapter) Y N Y N N
17 MailChimp (in Using the MailChimp Adapter) Y N N Y N
18 Microsoft Calendar (in Using the Microsoft Calendar Adapter) Y N Y N Y
19 Microsoft Contact (in Using the Microsoft Contact Adapter) Y N Y N Y
20 Microsoft Email (in Using the Microsoft Email Adapter) Y N Y N Y
21 Microsoft SQL Server (in Using the Microsoft SQL Server Adapter) Y N Y Y Y
22 MS Dynamics (via REST or Native) Y N Y N Y
23 MySQL (in Using the MySQL Adapter) Y N Y N N
24 NetSuite Adapter Capabilities Y N Y Y N
25 On-premise integration agent  (not just an ESB onpremise) Y N N Y N
26 Oracle Commerce Cloud (in Using the Oracle Commerce Adapter) Y N N N N
27 Oracle CPQ Cloud Capabilities Y N N N N
28 Oracle Database (in Using the Oracle Database Adapter) Y N Y Y Y
29 Oracle E-Business Suite (in Using the Oracle E-Business Suite Adapter) Y N Y N N
30 Oracle Eloqua Cloud Y N N N N
31 Oracle ERP Cloud Capabilities Y N Y N N
32 Oracle Field Service (in Using the Oracle Field Service Adapter) Y N N N N
33 Oracle HCM Cloud (excluding Taleo) Y N N N N
34 Oracle JD Edwards EnterpriseOne (in Using the JD Edwards EnterpriseOne Adapter) Y N Y N N
35 Oracle Messaging Cloud Service Y N N N N
36 Oracle RightNow Cloud Y N Y N N
37 Oracle Sales Cloud Y N N N N
38 Oracle Siebel (in Using the Oracle Siebel Adapter) Y N Y N N
39 Oracle Taleo Y N Y Y N
40 Responsys (in Using the Responsys Adapter) Y N N N N
41 REST Adapter Capabilities (not just HTTP) Y Y Y N N
42 Salesforce Y Y Y Y Y
43 SAP (in Using the SAP Adapter) Y N Y Y Y
44 SAP Ariba (in Using the SAP Ariba Adapter) Y N Y Y N
45 SOAP Adapter Capabilities Y Y Y Y Y
46 SurveyMonkey (in Using the SurveyMonkey Adapter) Y N N N N
47 Twilio (in Using the Twilio Adapter) Y N N Y Y
48 Twitter (in Using the Twitter Adapter) Y N Y N Y
49 Workday (via REST or Native) Y Y Y N N

Below the sources of information I used in the comparison: