First, map your environment. Remember that the rate of innovation of novel and new components (i.e. higher order systems) is exponentially related to the level of industrialisation of the underlying components (an effect known as componentisation).
With this in mind, then ...
Figure 1 - using a public cloud.
Figure 2 - building a public cloud service.
Figure 3 - How to build? Micro services or not?
First, I'd like to note that every node in your map is a component and ideally would be built as a 'small' and relevant component (see USAF FIST) for the activity that the component represents. Hence, for the activity of computing infrastructure then in the past we used product components such as servers though today we tend to use utility service components such Amazon EC2. Not breaking things down can cause all sorts of issues - see ASPIRE.
From the above example, it should be clear that how a component is delivered depends upon how evolved the activity is. In some cases the component can be provided as a product, in other cases (when the act is less evolved) you have to custom build it whilst in others (when the act is highly industrialised) you can use utility services or commodity components. The type of component you use to deliver an activity will also change over time (as the act becomes more evolved).
HENCE don't rush to build a public service for a novel act because it will rapidly change (evolve) in both code base and interfaces. Let me emphasise, the interfaces are anything but stable. Hence an 'experimental' code base with objects in a code repository is more than enough at this stage. Don't enforce its rapidly iterating schedule and changing interfaces on other consumers in your organisation. Let them choose the version they wish to use.
However - word of warning - ask yourself is this really a novel act? Just because it's the first time you're doing something doesn't make the act novel. For example, user object, security permissions, financial transactions are anything but Novel. So, check with the market and find out how evolved (i.e. ubiquitous and well defined / understood) something is.
Assuming the act is novel then as it evolves and the interfaces start to become more stable then by all means start to consider providing it as a common library and then as a micro-service to others. Yes, everyone using other versions will have to refactor a bit for use of the new micro-service.
For the more industrialised components, if you're not using utility services or your own micro services (in an ideal world the service would be both) then please ask yourself 'why?'
The above was brought to you with experience of building large and complex environments for millions of users with micro and some not so micro services between 2003-2006.
Snippet - Fotango Board Pack, 2007.
Yes, we had a mass of component services throughout the organisation from storage to server provision to utility billing to fulfilment to printing with configuration management, auto deployment and near continuous deployment of code.
However, maps and these techniques are simply a rough guide and not a substitute for thought.
--- 16th May 2015
If you want to learn more about this, you can always find members of the old Fotango crew speaking at various conferences. Always try and grab a few minutes with Artur Bergman (now, CEO of Fastly) and James Duncan (now, a CTO within UK Government).
Snippet - Fotango Board Pack, 2007.
Yes, we had a mass of component services throughout the organisation from storage to server provision to utility billing to fulfilment to printing with configuration management, auto deployment and near continuous deployment of code.
However, maps and these techniques are simply a rough guide and not a substitute for thought.
--- 16th May 2015
If you want to learn more about this, you can always find members of the old Fotango crew speaking at various conferences. Always try and grab a few minutes with Artur Bergman (now, CEO of Fastly) and James Duncan (now, a CTO within UK Government).
