HealthIT Interfacing in the Cloud

I've been thinking a lot lately about Interfacing in the Cloud, and Microservices strategies, and how that makes things different.  Consider interface engines today.

The classic interface engine is a piece of middleware that supports a number of capabilities:

1. Routing
2. Queuing
3. Transformation (message reformatting, tweaking messages)
4. Translation (codes, cross walks, et cetera)
5. Monitoring and Management
6. Transport (HTTP/HTTPS, TCP, SOAP, FTP/SFTP, REST, SMTP/IMAP/POP3)

It's a piece of enterprise middle-ware, and classically a monolithic application that allows you to build highly orchestrated pipelines to do the work.

In the micro-services world, each of these areas could be its own bounded context, with a few extra pieces thrown into the mix (e.g., the Message itself is probably a bounded context shared by many pieces).  Instead of building highly orchestrated message pipelines, we could instead be building choreographed services, even one-off services to support specific needs into operation pipelines that would be highly scalable and configurable in a cloud environment.

It's an interesting approach that I frankly haven't seen anyone take on well yet.  Mostly what I'm seeing is interfaces moving into the cloud first as a great big chunk ... running in a Windows VM somewhere to start off with.  Then some decomposition into parts, and finally, maybe a rational micro-services architecture.  Eventually, I think we'll get there, but I'm not so certain that the emerging victor in the Interface engine competition is going to be one of the current leaders.  It's possible, but sounds very much like one of the classic scenarios found in The Innovator's Dilemma.

I'm not entirely happy with the current situation.  I think cloud needs different thinking and a different way of doing things to handle interfaces. I really hope I don't have to build it myself.

   Keith

Code Once, Cloud Anywhere

One of the challenges with Cloud is that there are many new paradigms to deal with and every cloud provider wants you to use their own custom APIs for connecting an enterprise to a cloud.  We know what happens there.  You get locked in to doing things the way that one cloud vendor does it, and then you wind up being stuck when you need to work with a different cloud vendor for something else.

With cloud computing becoming so much more ubiquitous, the idea that you are going to be able to work with just one Cloud vendor is stretching things just a bit thin. 

What I want for my interfaces is code once, Cloud anywhere.

Building an infrastructure that doesn't take advantage of all of the bells and whistles of ones chosen cloud provider has its costs (usually in terms of performance and developer efficiency).  But rewriting code to switch or add cloud providers has a cost as well (often in terms of lost opportunities and delays).

Microservices will help greatly as long as they are truly "micro" and have limited dependencies.  But there are cases where you just don't want to hide the power of your cloud infrastructure (e.g., queries to document storage) from your enterprise endpoints accessing data in the cloud.  That's where standards should help.

One way around this is to utilize standards but you have to look at things just a little bit differently when you do this for Cloud ... because you are typically working at a different level (often both lower and higher) than you would for applying application standards.

These are some of the areas I'm looking into standards to apply for use with Cloud, along with standards that I've managed to identify.  Granted, this list is very weak, but I've also only just begun this exploration.

Security
Encryption (TLS)
Authentication (OpenId)
Authorization (OAuth 2.0, SAML)

Operations
Audit (also fits under security)
Telemetry and Monitoring

Communications/Transport
Messaging (AMQP)
Document Storage (JSON, MongoDB API)
Blob Storage (S3)

So, if you have any thoughts about standards that should be applied in cloud computing, I'd be happy to hear about them in your comments below.

    Keith