Would have had her, of a select few, hidden from death forever, if it was in my power. We are all powerless, except as we are remembered. Brevity does not do justice to her life.
Wednesday, November 23, 2016
Susan Tilsley Manley - 1965-2016 - Artist, Friend.
Would have had her, of a select few, hidden from death forever, if it was in my power. We are all powerless, except as we are remembered. Brevity does not do justice to her life.
Monday, November 21, 2016
Look Inward. Look Outward. Break it Down.
There are two types of entites in an organization. Those that look inward and those that look outward. This applies to any size organization. Each extreme is deadly. Too much inward looking and one loses sight of all the ways the world moves on organically outside. Too much outward looking and ones loses all sense of self control. The middle road seems worthwhile. All things in moderation.
The same inward and outward view is true of one's, potential and existing, customers or believers. The hope is to match outward and inward appetites.
Most very large organizations fall into looking inward. They focus on internal issues. They become protective. And they often close their borders. They raise up walls. This can work for awhile - especially when everyone in a domain is looking inward - including clients.
But in the face of even a moderate amount of client and competitive outward looking behavior, introspection is ultimately doomed. It is like the network effect: The power of the arrangement is more than simply a linear function of the participants. It goes more like the scale of potential connections.
This is, in technical microcosm, the story of APIs and microservices. The move to outward facing APIs and microservices is a reflection of the larger effect of a move to looking outwards overall.
Fintech organizations (banks "which can be defined as a bank or division thereof") now a see a world where it is important to look for new vehicles and new services. And to actively partner and acquire those vehicles. One bank buying another bank wants seamless integration. The melding should be about business initiatives and synergies and not about whether COBOL speaks to Fortran... those days are long gone. And the days where differences could be used an effective protective wall are likewise gone.
Industries where there are walls:
PLC communications. Cold chain management. Security systems.
Domains where the walls have been broken down:
Google maps and APis in general. AWS, Cloudfoundry and VMware systems. Network management protocols: Cisco.
Areas in transformation:
Building automation - witness a move to RESTful webservices.
Certain types of industrial automation - witness MTconnect. Platforms like GE Predix for IIoT. Renewable energy management - witness Sunspec and others.
Tools and platform providers are deaggregating- witness Microsoft Azure and IBM Bluemix.
Even energy itself is being deaggregated with Microgrids - with a strong analogy to microserviecs and APis. Utilities which continue to look inward will have serious problems.
There can be no knowledge without looking inward and outward. One needs to work on the viewpoint where one is most blind.
The same inward and outward view is true of one's, potential and existing, customers or believers. The hope is to match outward and inward appetites.
Most very large organizations fall into looking inward. They focus on internal issues. They become protective. And they often close their borders. They raise up walls. This can work for awhile - especially when everyone in a domain is looking inward - including clients.
But in the face of even a moderate amount of client and competitive outward looking behavior, introspection is ultimately doomed. It is like the network effect: The power of the arrangement is more than simply a linear function of the participants. It goes more like the scale of potential connections.
This is, in technical microcosm, the story of APIs and microservices. The move to outward facing APIs and microservices is a reflection of the larger effect of a move to looking outwards overall.
Fintech organizations (banks "which can be defined as a bank or division thereof") now a see a world where it is important to look for new vehicles and new services. And to actively partner and acquire those vehicles. One bank buying another bank wants seamless integration. The melding should be about business initiatives and synergies and not about whether COBOL speaks to Fortran... those days are long gone. And the days where differences could be used an effective protective wall are likewise gone.
Industries where there are walls:
PLC communications. Cold chain management. Security systems.
Domains where the walls have been broken down:
Google maps and APis in general. AWS, Cloudfoundry and VMware systems. Network management protocols: Cisco.
Areas in transformation:
Building automation - witness a move to RESTful webservices.
Certain types of industrial automation - witness MTconnect. Platforms like GE Predix for IIoT. Renewable energy management - witness Sunspec and others.
Tools and platform providers are deaggregating- witness Microsoft Azure and IBM Bluemix.
Even energy itself is being deaggregated with Microgrids - with a strong analogy to microserviecs and APis. Utilities which continue to look inward will have serious problems.
There can be no knowledge without looking inward and outward. One needs to work on the viewpoint where one is most blind.
Tuesday, November 15, 2016
GE Minds and Machines 2016 - November 15,16 - Pier 48 SF.
Was a real pleasure to attend GE Minds and Machines 2016, November 15,16, Pier 48 SF.
Highlights:
Current EMS Announcement. Here is a great talk by John Gordon. Also many new Current partners. Analytika is but one.
Meridium APM. Analytics for risk, availability and value management. Some great technical points made by Meridium. High in mind was a comment in an APM technical session that the majority of faults are not time related.
Many new players in the GE Digital ecosystem. TCS making great use of Predix Analytics. BitStew helping utilities. Too many to go into detail.
Highlights:
Current EMS Announcement. Here is a great talk by John Gordon. Also many new Current partners. Analytika is but one.
Meridium APM. Analytics for risk, availability and value management. Some great technical points made by Meridium. High in mind was a comment in an APM technical session that the majority of faults are not time related.
Many new players in the GE Digital ecosystem. TCS making great use of Predix Analytics. BitStew helping utilities. Too many to go into detail.
Thursday, November 10, 2016
IoT and Security. Edge. Network. Tracking.
Security and IoT is a topic impossible to avoid. With the days of modern APIs, and smart edge devices, the days of isolated LAN architectures are numbered.
Recent DDoS attacks show systemic vulnerability in IoT device deploys. Some have taken the walled garden approach: Do not allow the user/owners local access to their devices. But that is not really what the customers want.
Others go with the status quo from twenty years ago. They transparently indicate their devices are for open shared LANs, and one had best put a series of walls around them. To be technical: Put them in a virtual private network. This puts a load, without much benefit, on IT. It also ignores internal to network breaches... systematic or accidental.
There has to be a middle road. Some set of practices that is acceptable to end points and users, and IT and the enterprise.Three seem to arise.
One:
Make some effort with the edge devices. This is old school but just recently becoming standard practice for IoT devices. When "password" is used below it can be interchanged with the term "access token" or even "authentication method".
A. Make sure edge devices have passwords.
B. Close all access methods not related to setup and operation.
C. Make sure no setup or access method can be repeated quickly, either to probe for entry, or deny others service.
In a way the ABCs are non-negotiable. D probably hardest, but most important:
D. Make sure edge devices have good passwords.
This can be done by demanding first configuration password changes... Good for pilots, but unscalable in interesting large deploys. The other way is to set a strong and unchangeable password... which cannot by any means be deduced from the network. Generating a password from a network interface MAC address is close to this... except when MAC addresses leak from LAN to WAN - like when MAC are used for generating other defaults. Keeping manufacturer "cloud" databases of passwords leaves the end device a brick when the service expires. [NOTE this does not imply the owner of the device or the LAN on which it resides should not build and maintain a database of passwords - that is just their responsibility]. The key seems to be a unique long and strong local password, easy for human or machine entry, stored out of band, and only locally accessible. There are patentable and trade secret pathways therein... so let us leave it at that *grin*. Much of the above deserves genesis credit to James Lyne at a Xively Xperience 2015.
Two:
VPNs are still not easy to setup. And within a VPN their are no access controls. Modern IoT uses cases of remote service beg for a way to keep the setup interfaces, for example of a motor controller and its allied pressing machine controller, available only to select external parties, while they freely communicate with each other directly in the LAN. This speaks to access control lists - ACLs. Modern microservices architectures are forging a pathway here where even "interprocess" communications needs and has ACL-like constructs. True ACL-likes are heavy weight and hard to configure... and add more pain to IT setup.
Can ACL-like setup, for by-port access tokens, be automatically templatized and deployed automatically? Software defined perimeter is an emrging standard with offerings from those like Cryptzone. Some like Illumio for VMs and containers have a method which might transfer well from IT to OT.
Three:
Testing, tracking and logging. As well as one might develop edge and core and network and database strategies, they can be pried by inquiring minds, they can be broken by accident or misuse. One needs to do testing (like API testing by Smartbear, for development and production - DevOps)... but even more important, one needs continuous monitoring, so that one can learn each time something new arises -and something new will arise - one can find ways around passwords and network access controls.
At minimum on LAN and WAN, one should try watching transactions with Nagios. Wireshark tends to not run all the time, and MRTG is somewhat limited. And if one goes further there are tools for various types of tracking. Like those from Genians and PRTG. Will go further than tools and suggest one needs to consult with someone who has experience in real world, in the wild, large deploys and monitoring thereof. Like Cimetrics has with Analytika for automation systems.
Recent DDoS attacks show systemic vulnerability in IoT device deploys. Some have taken the walled garden approach: Do not allow the user/owners local access to their devices. But that is not really what the customers want.
Others go with the status quo from twenty years ago. They transparently indicate their devices are for open shared LANs, and one had best put a series of walls around them. To be technical: Put them in a virtual private network. This puts a load, without much benefit, on IT. It also ignores internal to network breaches... systematic or accidental.
There has to be a middle road. Some set of practices that is acceptable to end points and users, and IT and the enterprise.Three seem to arise.
One:
Make some effort with the edge devices. This is old school but just recently becoming standard practice for IoT devices. When "password" is used below it can be interchanged with the term "access token" or even "authentication method".
A. Make sure edge devices have passwords.
B. Close all access methods not related to setup and operation.
C. Make sure no setup or access method can be repeated quickly, either to probe for entry, or deny others service.
In a way the ABCs are non-negotiable. D probably hardest, but most important:
D. Make sure edge devices have good passwords.
This can be done by demanding first configuration password changes... Good for pilots, but unscalable in interesting large deploys. The other way is to set a strong and unchangeable password... which cannot by any means be deduced from the network. Generating a password from a network interface MAC address is close to this... except when MAC addresses leak from LAN to WAN - like when MAC are used for generating other defaults. Keeping manufacturer "cloud" databases of passwords leaves the end device a brick when the service expires. [NOTE this does not imply the owner of the device or the LAN on which it resides should not build and maintain a database of passwords - that is just their responsibility]. The key seems to be a unique long and strong local password, easy for human or machine entry, stored out of band, and only locally accessible. There are patentable and trade secret pathways therein... so let us leave it at that *grin*. Much of the above deserves genesis credit to James Lyne at a Xively Xperience 2015.
Two:
VPNs are still not easy to setup. And within a VPN their are no access controls. Modern IoT uses cases of remote service beg for a way to keep the setup interfaces, for example of a motor controller and its allied pressing machine controller, available only to select external parties, while they freely communicate with each other directly in the LAN. This speaks to access control lists - ACLs. Modern microservices architectures are forging a pathway here where even "interprocess" communications needs and has ACL-like constructs. True ACL-likes are heavy weight and hard to configure... and add more pain to IT setup.
Can ACL-like setup, for by-port access tokens, be automatically templatized and deployed automatically? Software defined perimeter is an emrging standard with offerings from those like Cryptzone. Some like Illumio for VMs and containers have a method which might transfer well from IT to OT.
Three:
Testing, tracking and logging. As well as one might develop edge and core and network and database strategies, they can be pried by inquiring minds, they can be broken by accident or misuse. One needs to do testing (like API testing by Smartbear, for development and production - DevOps)... but even more important, one needs continuous monitoring, so that one can learn each time something new arises -and something new will arise - one can find ways around passwords and network access controls.
At minimum on LAN and WAN, one should try watching transactions with Nagios. Wireshark tends to not run all the time, and MRTG is somewhat limited. And if one goes further there are tools for various types of tracking. Like those from Genians and PRTG. Will go further than tools and suggest one needs to consult with someone who has experience in real world, in the wild, large deploys and monitoring thereof. Like Cimetrics has with Analytika for automation systems.
Sunday, November 6, 2016
APIStrat 2016 Boston November 2-4.
First week of November 2016 was API week in Boston. Still trying to absorb APIStrat 2016. Presentations the same week with similar API themes from IBM, SmartBear and GE Predix.
API? Had in mind the API definition from Wikipedia. But the core is now more what is defined above as "Web API". API is about REST, SOAP - MQTT, CoAP - etc.
Presentations in past months and years on IoT from Axeda, Thingworx, PTC and IBM Bluemix and AT&T M2M and Amazon Alexa/Lambda were in retrospect more about APIs than anything else. The APIs for endpoints and platforms for IoT have been building. BACnet Web Services is but one example.
API is more than a "definition". API is about the rising ecosystem of business use cases and tools for APIs. Swagger, RAML, OpenAPI , Stoplight, even Postman, CURL and choices regarding REST, SOAP, XML, JSON and so forth.
Gartner analyst APIStrat keynote: Mark O'Neill : Business use cases gelling. Rich ecosystem of tools and cases for API creation. But also cases for API consumption... and there is a business opportinity therein. [Also *grin* Why are digital voice assistants like Alexa and Siri always depicted or embodied round? Are polygons too edgy? ]
Great easy venue for APIstrat at Marriott Long Wharf on Blue Line MBTA.
Presentations in past months and years on IoT from Axeda, Thingworx, PTC and IBM Bluemix and AT&T M2M and Amazon Alexa/Lambda were in retrospect more about APIs than anything else. The APIs for endpoints and platforms for IoT have been building. BACnet Web Services is but one example.
API is more than a "definition". API is about the rising ecosystem of business use cases and tools for APIs. Swagger, RAML, OpenAPI , Stoplight, even Postman, CURL and choices regarding REST, SOAP, XML, JSON and so forth.
Gartner analyst APIStrat keynote: Mark O'Neill : Business use cases gelling. Rich ecosystem of tools and cases for API creation. But also cases for API consumption... and there is a business opportinity therein. [Also *grin* Why are digital voice assistants like Alexa and Siri always depicted or embodied round? Are polygons too edgy? ]
Great easy venue for APIstrat at Marriott Long Wharf on Blue Line MBTA.
Subscribe to:
Posts (Atom)
