The big 5 areas to nail when moving to the cloud

Back when I worked for a large bank my manager – a shrewd thinker – was asked what he would do to the IT infrastructure if he had infinite time and money. His answer was that he’d tear it all down and start again. When 9/11 destroyed many buildings in lower Manhattan, some organisations had to do just this.

It’s an interesting thought-exercise because you arrive at a different target state when you think this way, than when you start with an existing set-up and incrementally change your environment.

From what I’ve seen of cloud transformations across different organisations, I’ve found five key areas you need to consider, that are difficult, oft-neglected areas. The way you approach these five depends very much on whether you are starting from scratch or not.

I’ll deep-dive into them in future posts but for now a brief summary (with no particular priority):

1. Identity

Now that platforms, systems, devices etc. are outside your network, how do you identify and provisions users? How do you make sure it’s only Jim who is accessing his iPad and using an approved SaaS provider that uses data from a core internal system? How do you deprovision him and his access when he leaves one Friday to go work at a competitor? The management of identity in the new era requires new platforms and skills. When this area is ignored you start to lose control pretty quickly.

2. Network

Networks used to be like medieval castles. There was a big wall with guards and a few entrances. Legacy networks were built on this paradigm. But today your device could physically be on a public network whilst logically on a companies network. You could be logically managing your network on someone else’s infrastructure (think AWS VPCs). Some applications will be hosted externally and require access to internal systems.

The medieval city has lost its walls and people are roaming freely. Your data assets need to be locked in suitable safes in different towers, with access by appointment only.

50205631_9fe31fa184_o

FIVE – Photo Friday (Andrew Morrell via Flickr)

3. Service Management.

Service Management is not sexy. Remember all the guys who won awards and got ‘5’s on their balanced, normalised, bell-curve yearly performance review/scorecard? Never happened.

Problem, Incident, Change management etc., that is ITIL stuff, is still important but now the configuration items you manage could be somewhere else. There are externally hosted partners responsible for parts of your service.

You will need to agree with them how to manage and measure the service levels of their components. And they will have their own service management platform and processes (hopefully). Where are the demarcation lines and how do these service management platforms share data? When a major incident occurs how do you know that everyone has the same information and is working in a coherent fashion?

4. Integration

I heard this best described at a vendor demonstration. Systems of record are being separated from systems of engagement. In the past you had a monolithic system that was both a system of record and engagement.

Today, a system of engagement could be a SaaS provider or a mobile App. How do you get data from one to the other? Also externally hosted systems may need access to core company data. Previously you may have had to integrate platforms across an internal network. Now you need to integrate platforms across many providers and geographies.

5 Vendor Management

Vendor management in the old world was somewhat different to the new. The new world is fluid with expectations of quick on-boarding and off-boarding. The market is bigger with many diverse providers rather than the usual chosen few. There are considerations about data sovereignty, off-boarding etc. that you have never had to consider before. There has to be more collaboration between technology teams and procurement teams to understand how these external solutions work and protect data.

That’s my big five. I haven’t included anything about the server platform, orchestration, storage etc., because I think there’s less impact if you stuff them up. You can always adapt. If you get my five wrong, the consequences are significant. And across all of these big five you need to consider security as well.

As always, thoughts in the comments below.

Who are your best local cloud providers?

It’s easy to find a cloud provider right?

Until you’re told you have to use a locally-hosted provider! And then you’re told to find perhaps a locally-hosted and locally-owned provider?

I need you to share the names and URLs of locally available cloud IaaS providers in your country. I’m compiling a list for Canada, Mainland Europe, New Zealand, UK, India, China, South Africa and of course US (although they own all the big providers). Feel free to share in the comments.

Here’s what I found for the Australian market in no particular order (Feel free to add to this):

Hosted in Australia:

  • AWS
  • Dimension Data,
  • Telstra,

Hosted and Australian-owned (I think):

  • NEXTDC,
  • Cloud Central,
  • Decimal,
  • Bulletproof,
  • CloudCentral,
  • UltraServe,
  • Brennan IT,
  • Macquarie telecom

How to fix your private cloud – Part 5

In parts 1-4 of this blog series we explored some reasons why private clouds bombed. In this final blog, I’d like to discuss a better approach

Finding examples of successful private clouds is difficult because many organisations claim to have a private cloud when in fact all they have done is install VMware. If a project manager has to organise a resource to install something it’s not a cloud. Cloud is not virtualisation.

If you were starting a private cloud environment build 3 years ago, it would look different to one you would begin building now. But I like to live in the here and now so let’s look at what we would do now.

For starters, reverse these unspoken principles:

  • IT departments do not need to communicate with their users.
  • IT departments are needed and irreplaceable.
  • Users don’t know their needs and IT departments do.

Then approach as shown below. Users care about the items closer to the top.

Private cloud approach

Now, look at your best use-cases and choose a champion project/platform/department to partner with so you can create one end-to-end service.

Then get the right people on board to build it out. The guy who built your virtualisation stack back in the naughties probably doesn’t have the social intelligence (and hygiene) to approach users and “communicate”. Users value the speed in which resources can be allocated to them, the simplicity of getting their work done and the lack of friction involved so put someone in charge who understands public clouds, understands service design and delivery and is willing to start with an open mind. Then create a list of services you wish to offer.

Eventually after much work and discussion you’ll get to the point where you understand the services you want and what is required of the technology to support your cloud. This is where you may get derailed. Whatever happens make sure your choices minimise “tinkering”, promote scalability through modularity, and can work with your current network.

Your network may suck. It may make providing access to external and internal users difficult. It may be impossible to converge data and storage networks. If so, you could wait for SDN to mature and your CIO to give you budget for a Network Refresh or…

  1. You could build the cloud off-premises. Private cloud is used only by internal users but can be built anywhere. So build it in Rackspace or AWS, or a local provider if data sovereignty is an issue.
  2. You could build the cloud on converged infrastructure which includes its own networking. Something like vBlock or FlexPod. Converged Infrastructure is modular, making it easy to add and manage computing power, storage or networking throughput. The seamless coordination between hardware manufacturer (compute, storage and networking) and virtualisation is key to private cloud computing. It resists “tinkering”.

You’ll need more tools over time to manage this because of new standards and platforms, capacity-managing a pool of resource aggregated at a data-centre level, and also in planning for the hybrid cloud (which may exist for real one day). But all in good time.

The cloud is essentially a vending machine. It’s an automation-oriented, self-service approach to IT. Anything else is folly.

Businesses that run on the cloud: Annex Products

I ran into Rob Ward at a recent StartupGrind and he came across as very personable, relaxed and successful. He is a Founder at Annex Products, who make the incredibly popular Quad Lock cases for mounting smart phones on bikes, cars and people.

We caught up a few days later for a coffee near his office in Prahran. The Annex office had a cool set-up with ping-pong table, arcade machine, 3D Printer, quadcopter and lots of prototypes. His team were working behind 27-inch iMacs running Solidworks for CAD and for everything else it was the just usual Dropbox, Pages, Numbers, Adobe Creative suite and Final Cut Pro.

I intended to ask him about the different platforms they used to manage and run their business, but we spent quite a bit of time talking about sales and marketing. He sees Annex as a brand and product design business. Great design is important but “isn’t enough to stand out from the crowd”. You need good sales and marketing.

Rob learnt sales and marketing the hard way (or the best way he’d say). In the mid 90s he was out walking the streets selling OptusVision cable TV to Australians. I remember thinking that was a horrible job at the time but Rob reckons it gave him the best possible sales education. Maybe I missed out!?

The best sales and marketing tools Annex use are Facebook Ads, Email lists – “the best customers are return customers” – and AdRoll, a “retargeting” platform. Retargeting works by keeping track of people who visit your site and displaying your retargeting ads to them as they visit other sites online. That’s important because many people don’t buy the first time they visit your site. They just need a little reminding!

Some of the other key systems/platforms they use are:

Crowdsourcing:

Kickstarter: He had to perform some magic in setting up a prerequisite US Bank account to get started, but this step got the ball rolling and “proved” there was a market for their product. (The US bank account issue does not exist anymore, at least for Australians.)

eCommerce customer interface:

Shopify is the businesses storefront. Rob mentioned how easy it was to set-up and use – “Why would you build your own?”. They use Canadian developers to tailor the site (Responsive design etc.). Why Canada? Because Canada has great Liquid developers. (Liquid is a templating language for Shopify). Previously they’d sold Opena cases on a “cheaper solution” (not Shopify) and then one day Ashton Kutcher tweeted about them and knocked their system over. The ecommerce platform provider at the time gave them as much infrastructure grunt as he could and they still fell over. Shopify has never had this problem.

Payments:

Paypal and Stripe (which only just kicked off in Australia making it easier to use accept payments from anywhere in the world).

Fulfilment:

Shipwire: You previously needed a US account to get this started just like Kickstarter. It’s easier now. Shipwire integrates with Shopify, and a heap of other commerce systems. They store your products in their warehouses, provide shipping rates and inventory back to your storefront, arrange delivery etc. These guys are crucial if your business ships a physical product.

Customer Support:

Zendesk: Keeps track of customer issues and details. As the Annex business hit scale, there was no other way to keep track of this stuff.

CRM:

Capsule CRM: Annex primarily use this to manage relationships with their B2B customers.

Accounting software:

Xero: Accounting SaaS provider. Cool… but it’s still accounting.

List Management:

Mailchimp: Manage your email lists.

All of these platforms are software-as-a-service. The ecosystem they play in has forced the major players to integrate well with each other. This truly is a business without on-premise IT (apart from their iMacs).

Rob takes the approach of “do and change” with his business so he’s not too concerned about change. If a SaaS provider they use started to alienate their base or went out of business I imagine he’d take it in his stride and move to someone else. Possibly a few late nights and stressful moments, but Annex would get through it.

One thing he kept iterating was how easy it was to set up these businesses.

So check them out. It’s a great example of a contemporary global niche business, where the barriers to entry get lower and lower.

Start your own business. Looks easy enough!

How to fix your private cloud – Part 4

We’ve covered legacy IT, use-case and business case issues. Today we’re talking about the immaturity of private clouds themselves.

There are 4 areas where private cloud deployments haven’t matured yet that you must contemplate:

  • Software licensing – When migrating legacy software to private clouds it gets very difficult to track software licensing. Where previously you had a pretty static license pool, in a private cloud your usage may expand and shrink. How do you manage that? For example, how do you deploy Oracle RDBMS in a private cloud if you don’t have an Enterprise agreement? A nightmare!
  • Lack of standardsThere are many cloud platforms, some proprietary, some open-source. All these are different to their public cloud companions. It’d be good if a public service provider would let you install your own cloud platform on their tin. It’d make hybrid cloud a lot easier. One day I suppose. Until then you have to manage your public and private APIs differently.
  • Compliance leakage – Your private cloud is a single environment. Anything that has regulatory or compliance requirements (like PCI-DSS) can’t go on there without bringing the whole cloud into scope because of…..
  • The immaturity of cloud networks – I know SDN will save the world but for now the underlying networking concepts of different clouds are of a differing standard and sophistication. Many enterprises therefore deploy cloud networks in a basic, pre-provisioned fashion. (Read about the 6 challenges of private cloud networks in this F5 document.)
11144223_ad706710a5_b

Mike DiStaula, little boy (Mike Burns via Flickr)

I suspect one day cloud platforms, standards, licenses etc. will converge enough so that you are running the same technology in private and public cloud stacks. Possibly AWS will provide an on-premise cloud stack, or a provider will start letting you install your own cloud platform as already mentioned. At least with this last one, the enterprise is finally free of the need to actually deal with hardware. What will we call infrastructure specialists then!?

The default answer is that IT’s vision is to provide hybrid or “multi-cloud” environments but not many people can actually articulate what that means, how it can be achieved, and why business users should care.

In the last post in this series we’ll look at the ways forward.

How to fix your private cloud – Part 3

In the past two blogs we’ve looked at the inertia of Enterprise IT and the issues with use-case development for private cloud. Today it’s the business case.

Business cases are typically written for, and approved by, senior management who don’t fully understand technology – its possibilities and limitations. They use IT services more than most demographics and always want the latest tech – for themselves at least!

So what is the business case for private cloud?

Is it to increase revenue? Possibly, in some indirect not-so-obvious way.

Is it to decrease costs? Not at all, unless you were really inefficient to begin with. It does reduce the transaction cost of establishing a new platform but that is but one smallish component of a projects cost. Building a private cloud requires a big upfront investment with no immediate return, a real “field of dreams” situation. Cloud is about speed, automation, self-service and a little experimentation.

http://johnhoran1917.files.wordpress.com/2012/07/552976_154631554667905_372989070_n-copy.jpg

A business case must be able to measure and demonstrate success. You need a metric and it’s difficult to measure cost reduction or revenue improvements with a private cloud. You could use project delivery and time-to-market metrics. You could measure how many applications are running on your private cloud. You could measure developer satisfaction and/or usage. None of these metrics are easy to measure or necessarily translate to a successful outcome though. If project delivery times go down is it related to cloud or other improvements? If you measure how many applications are running on the cloud is it just shuffling your existing portfolio around?

The truth as I see it is this. IT has to transform to meet modern requirements and Cloud computing is one necessary component. Disruptions like big data, mobility, wearables, gamification, social networking, high speed networking, Internet of things, global logistics & resourcing can’t be delivered effective using traditional IT.  Practices like Agile and DevOps – and other things – complement cloud computing for these same ends. IT now plays in a border-less environment with abundant resources, nimble competitors and changing technology. The game has changed.

So cloud is one piece of an IT transformation. But why a private cloud? It’s hard for business users and developers to get excited about internally provided services they can get from Amazon, Rackspace, Google or Microsoft already. Enterprise IT wants to demonstrate robustness, stability and change control but users really only care about usability and provisioning times.

To demonstrate the value of a private cloud you need to demonstrate success in the realm of all this disruption and it has to be something that is difficult to do in the public cloud for security, legal, integration or performance reasons. Choose a significant project/platform in this realm, and bolt it to your private cloud project. A champion project for your cloud.

Your business case then includes a complete end-to-end platform and the success of the private cloud is tied to success of the champion platform, by how well the platform is “harnessing change for competitive advantage”. For example, how do the release cycles compare to your existing platforms? What are the scale limitations? How easy is it to add features and fix bugs compared to your legacy platforms? How well does it perform in the digital world? Do developers use the private cloud? Can users get at the data anywhere and any time? What is the next project that could benefit from this approach?

The business case for a private cloud stacks up only if you have a significant partner at the beginning, or at least very early on. This could be a significant project, application or business area. Sure, run some proof of concepts to familiarise yourself with cloud technology but then get this key user who can provide feedback on the platform, someone who can do regular releases on the platform, someone who depends on your cloud to run their business. This partnership could then be the seed for a new digital enterprise.

In the next post we’ll look at all those thing’s private clouds can’t do!

How to fix your private cloud – Part 2

My last post about how to fix your private cloud focused on IT’s organisational flaws, ill-directed focus and lack of customer-responsiveness. If I’m going to fling excrement at my industry peers, I’d at least better have a crack at identifying some good use-cases for the private cloud myself, and highlight where the focus could/should have been.

"Wait here until you are useful",  Matt Brown (via Flickr)

“Wait here until you are useful”, Matt Brown (via Flickr)

So this post is primarily a bullet point list! Here we go… Private clouds can enable:

  • Single OS instances for sand-pitting applications. If a developer needs a server environment, they spin one up in the private cloud, rather than hack their desktop to pieces. The benefit over using public cloud here is that the sandpit will have access to the internal systems a developer needs.
  • PaaS-like environments, and by this I mean pre-configured development environments with all the preferred tools and integration technologies already installed. This is a natural extension on the last point. This could also include database-as-a-service (DBaaS).
  • Internet-facing applications that need to be spun up, and then down, quickly. The classic example is a marketing campaign. These types of loads may have been handled by a marketing agency in the past. This could be done in public or private cloud, integration depending.
  • Internet-facing apps where you want to preserve an architecture that scales when needed (for example a political parties web site which gets hammered once every 3-4 years, or a betting site that gets smashed once a year). Of course some of these would do well in the public cloud but for regulatory, latency, specialty-hardware or integration issues.
  • Web portals and e-commerce systems that necessarily combine many internal and external system components. Imagine an e-commerce system that integrates social-login and internal product information systems.
  • Web services where utilisation is unpredictable and the service consumer is as likely to be external as internal. Web services typically need access to a company’s data so will likely be “close” to internal data sources making private, rather than public, cloud more likely, especially for large or sensitive data sets.
  • Virtual desktop infrastructure (VDI) because workloads are inherently highly variable, which is a good reason for implementing on the cloud. User access to VDI will be from anywhere on any device at any time, which suits private cloud environments. Typically VDI is built on specific hardware, but increasingly integration opportunities between VDI and Cloud vendors are occurring.
  • Disaster Recovery/Business Continuity. The public cloud is promoted for this purpose of course, but moving the function in-house could be cost effective for a very large enterprise.
  • Platforms that are developed using Agile, Continuous Deployment and DevOps practices. In these instances your infrastructure is part of your deployment process and fully orchestrated. There is typically no “operations handover” in this environment and it evolves over time.
  • Systems where you are occasionally grunting through a very large amount of data. For example, 3d rendering, unstructured or big data analysis, and business modelling.

These some use-cases I researched and have observed myself. If you can think of any more, add them in the comments.

One of the interesting things to consider is what is not on the list: legacy systems, Exchange servers, storage systems, Intranet portals… You could put these on your private cloud, but there’s no great benefit. When you factor in the orchestration effort it can actually take longer to get these working on the cloud. They probably don’t need autoscale and other cloud features. So run them on your ol’ VM farm!

IT would have done better to work through the likely use-cases for the cloud and focus on these rather than looking at the private cloud as the latest platform for…. everything. Even better it could have done this before beginning, which leads me to the topic of the next blog in the series: The business case.

How to fix your private cloud – Part 1

Private clouds are difficult to build. In this blog series I’ve surveyed all the common flaws in private cloud design and implementation so you don’t have to chase them yourself. Hopefully you can relate to some of the issues and contribute your thoughts in the comments. In the final blog in the series I’m going to attempt point a direction forward, to fix the private cloud, and share my reading list.

Today’s blog is about the organisational flaws exposed by the private cloud trend.

*********

IT built the private cloud IT wanted to build and not the cloud anyone wanted to use.

Private clouds were commonly seen as an extension of virtualisation. This encouraged IT to have an inside-out cloud mindset. Now virtualisation and cloud typically go hand-in-hand, but they are not the same thing. Even though the IT infrastructure deployed in both instances is usually quite similar, from a user perspective they are completely different. Clouds are quick and self-serviced whereas virtualisation by itself is not. The truth is you can have a cloud without virtualisation. For example, if you build self-service etc. on top of an Oracle RAC Cluster you could have DBaaS. (Be careful to not get screwed too much on the licensing costs.)

IT built the cloud it wanted to build

The virtualisation trend also exposed some organisational issues, which may or may not have been dealt with. It’s part of the phenomenon of Software eating Infrastructure. Virtualisation allowed cloud engineers to make network changes to “soft” switches and firewalls. It allowed them to deploy storage. Storage I/O problems occurred because of poor workload balancing and live migrations. The opportunity to improve IT efficiency by delegating storage, compute and network activities to a semi-orchestrated cloud team existed. In some organisations this change worked, in others it was resisted.

The arrival of private cloud progressed these organisational issues further with many organisations merging specialists into a cloud team and hoping they would abandon their specialist mindset.

I’ve drawn up a very generic cloud stack below:

Private Cloud effort

You should have put most resources into the top block but these skill-sets (establishing services, APIs and managing a relationship directly with cloud users) are not something specialist IT staff are traditionally good at, or have ever had to do. IT shops started reinventing themselves to make this shift.

The bottom two blocks play to IT’s traditional strengths. Depending on how (in)efficient you were you may have spent most of your time and energy stuck in the bottom block, building networks, hypervisors and customised operating systems. If you were still heavily silo-ed there was no way you could match someone like Amazon’s scale and efficiency. Even if you were uber-efficient you probably can’t match AWS. The thing is, if you’ve spent most of your energies in the bottom blocks, and not in the top block, you probably don’t have many users. You spent a lot of time building the “undifferentiated heavy lifting”, as Adrian Cockcroft said back in the day, because it’s what IT knew how to do.

In the next blog post I’ll discuss the business case for private cloud and some use-cases.

MBAs kill IT with efficiency pr0n

If you feel like a good read pick up a copy of Antifragile by Nassim Nicholas Taleb. Specifically read Chapter 3 temptingly titled “The Cat and The Washing Machine”.

A summary of the book in one line is: Antifragile things get better under stress. This is distinct from fragile things that break under stress, and robust things that persist.

Some antifragile examples used are:

  • Human bodies that improve under certain levels of stress (eg. strength training) and;
  • The airline system, which gets better with each single accident. Each accident improves the system (MH370 may prove to be an exception).

Chapter 3 argues that antifragile things tend to be organisms like “The Cat” whereas fragile things tend to be like the “The Washing Machine”.

What does this have to do with IT Infrastructure? Historically we’ve aimed to build robust infrastructure. We’ve built environments with dual power supplies, backup data centres and RAID disk arrays. We build environments to be robust under stress. They don’t improve.

When IT hardware was expensive and scarce it may not have been justified to buy back-up hardware. You may have bought a single mainframe for one site, leaving your business exposed to a potential extended outage. That is, fragile.

Now in the days of IT abundance, IT infrastructure is vast and geographically dispersed. If one server dies in the cloud does anyone notice? Shadow IT, iPads, BYOD and opportunistic vendors make IT growth much more organic that it once was.

It isn’t urgent if a power supply or HDD dies anymore. What is tricky is understanding the complexity of key business functions and how they map to IT. Also, software is eating infrastructure. Physical assets can be robust, but never antifragile. Software is much more malleable and can improve.

As an aside I chatted to a lady at a cafe the other day. She was a nurse about to study LEAN. I was horrified. LEAN is all about minimising waste and maximising value, or in my mind, managerial efficiency pr0n. I imagine the LEAN consultants received less-than-lean money from the public health system. LEAN works well for manufacturing, but applying a model born out of Toyota to hospitals is MBA madness.

I have nothing against efficiency. I just don’t think LEAN works outside of manufacturing. In manufacturing you have slow-changing product life cycles, mass production and well understood customer needs.

Applying LEAN thinking to IT assumes IT is like “The Machine” where in fact it is becoming more like “The Cat”. In IT we don’t fully understand customer needs so we have tight iterations and close proximity to the end-user (ie. Agile). Product life cycles can be incredibly short. Look at mobile apps. Digital software products are not mass-produced. A single version is produced that copied/distributed one-by-one as needed. A large portion of IT work is not documented. It is done by skilled artisans who don’t see the point of writing down stuff for efficiency experts.

In the naughties IT was consolidated to achieve scale. It was then optimised using methodologies like LEAN and outsourcing to manage cost, but IT never simplified. Complexity is always, at least, preserved it seems.

LEAN, consolidation, outsourcing. We ended up with many gutted-out, off-shore script shops. A disaster waiting when something undocumented or unexpected occurs. Previously salaried employees returned as contractors. IT in some ways became more fragile.

In fact, Taleb argues, and I agree, excessive size, efficiency/optimisation and complexity generally makes things more fragile. Efficiency leads you to put all you eggs in one basket. To lean on single vendors (pun intended) and have big hidden risks. Times have changed. Efficiency is becoming dangerous.

That’s not to say we gold-plate IT. I like Agile. Even though it not always implemented well, Agile recognizes IT as “The Cat” it is. It works with small teams, learns and improves (fails fast) quickly.

I suspect a good number of IT professionals will continue to balance efficiency/fragility with robustness when in fact the we should start looking at anti-fragility. We should look at more ways for IT to improve itself under stress.

We want failure to make IT better and stronger. Isn’t this the big takeaway from ITIL problem management? Isn’t this what Chaos Monkey does for Netflix? A non-functional process destroying things at random to improve the Netflix ecosystem.

What other examples can you think of where IT improves itself under stress? And do MBAs with the latest efficiency fad represent a risk to IT systems?

Is the cloud just… web services?

My work colleague turned around to me and said, “Web Services aren’t APIs”. That didn’t sound right so I started investigating. What is the difference and why is it important?

Applications have been built and constructed from re-usable and shared components since the bloody epoch. It’s why software is eating everything. Once a standard interface – and usually a corresponding library – is agreed upon there’s little reason to go back to first principles again. It’s division of labour, driven by pure need, evolving organically.

Then along came ubiquitous, always-available connectivity and expanding bandwidth. Why bother compiling and distributing an API/Library when the same API call could be made to a shared network service? A web service.

So a web service is a type of API. Not all APIs are web services though. APIs are the public interface for a piece of code – it is what you can call from within your code. It may be a web service, but it could also be a Java library or similar.

Wikipedia has a web services as “… a software function provided at a network address over the web”. That’s a pretty good definition. It must also be loosely coupled, which means that both the service caller and owner agree on the interface but know little about each other. The back end class can be substituted as needed.

Companies are themselves creating their own web service APIs. Here’s an API for business listings at Australia’s Yellow Pages and here’s one I’m looking at now to do some useful work on my expanding Evernote database. Both of these are web services with some extra API management capabilities. Grab yourself key and start developing!

Amazon was miles ahead of the curve on this. This famous post by Steve Yegge describes the famous Jeff Bezos mandate (in 2002!) that all teams at Amazon must:

  1. Expose their data and functionality through data services,
  2. Teams must communicate only through these interfaces (no direct database links etc.),
  3. All interfaces must be designed to be accessed externally

and a few other things. Talk about ahead of the curve.

It’s the future mesh of interconnectivity. One big “programmatical” mash-up.

There are the web services you own and the ones you don’t. With regards to the ones you do own, you’ll have to think about how you maintain some control of the integration. Two possible models are shown below. Do you have an integration bus/relay/proxy in each cloud so as to minimise network traversals, or do you have a few centralised integration points to make control and standards (and non-functional requirements like logging, access control, templates etc.) easier.

Web service cloud options

For the web services you don’t own but use, how much do you rely on single vendors, how do you manage keys and how do you manage different standards/skill sets etc.

I’ve always thought of “The Cloud” as a technology theme that is behind many new implementations, but I’m starting to think “the Cloud” is just a biblical plague of web services. It’s even hidden the in term “as-a-service”! All SaaS, PaaS and IaaS providers have public web service APIs built in from day one.

Load more
%d bloggers like this: