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 <[email protected]> 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 <[email protected]> > *Sent: *Tuesday, June 16, 2020 3:02 PM > *To: *Pete Brown <[email protected]> > *Cc: *[email protected] > *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 <[email protected]> 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 > [email protected] > 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> > > >
_______________________________________________ cisco-voip mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-voip
