Making the Cloud, Microservices, and Enterprise IT work!

Suddenly this year clients are calling me up about SOA Governance, service libraries, service monitoring and control.  First SOA was dead, then SOA governance was dead (even saw an article that SOA governance is more than just dead, it’s a murderer, killing the future by stopping cloud computing).  What’s going on with all my customer calls? Here’s a simple fact about services.  Until a significant percentage of frequently used business processes have been exposed, and exposed at a relatively granular (detailed) level (without being too granular that they require re-composition and orchestration every use), the major SOA ROI (return on investment) doesn’t happen.  Kind of like a real world physical library, it won’t have much traffic until either it has a large collection or a collection of popular material. Most SOA efforts begin Bottom Up, with programmers and projects beginning to use SOA technologies simply because they are available and enable getting the job done (rath

  I was recently working with a client on SOA governance / service management.  They’ve build several hundred enterprise services and major integration points, and trying to manually manage them through a web site (or Excel spreadsheet or the brains of the integration department people) is just getting out of hand. This isn’t so unusual, it’s become the classic SOA design time governance problem encountered 2-3 years into the SOA maturity cycle.  While there are those claiming SOA Governance is dead, focused on Design Time Governance (I guess this would be a subset argument of the SOA is Dead punditry), the problem keeps cropping up in Enterprise IT. To be fair to the (Design Time) Governance is Dead argument, few organizations have successfully deployed SOA design time governance.  It’s extremely tricky to insert a tool that touches so many points of the Software Development Lifecycle (SDLC) into the process and not have it rejected or avoided.  It requires adjustments to the e

  The Datapower has an internal structure of components that can inherit or be reused, depending on their place in the inheritance chain.  Here’s the secret internal architecture of the DataPower:   And here’s the Datapower’s capabilities in a nutshell:   Multi-Protocol Gateway: (superset of XML Firewall) Transformations – Any-to-any transformation engine: MPGW can parse and transform arbitrary binary, flat text, and XML messages, including EDI, COBOL Copybook, ISO 8583, CSV, ASN.1, and ebXML. Transport Bridging – protocols such as HTTP, HTTPS, MQ, SSL, IMS Connect, FTP, and more Message-level Security - Messages can be filtered, validated, encrypted, and signed, helping to provide more secure enablement of high-value applications. Supported technologies include WS-Security, WS-Trust, SAML, and LDAP. Logging - logging and audit trail, including non-repudiation support Web Service Proxy: Schema Validation Policy Application SLA Monitoring Load-Balancing

  Ok, this is a little more practical and technical than we usually get, but important nonetheless. The IBM Datapower, as well as similar devices from Layer 7 and Cisco (and others) provide SOA security, attack prevention, and a number of ESB-like abilities (somewhat of an ESB lite).  However, these boxes tend to be EXPENSIVE, as well as having a series of add-on software modules that raise the price significantly. The latter is a shock to many people.  One thinks of the Datapower as a physical device, like a network router.  While it is a physical device and much of it’s performance is based on optimized software placed in ASIC hardware chips, it’s also a very sophisticated software platform.  As such they’ve done the standard vendor thing of separating many of the sophisticated abilities as separate software add-on modules – adding on ability and adding on price.  For example (if I remember correctly), the ability of the Datapower to connect to a database stored procedure and e

  Validation.  Security headers, SAML, WS-Security, etc are useless unless they’re being validated against SOMETHING.  Usually this something is an LDAP, and in a Microsoft environment the Active Directory.  If you’ve got a security device such as a Datapower, it can be configured to perform this validation.  So can many SOA runtime governance and SOA security tools.  Use it! Exclusivity.  Sources of requests must be validated.  If there’s a Datapower (or similar) device in the picture, this means both providers and ESB’s only accept requests from the security device.  If not, security agents have to be configured to validate sources.  If no agents exist, there’s a hole to be exploited. Protocol Independence.  Security rules must remain true regardless of protocol…http, https, ftp, s/ftp, MQ, Tibco, etc. To act in this fashion, every message must contain the XML security header whether it’s sent by HTTP or another protocol such as FTP or MQ.  Security is independent of protocol.

Encryption Every web service call should be SSL encrypted (HTTP/S). Similarly, any web service operation or file transfer sent via FTP should utilize Secure-FTP (S/FTP). Basic level security requires that the receiving source have a valid signed certificate, but it does not require dual-side certificates or any validation of the certificate beyond it being a valid source on a valid root chain. The objective of this requirement is encryption, not authentication. Now encryption will frequently be argued against.  “It’s high overhead, slows things down too much.” and “Setting up security on every server is time consuming.” First, we must layer our security.  By exposing services we’re transmitting internal application data outside the security perimeter of the application!  This data must be protected from view, and dropping a network sniffer onto a developer’s workstation or a development or test server is a trivial exercise.  So even if there’s some overhead, we must