As catch-up, I’m writing two blogs this week. This series will end one day, and then I’ll be able to write some positive stuff about AWS too. I am actually a big fan. Today’s topic is about web services integration.
A good definition of a web service is: a software function provided at a network address. It is designed to support interoperable machine-to-machine interaction over a network. There are a range of different standards including SOAP (XML/HTTP), JSON and RESTful interfaces. Web services are used everywhere and for everything these days.
Applications can be constructed by mashing together multiple web services that can be hosted anywhere. Web services are used to manage all layers of a system: the infrastructure (a great little article on AWS APIs), supporting software (eg. Heroku) and the application itself (eg. Salesforce). These are all examples of APIs represented through a web service.
Over time as platforms and applications are constructed from many disparate web services, that are hosted both internally and externally, your organisation’s architecture, (including application, security and network) becomes increasingly entangled. I’ve tried to represent this in the diagram below.
This confusion was already a problem when an application was predominantly in-house, but is an order of magnitude more complex when mashed with the cloud. Microsoft Azure allows integration via an outbound relay connection. Amazon allows integration via a network level VPN. All web services can be connected via web proxies, and there are many ways of implementing these.
One way of limiting this confusion is by implementing an integration bus somewhere in the stack. This would limit the number of point-to-point web services and therefore drive standardisation of a common set of security and network integration points.
My question today is: How would you go about limiting and controlling this confusion? Thoughts?
3 Comments