Hi all,
I thought I might share some thoughts about the financial aspect of the new wave of IT.
IT has always been a cost. It doesn't generate revenue, it's expensive and it's sort of invisible to the end users in the same way people on a train don't care about the rail lines.
It's taken a long time for IT to get accepted by bean counters as having a real function with definate cost benefit and now we are here we need to give them some exciting news.
We're not going to be a CAPEX for very long!
Yeah!
Why would any business who could outsource their hardware to the cloud not do so?
There could be a problem here though. When we rock up to finance and say that we need £1.2m for some tin, at least they can understand that something has been bought. It depreciates, it can be sold and it has value. The the issue now is that with the evolution of cloud offerings the only thing we could end up buying is TIME.
Time does not depreciate. Time is gone the moment it turns up. You can't (easily) sell on your time. Time has no value once its used. The day is not too far away when for some places IT will no longer be a CAPEX but a pure OPEX action.
This could mean our poor finance teams needs a heads up that IT are about to hugely shake up how things are done and may need to adjust their figures accordingly.
Food for thought certainly.
Thanks for reading,
Friday 30 September 2016
Redefining Software Defined Anything
Hi all,
Last night at the IG16 dinner I did the social thing and asked other people what they thought of the whole SDx thing. Apparently my comment in the Q&A session had hit home with quite a few of the more technical spods and this got us talking about what we would actually describe as "Software Defined".
Fishcake: Quite nice.
First we went over the current definition of what Software Defined is and what we thought was broken with that name. Apparently my opinion was quite well received and we came to a group decision that SDx in it's current framing is actually "Profile Defined". Humans define the Profile. The Profile is pushed to a controller of some kind. The Controller pushes the Profile to the end devices.
Lamb: Really good. Succulent. Great with the ju.
What is an API anyway? Does SDx need to be API driven? We quickly came to the conclusion that the API in all the slides didn't actually have to be an API. It just has to be a method of collecting data or sending new commands. This could be as simple as WMI calls or an SSH session. As long as the controller knows what to do, and it produces an automated response it could even be as simple as dropping a file into a remote directory.
Creme Brulee: Really? Was nice but these things pop up everywhere. This one had fruit.
What should SDx be? We decided that the real innovation in SDx wasn't actually the controllers or the code or the software. The actual innovation here are Vendors providing programmatic ways of configuring devices remotely. The software element in SDx is just replacing the human pressing the buttons. But that's not what SDx should be.
We decided that in order for SDx to be a real thing it needed to do more. It needed to do more than just blindly push human written profiles to devices. It needed to do more than the devices themselves. It needs to become the central hub for the environment. It needs to react to that environment based on how the environment is behaving at the time and it needs to do this automagically. The profiles then are humans telling the controller the acceptable ranges the environment can be in and the controller makes the decisions on how that is achieved. This would be a true Software Defined environment.
Cheese: Cheese.
So what next? Well as our new definition of SDx is more automated and less human controlled it brought into the discussion of other technologies. If SDx could re-route network traffic or turn off switches to save power, for example, would we need Cisco's very clever routing protocol to find "cheaper" routes? Would we need VMWares Storage virtualisation or DRS? Were all of these things work arounds in preparation for SDx and if SDx is better, how do we wind down these technologies?
Thanks for reading,
Last night at the IG16 dinner I did the social thing and asked other people what they thought of the whole SDx thing. Apparently my comment in the Q&A session had hit home with quite a few of the more technical spods and this got us talking about what we would actually describe as "Software Defined".
Fishcake: Quite nice.
First we went over the current definition of what Software Defined is and what we thought was broken with that name. Apparently my opinion was quite well received and we came to a group decision that SDx in it's current framing is actually "Profile Defined". Humans define the Profile. The Profile is pushed to a controller of some kind. The Controller pushes the Profile to the end devices.
Lamb: Really good. Succulent. Great with the ju.
What is an API anyway? Does SDx need to be API driven? We quickly came to the conclusion that the API in all the slides didn't actually have to be an API. It just has to be a method of collecting data or sending new commands. This could be as simple as WMI calls or an SSH session. As long as the controller knows what to do, and it produces an automated response it could even be as simple as dropping a file into a remote directory.
Creme Brulee: Really? Was nice but these things pop up everywhere. This one had fruit.
What should SDx be? We decided that the real innovation in SDx wasn't actually the controllers or the code or the software. The actual innovation here are Vendors providing programmatic ways of configuring devices remotely. The software element in SDx is just replacing the human pressing the buttons. But that's not what SDx should be.
We decided that in order for SDx to be a real thing it needed to do more. It needed to do more than just blindly push human written profiles to devices. It needed to do more than the devices themselves. It needs to become the central hub for the environment. It needs to react to that environment based on how the environment is behaving at the time and it needs to do this automagically. The profiles then are humans telling the controller the acceptable ranges the environment can be in and the controller makes the decisions on how that is achieved. This would be a true Software Defined environment.
Cheese: Cheese.
So what next? Well as our new definition of SDx is more automated and less human controlled it brought into the discussion of other technologies. If SDx could re-route network traffic or turn off switches to save power, for example, would we need Cisco's very clever routing protocol to find "cheaper" routes? Would we need VMWares Storage virtualisation or DRS? Were all of these things work arounds in preparation for SDx and if SDx is better, how do we wind down these technologies?
Thanks for reading,
Thursday 29 September 2016
Software Defined...anything?
Hi all,
I'm currently at the IG16 conference in Leeds, the title of which is "Software Defined...So what?". So what indeed?
A small part of the time in the talks today has been to define "Software Defined". Reading between the lines, it has almost nothing to do with "Software" defining anything and everything to do with automation and API's.
Let me go back a bit and I'll try to explain why you don't have to worry about "Software Defined...something" and why you have actually been doing this stuff for years.
SDx, the TLA being bandied around here with great abandon, is the act of abstracting the user from the API of a given vendor or set of vendors and giving them a core API that translates ubiquitous commands into Vendor specific commands.
Wow. What a sentence.
Ok. You are a Sys Admin. You have some Dell storage units and some Netapp storage units. You also have access to the API's and some skill in scripting. Now, some monster has asked you to create the same LUNs and configs on both units. So you write a script that will do that by speaking to the 2 companies API's that talks to their kit. Congratulations, you are now doing SDS.
Happy enough so far? Well it gets more interesting.
Lets say you don't actually care about storage configuration automation. You very rarely set up a new LUN, disk array, whatever. However, you've only got block storage (fibre/iscsi) and you want to automate the process of end users getting SMB or NFS shares. What you do is put a server inbetween, write some scripts that create windows/nfs shares on demand through a webpage or whatever and boom. Software Defined Storage at this layer too.
It's exactly the same deal with networking. If you write a script that interacts with some Cisco switches and/or some other kit, that is Software Defined Networking.
I raised a point in the Q&A session that this description is wrong. It isn't "Software Defined X". It's "Profile Defined X". Let's take Storage. What the SDS (Software Defined Storage) layer is actually doing is being your swiss army storage dude. It knows how to speak to all storage API's. You give the SDS a profile for it to follow, a device to poke the profile into and it'll do it configuration for you.
None of this is new. People have been writing scripts to do this for years. The only difference is now companies are getting into it and selling purpose built devices with a profile manager and a Perl script (or similar) to run against the Vendors API's.
The bonus is that because BIG IT are coming round to the idea they can monetise it. As they are trying harder to monetise it we are about to see some API standards being brought in. This means, ironically, it'll be easier for you to write code for the Vendors API's and not need their devices in the first place.
Software Defined X, again, isn't new. However the market is driving a new appproach to it. We need to be receptive to it, and actively encourage it so we can move onto more cool things. But don't forget, as it's as simple as all this, all you need is a computer and an API and you can do Software Defined anything you like.
I'm off to write a Software Defined Coffee API. Makes about as much sense as everything else.
thanks for reading,
I'm currently at the IG16 conference in Leeds, the title of which is "Software Defined...So what?". So what indeed?
A small part of the time in the talks today has been to define "Software Defined". Reading between the lines, it has almost nothing to do with "Software" defining anything and everything to do with automation and API's.
Let me go back a bit and I'll try to explain why you don't have to worry about "Software Defined...something" and why you have actually been doing this stuff for years.
SDx, the TLA being bandied around here with great abandon, is the act of abstracting the user from the API of a given vendor or set of vendors and giving them a core API that translates ubiquitous commands into Vendor specific commands.
Wow. What a sentence.
Ok. You are a Sys Admin. You have some Dell storage units and some Netapp storage units. You also have access to the API's and some skill in scripting. Now, some monster has asked you to create the same LUNs and configs on both units. So you write a script that will do that by speaking to the 2 companies API's that talks to their kit. Congratulations, you are now doing SDS.
Happy enough so far? Well it gets more interesting.
Lets say you don't actually care about storage configuration automation. You very rarely set up a new LUN, disk array, whatever. However, you've only got block storage (fibre/iscsi) and you want to automate the process of end users getting SMB or NFS shares. What you do is put a server inbetween, write some scripts that create windows/nfs shares on demand through a webpage or whatever and boom. Software Defined Storage at this layer too.
It's exactly the same deal with networking. If you write a script that interacts with some Cisco switches and/or some other kit, that is Software Defined Networking.
I raised a point in the Q&A session that this description is wrong. It isn't "Software Defined X". It's "Profile Defined X". Let's take Storage. What the SDS (Software Defined Storage) layer is actually doing is being your swiss army storage dude. It knows how to speak to all storage API's. You give the SDS a profile for it to follow, a device to poke the profile into and it'll do it configuration for you.
None of this is new. People have been writing scripts to do this for years. The only difference is now companies are getting into it and selling purpose built devices with a profile manager and a Perl script (or similar) to run against the Vendors API's.
The bonus is that because BIG IT are coming round to the idea they can monetise it. As they are trying harder to monetise it we are about to see some API standards being brought in. This means, ironically, it'll be easier for you to write code for the Vendors API's and not need their devices in the first place.
Software Defined X, again, isn't new. However the market is driving a new appproach to it. We need to be receptive to it, and actively encourage it so we can move onto more cool things. But don't forget, as it's as simple as all this, all you need is a computer and an API and you can do Software Defined anything you like.
I'm off to write a Software Defined Coffee API. Makes about as much sense as everything else.
thanks for reading,
Subscribe to:
Posts (Atom)