[cisco-voip] Consolidating access to Cisco CUCM APIs via Service Mesh

[Pete Brown]

Thanks for mentioning AutomationFX.  That’s exactly the sort of API consolidation I was thinking of.  Should’ve guessed the guys at UnifiedFX had already done something along these lines!  I’ll probably still build a CUCM mesh agent just to demo the marrying of access to objects & their associated data streams.  But it won’t be near as complete as AutomationFX.

Wouldn’t say ignorant at all.  Service meshes (Istio, etc) in their current form have only been around a few years.  Even most developers I talk to haven’t really touched them beyond POCs.  Mainly due to the complexity since they all require the use of Kubernetes.  The concept has never really been applied to infrastructure sources before, especially in a vendor agnostic way.  In infrastructure we’re dealing with a federation of loosely coupled data sets instead of something that a single architecture group came up with.

To answer the question of “why” regarding the mesh I’m working on, it’s to eliminate a bunch of the common pitfalls in traditional integrations.  Instead of finding and calling each source directly using different client libraries, the mesh provides a single method of executing RPC & pub/sub operations against backend services.  You can even navigate the resources like a directory structure.

In this mesh, the backend services register themselves and declare their functions, object schemas, etc.  That’s why I say it’s sort of a hybrid between a service mesh and a data mesh; you can call service functions or search on object class attributes regardless of source.  Clients who need to access sources make calls to the Brokers.  Very roughly analogous to a “meshified” version of SNMP.

Here’s a before and after of what an Ansible script might look like calling difference sources.


[cid:image001.png at 01D6440B.B0577920]


Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10

From: Anthony Holloway<mailto:avholloway+cisco-voip at gmail.com>
Sent: Tuesday, June 16, 2020 3:02 PM
To: Pete Brown<mailto:jpb at chykn.com>
Cc: cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
Subject: Re: [cisco-voip] Consolidating access to Cisco CUCM APIs via Service Mesh

You lost me there, as I'm too ignorant to understand what an API mesh is, but this sounds very familiar to what UnifiedFX is/was doing with AutomationFX, is it not?  Or am I again showing my ignorance?

On Tue, Jun 16, 2020 at 12:32 PM Pete Brown <jpb at chykn.com<mailto:jpb at chykn.com>> wrote:
TLDR – Developing a hybrid service/data mesh for interacting with infrastructure services.  Thinking about what a modern, consolidated API might look like for CUCM.

I was scheduled to give this talk at DevNet Create until everything was shut down…
https://github.com/adhdtech/DRP/blob/master/DevNet%20Create%202020%20-%20Making%20a%20Mesh%20of%20the%20Infrastructure.pdf<https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fadhdtech%2FDRP%2Fblob%2Fmaster%2FDevNet%2520Create%25202020%2520-%2520Making%2520a%2520Mesh%2520of%2520the%2520Infrastructure.pdf&data=02%7C01%7C%7Cd6a891dd87c54621067108d8123041fd%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637279345751719757&sdata=dyBvjV7Fh1Wk6XYSOaQGqXfl65bjxthF50%2FWuEKSz54%3D&reserved=0>

For the demo I had data from a few of the CUCM APIs being piped into a consolidated logical model.  Nothing too complex; just users, devices and associated JTAPI streams.  It got me to thinking, though.  If you could snap your fingers and have a modern, consolidated API for interacting with CUCM services, what would it look like?  Not just RPC operations, but pub/sub as well.

I’m considering creating a mesh service agent for CUCM.  Instead of leveraging the existing APIs, the goal would be to effectively replace them and inject their capabilities into the mesh.  Before I do, I’m trying to figure out what some of the “must have” features would be for a POC.

The project README needs some updating, but it does give a general idea of how everything works.  Recently added a command shell; need to get that documented.
https://github.com/adhdtech/DRP<https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fadhdtech%2FDRP&data=02%7C01%7C%7Cd6a891dd87c54621067108d8123041fd%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637279345751729741&sdata=%2BayXqiSdtWHtbnS5ZsAfS1k3cU%2BZ3rLo59oA1NtX3nA%3D&reserved=0>

-Pete

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip<https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.nether.net%2Fmailman%2Flistinfo%2Fcisco-voip&data=02%7C01%7C%7Cd6a891dd87c54621067108d8123041fd%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637279345751739738&sdata=f0jlP20VlNLd9zIENVXVvcB%2BguROK6VN54qnc7Ina2M%3D&reserved=0>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20200616/3eb05a4c/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 02C12B8FF08D48118B3172F2F388653E.png
Type: image/png
Size: 60437 bytes
Desc: 02C12B8FF08D48118B3172F2F388653E.png
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20200616/3eb05a4c/attachment.png>