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

Wed Jun 17 19:41:11 EDT 2020

Stephen, good to hear from you.  Thanks for the advice, will focus on device inventories to begin with.  But don’t be surprised if I have to ping you off list for a little guidance.  Again.  😉

I forgot that I already have a presentation planned on July 7th.  It’s being hosted by DevMemphis, but anyone is welcome to join.  I’ll try to make it as engineer friendly as possible.
https://www.meetup.com/memphis-technology-user-groups/events/wvmklrybckbkb/

We’ve been using this specific mesh in production for a little while now.  So far the app owners seem to love it; makes their lives much easier when it comes to automating infrastructure changes.  And we don’t have to give them direct access to all the backend systems, so that’s a plus!

-Pete

From: Stephen Welsh<mailto:stephen.welsh at unifiedfx.com>
Sent: Wednesday, June 17, 2020 12:55 PM
To: Pete Brown<mailto:jpb at chykn.com>
Cc: Pawlowski, Adam<mailto:ajp26 at buffalo.edu>; Anthony Holloway<mailto:avholloway+cisco-voip at gmail.com>; 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

Hi All,

Just noticed this thread, been busy drinking the cool-aid of dotnet core recently ;)

Pete, as always, great work, it’s never a simple project you end up chewing on ;)
Only had a brief look, but that is a big problem you are solving and looks like a powerful approach that has legs. I guess my main suggestion would be to start with one area first, i.e. asset/inventory or configuration management/provisioning etc.
Like Anthony I have little to no knowledge of service meshes, so yes if you are kind enough to share some knowledge I’m down.

Anthony, thank you for highlighting AutomationFX, hope all is well.

Adam, no worries, happy to have a wee call to take you through PhoneView/AutomationFX, although it may help me more than you I suspect ;)

In terms of AutomationFX (the API side we brand as AutomationFX SDK) I’d class it as middleware, consolidating the varied and complex UCM integrations into a single/simple REST API and using web hooks for eventing. So where possible trying to normalise to a very pervasive API pattern to maximise developer reach. In addition we have some plans on a UI (beyond swagger) that should provide a suitable balance between complexity and flexibility that should be acceptable for UC engineers with minimal dev experience.

As AutomationFX is built on .Net (moving to dotnet core ;) it already has and uses SignalR (a Microsoft wrapper on Web Sockets) and therefore capable of realtime events without the need to register web hooks. However I’ve not come across a common pattern for real-time/eventing api’s beyond web hooks so-far that I want to explore yet. The dotnet core version of SignalR has quite an impressive set of capabilities, including streaming support, so may look at a way to leverage that at some point in the future for developer access.

One of the key areas we are focusing on with AutomationFX is JTAPI as that has the greatest middleware benefit and has very careful scaling considerations on larger systems. In addition JTAPI is incredibly chatty, 10+ events for a single call etc. so we have also figured out how to consolidate events to reduce the chatter without compromising latency.

We believe testing (not just with hard phones) is something that will be more important moving forward as complexity increases with more integrated services and hybrid deployments etc.

Thanks

Stephen Welsh
Founder & CTO
UnifiedFX

On 17 Jun 2020, at 17:24, Pete Brown <jpb at chykn.com<mailto:jpb at chykn.com>> wrote:

That’s a respectable amount of work you’ve put into that!  One of the reasons I’m taking the service mesh route is to maximize reusability of existing code like yours.  I spent years writing Perl scripts for ETL and automation functions.  I wouldn’t say that time was “wasted” because it got the job done, but now most of those scripts are useless.  They weren’t written in a way that allowed their functions to be called by other processes.

Last night I spent a few hours trying to find a quick intro on service meshes & API gateways.  Most assumed a bit of development experience; couldn’t find anything that would be useful for most UC folks.  I wouldn’t mind throwing a presentation together if someone has a BrightTalk account.  And there’s interest, of course!

-Pete

From: Pawlowski, Adam<mailto:ajp26 at buffalo.edu>
Sent: Tuesday, June 16, 2020 7:55 PM
To: Anthony Holloway<mailto:avholloway+cisco-voip at gmail.com>; 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

This is more or less what I had been doing internally at a very primitive level, and its been very valuable but quickly consuming of a ton of time to try and account for the items and interactions between them.  I have to more or less abandon Ruby at this point given that gems are not being updated and things are starting to be a problem to maintain for me, oh well.

The Ruby gem I coked up abstracts a user object with details pulled from LDAP, UCM, Unity Connection, and lets me interface with local resources or write simple reports. It is what I used to write a basic CSV Jabber import (stripped way down to just basically AXL) tool, though no one took me up on it for import over BAT. I think they’re nuts to use that.

I am still unclear on what a service mesh is, but, my overall vision was to have some sort of abstracted layer that monitors some level of object history, but allowed me to tether business rules and systems to actions in the data systems. It became pretty quickly obvious a job engine, call brokering and buffering, intermediate database with reconciliation and clean up jobs, etc would be needed on top of trying to define the way the objects actually interact with each other. I don’t have the time.

I did not look into AutomationFX, and I’ll earn some ire for this, but, we have used both PhoneView and MigrationFX. PhoneView I have largely gotten past internally with my own tooling but it is great for the rest of the team looking to do a quick data dump or get some data for reporting and with it’s built in data cache it’s pretty good. MigrationFX seems to be built on top of AutomatioFX, but, while better than going to each phone and configuring a new one, has had a clunky interface that doesn’t appear to be possible to secure when using older phones, at least per my coworkers, and I don’t want to invest my efforts into that.

I’d love to see something like this, but I wonder how complicated it would have to be to be ubiquitously useful.

Adam

From: cisco-voip <cisco-voip-bounces at puck.nether.net<mailto:cisco-voip-bounces at puck.nether.net>> On Behalf Of Anthony Holloway
Sent: Tuesday, June 16, 2020 8:34 PM
To: Pete Brown <jpb at chykn.com<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

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<mailto: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.

<image001.png>

Sent from Mail<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgo.microsoft.com%2Ffwlink%2F%3FLinkId%3D550986&data=02%7C01%7C%7C55197a9c5e0042afe7c908d812e79718%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637280133363097765&sdata=oboe33t%2FvUZ3Sd6uYEY%2Fo1G9ug59myyjXKtyqE1m2oM%3D&reserved=0> 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://eur01.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%7C55197a9c5e0042afe7c908d812e79718%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637280133363107768&sdata=lJ3OIZewckxh%2BthJoN9s%2FEms6BEz%2BBznCnSdz%2FgvB%2F0%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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fadhdtech%2FDRP&data=02%7C01%7C%7C55197a9c5e0042afe7c908d812e79718%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637280133363117755&sdata=sAjnWJXNMqWQkal3BurPJKFYbeHBbyPj745XyVSUEC4%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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.nether.net%2Fmailman%2Flistinfo%2Fcisco-voip&data=02%7C01%7C%7C55197a9c5e0042afe7c908d812e79718%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637280133363127750&sdata=bXZ234UVhecvcHTNxPASPd1WiW0Eg%2FOsIqQFKeTqZPg%3D&reserved=0>

_______________________________________________
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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.nether.net%2Fmailman%2Flistinfo%2Fcisco-voip&data=02%7C01%7C%7C55197a9c5e0042afe7c908d812e79718%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637280133363137750&sdata=MCe7KwdL%2FnOI0Vbg9gV5xE0XI6QZm5AV8vwdc4pQBdM%3D&reserved=0>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20200617/59994cbf/attachment.htm>