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

[Anthony Holloway]

Yeah....still lost.  Possibly even more than I was before.  I'll just see
myself out now.

On Tue, Jun 16, 2020 at 6:44 PM Pete Brown <jpb at chykn.com> wrote:

> 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.
>
>
>
>
>
>
>
>
>
> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for
> Windows 10
>
>
>
> *From: *Anthony Holloway <avholloway+cisco-voip at gmail.com>
> *Sent: *Tuesday, June 16, 2020 3:02 PM
> *To: *Pete Brown <jpb at chykn.com>
> *Cc: *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> 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
> 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/5613970a/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 02C12B8FF08D48118B3172F2F388653E.png
Type: image/png
Size: 60437 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20200616/5613970a/attachment.png>