Clive Longbottom - Analyze This!

Andre Pino: In today's episode, I'm joined by Clive Longbottom, cofounder and the service director of Quocirca, an analyst firm based in the United Kingdom. Welcome, Clive.

Clive Longbottom: Hello, there.

Andre: Clive, I just realized that we have something a bit in common. I have a chemistry degree and you have a chemical engineering degree. Just curious how you got onto IT from your chemical engineering degree?

Clive: Yeah, it's a very long and convoluted story so I'll have to cut it as short as I possibly can. I went into engineering because I wanted to work on the oilrigs in the North Sea. Unfortunately, while I was at university I found out I had got epilepsy and they're not too keen on people throwing themselves overboard every now and again by throwing fits. So I had to find a different job to do and went into engineering research, working with a company called Johnson Matthey and I worked on various different projects like anti-cancer drugs, car catalysts and the thing which was the love of my life which was fuel cells for many different areas. However, that then – they wanted me to move from doing the research into development and then into production and I got myself all set up in Cambridge in the UK to head up that group and was then told that they were going to move it over to Pennsylvania in the States, and unfortunately, I was in no position where I could follow that. I went back to the job that I'd had previously within the company and they moved me out of doing research and into being an engineer, which to them was going around putting plug sockets into offices which was not quite what I wanted to do. So I found myself being dragged kicking and screaming away from what I saw as being a project – sorry, being a hobby in IT – to actually doing it as a job, and then when my boss got headhunted by one of the electricity generating companies in the UK, I followed him and headed up putting in place office automation across 17,500 people. I then one day had a phone call from a company I'd never heard of asking me whether I was interested in doing a job that I'd never heard of, and that was a company called Meta Group who are now part of Gartner, asking me whether I wanted to be an industry analyst. So after they explained to me what an industry analyst was and after I'd gone, "I don't think I'm the right person,” when they tried to persuade me otherwise, three months later I found myself standing onstage in Haifa, in Israel, next to Dale Kutnick, the founder of the company, presenting to 350 people and thinking, what am I doing here? And the rest is history, really; four years with Meta Group, a couple years out for various reasons and then set up Quocirca 17 years ago.

Andre: Very nice. It's amazing how careers – the path careers take sometimes, isn't it?

Clive: It is, yes.

Andre: So at the Quocirca, what's – what are your areas of coverage?

Clive: Well, I'm sort of the universal catch-all. I'm the biggest generalist. I take any areas that nobody else wants to take, plus being the founder I also take some of the ones which I really do want. Being an engineer, everything to me is a process and if you go into an organization and talk to them about what is keeping them awake at night, it's unlikely that they will say, "Oh, it's whether we should use AMD or Intel chips or, you know, whether we use proper HP toner cartridges or third party ones." You know, they'll say it's how do we gain more customers, how do we get the customers to spend more with us, how do we reconcile payments against the bank statements, and so on and so forth. So, yeah, I feel that any analyst that wants to talk to end users on a sensible basis needs to cover a whole range of subjects. You can't really specialize in one and then go in and talk at the C-level in an organization and try and help them.

Andre: Right. So, you know, here in the States the DevOps transformation is – I would characterize it as being in full swing. It's a pretty hot topic here. You know, what is your perspective on DevOps in Europe and perhaps more specifically in the UK and what kind of role is it playing in transforming the software development process?

Clive: It's growing very rapidly. You know, Europe is not quite the same federated states as the US is so, you know, you can take a very broad brush approach of which there will always be countless exceptions to it, but North Europe, when you look at the Nordics, the Scandinavia plus Finland, they tend to be far more advanced than the rest of Europe. IT people understand the business, the business understands IT, and so they can have a really good conversation between each other, and so we're seeing DevOps doing well there. In the UK, it's doing well but there are still a lot of cascade projects going on. France, not so much. Germany, a very engineering approach, so it's very much process driven, but the technologies do tend to have a lot of sway within the organizations and so we are seeing a slightly different form of DevOps in the Germanic countries – Germany, Switzerland and Austria. And then as you move south, I think we start to see a slower movement there. Parts of Italy are moving faster than other parts. Greece, Portugal, Spain tend to be moving quite slowly, for financial reasons, if nothing else.

Andre: And is that typical of the adoption of new technologies and methodologies in IT in Europe?

Clive: On the whole, yes. Yeah, and as I said it's a very broad brush approach. You can't sort of say that is France all the way through, that is Germany all the way through but, you know, if we are okay with a generic outlook on a country and not being too nasty to them then I think that that counts quite well, that the north is – tends to be more IT savvy, tends to move faster than the south which does tend to suffer at the moment, particularly from the financial issues which are holding a lot of projects back.

Andre: Right. So from what you've seen of the DevOps activity across Europe, what are you seeing in the impact its having on IT teams and the way those teams work?

Clive: It's a very broad spectrum. You know, we can take the ones who are understanding it well, are implementing it well, where it's a case of what is DevOps; it is a means of ensuring that the business development, testing and operations work hand-in-glove and make sure that what comes out at the far end is something that supports the business and what it wants to do and add distinct and discreet value. At the other end of the scale, there are those who it's being driven by IT, predominantly by development teams who are then saying, "Great, this gives us the chance to push things out when we think they're ready." Now whether the business wants them or not is another matter, whether the business is ready for them or not is another matter, whether operations are in a position to support them is neither here nor there; we're seeing quite a few too many of those type of approaches where, you know, it really is painful and harmful to the business with the end result.

Andre: Interesting. So what… You know, in your role as an analyst you probably talk to a number of end user organizations. Does anyone stand out in you? Have you been really impressed by what you've seen them doing with respect to DevOps?

Clive: Well, no names, no _____. The end users we talk to generally prefer to keep their names under their hats, but certainly we are seeing ones, some of the larger organizations that are in faster-moving environments. You know, we can say sort of high-tech narrows it down marginally. It doesn't make it that you can actually name anybody but, you know, it is a case there that when you are looking at continuous delivery, continuous integration and continuous improvement as well, those are the things which the business is looking at and saying, "IT, we cannot afford to give you – this is our business problem and then wait 12 or 18 months for you to come up with a solution because then you're solving a problem which is 18 months old and we may not even have that problem any longer, we've now got 18 months worth of other problems in which we wish you'd dealt with." So, you know, those companies we're seeing are – the business is going to IT and saying, "Look, how can we make sure that this works well? How can we make it that when we say we have this problem you go, “Great, here are a few options. This one we can have something out in a few days. It may have some more risk with it. This one we can have out in a week, a couple of weeks. It'll have less risk. Maybe a reasonably high cost to it or this one might take, you know, a month or two months and we can keep the cost low and we can hammer the risk down through the ground as well," and the business can then sort of take it – its risk profile view and say, "Well actually, you know, this problem that we've identified is core, it's major, it's hitting us now so we don't mind taking a bit of risk to get rid of the risk of the problem itself." Other ones they may look at it and go, "Well actually, okay, you know, we've regarded the problem. It's something that we can live with for a short period of time. We would rather make sure that, you know, when you do the cost value balance that we don't mind waiting a month, six weeks, for this; make sure you get it right, make sure that all of the retro testing is still done." You know, this doesn't have to be pushed through from development to operations as quickly as the other stuff, so a lot of prioritizing don't regard DevOps as a, you know, single-sized tool. It's a whole toolbox and it's taking the right tools to deal with the right thing at the time. Not everything is a nail, not everything needs a hammer.

Andre: So do you think the businesses that you talk to that are in some of the traditional industries and markets, do you think they recognize the potential threat that they might see from a new startup company that's coming in with more of a digital approach to the business to disrupt their industry?

Clive: If you'd have asked me a few years ago then it would be a case of no. You know, we've been around for 20, 30, 40 years, we're growing at 5 percent, 10 percent per annum. The barrier to entry is far too high for all of these organizations. Then Amazon happened, the Google happened, then Uber happened, then Airbnb, you know, all of these born-in-the-cloud, brand new companies coming through with a model which the bricks and mortar older style organizations just looked at and went, "How did that happen?" You know, we can't do that, and so they've had to look at how they – and also, the financial crash of 2008 uncovered so many bad processes which were being hidden by good revenues coming in at a reasonable margin. So all of a sudden when you get a lack of revenue coming through and you find that your margins are down at the single percentage points you have to look at the processes that underpin everything. So a lot of these organizations that have been around for a long time start to see themselves having to post losses to the markets, that the shareholders are getting very worried that they're deserting and going to some of these born-in-the-cloud companies, and so I think, you know, what we've seen there is this massive wakeup call to the whole idea of cascade project management shouldn't be being used except for in exceptional circumstances. The big exception to that still seems to be public sector projects.

Andre: And what – why is that? Why do you think public sector is the exception there?

Clive: There's a raft of different reasons one of which is just mindset. Public sector tends not to attract the best project managers who are available in the market. They tend to go to other places which can pay them more. There's also a lot of incumbency. So, you know, for – and take the UK as a prime example. The percentage of IT projects which are being run by the likes of IBM, Capita, Accenture, other incumbent systems integrators who historically have specialized in cascade projects. There's a lot of money in a cascade project in the public sector to a third party. They are quite happy to continue to run cascade projects and DevOps is not something which they want to put their best skills in public sector projects on. They'd rather keep those DevOps skills for the big commercial customers who are demanding those skills.

Andre: Right. So let's switch a little bit and talk about what you're seeing and hearing from your clients in terms of their approach towards a DevOps journey or implementation. So are people approaching it, you know, from a technology standpoint, from a process standpoint, holistic standpoint, and which way do you think is the best way to approach it?

Clive: This isn't like going driving an island where, you know, it's a case of how do I get to this endpoint, and the response comes back, well, if you want to get there I wouldn't start from here. I think the problem is the genie is out of the bottle with DevOps. DevOps is not grown organically. It is not something which has had a good degree of control over it. Development people, were looking at the tools which they were using, the Rationals of this world and so on, and going, this doesn't work for me. I need something different. And they looked around and there was this raft of open source tools which were coming through and tools which allowed them to work as an individual in a much more effective and efficient manner. So they started to take these tools 'cause it was a case of, well, if I'm going to be doing this project then I'll do this project as an individual. Then it was a case of their teamwork, as going, well, thank you very much for giving me that piece of code, but how did you create it? Oh, well I started to do this, I used this tool or that tool. Oh, I'll have a look at that. Hmm, it doesn't quite do what I want. I see there's another option here, so they download that open source tool and use that. So chaos really started to come through, and then when it started to get through to the test environment it was a case of, well, we're seeing problems with the code here. We can't feed back in the same way as we were doing with Rational or other tool because now you're all using your own tools, so we now need something which can start to manage the development and test environment, so we need some form of orchestration tool between there. And then there was the case of right, it's been developed, it's been tested, those two groups are happy with it; now we need to give it to operations and they're looking at it and sort of going, "So what are we meant to do with this?" You know, thank you very much for providing us with an end set of code but we've now gotta provision this out there and we have no idea what is required around this, so they'd go and find another set of open source tools to get it out there in the way that they want. So, you know, that creates a total DevOps chaos and that was the technology-driven approach to it from the individuals who tend to fail to realize that the organization they're working for are the ones who put a roof over their head and leather on their feet, you know, they were looking at what helped them, rather than what helped the organization. So now, you know, what we're seeing is the clever IT department and certainly the savvy organization is now saying, "Okay, we know that you're using those tools. If we come in and say, “Here's something that vendor A, B, C has done which covers all of those bases in their way” you're unlikely to give up your tools of choice and go, “Thank you very much, that's wonderful." But if we can layer something over the top that says, "We don't really mind if you're using Chef, Puppet, Jenkins, Hudson, whatever it might be – you've chosen those tools, we'll have to allow you to do it because we're too late to the party, but we can make sure that all of the workflows, all of the checks and balances are put in place to ensure that the flows are done in the correct manner, the feedback loops are put in place and so on." As long as all of that is in place, then I think that's the best we can hope for in the DevOps world at the moment and I think that's what we're seeing from – those organizations which are winning in the DevOps environment now.

Andre: So you've written recently about configuration management. How do you see that fitting into this landscape?

Clive: The long-term aim is to automate as much as can possibly be done, and as we're moving into a more hybrid cloud environment – we're at the starting point of that – we can read as much in the press as we want that cloud is now mainstream; it's not, but a lot of organizations have done a little bit more than dipped their toe into it – but as we move into a more hybrid cloud environment the needs of an operations person is not going to be sitting at a screen trying to figure out what parameters they should put around some code to make sure it runs well in the operations environment. What is needed is some tool which can sit there and go, okay, how do I make this an idempotent environment? How do I make sure that what I do is – I create a recipe – for want of a better word, it's the wrong one to use because of the way that it's used within certain tools as a specific thing but I can't think of another one at the moment – how can I say this is what has to happen out there and I don't care whether we're going to put it out on AWS, whether we're going to put it out on Azure, whether we're going to put it out on SoftLayer, or whether we're going to put it on our own private cloud running OpenStack. I want to make sure that it runs in the best possible way and that when it needs more resources it can get the right resources at the right time. And that becomes far too complex for human brains to be able to deal with in a predictable manner and so by having orchestration and configuration management tools which understand how to put all of this together to make it, you know, do the Jean-Luc Picard thing of make it so – the idempotent approach. That's where I think, you know, we have to have the tooling in place. It's not quite there yet but there are quite a few vendors out there who are making moves in the right direction.

Andre: Right. So the EU, much like the US government, places certain regulations and controls on various industries and so forth. Are there any EU regulations that folks need to consider in Europe as they think about their DevOps transformation?

Clive: Yeah, and the biggest one is the GDPR, the General Data Protection Regulation, which comes into legal power across 27 nations plus the UK as we are voting ourselves out of the EU, but we'll still have to adopt the GDPR otherwise we can't trade with the rest of the EU – that is around the security and the handling of data, not only within the EU but with any EU company which is dealing with, say, an organization or customers outside of the EU, and likewise, any organization or individual who's dealing with a company within the EU. So a lot of that comes down to where is personally-identifiable information held within an organization. So the DevOps people must be able to understand that they need to provide some form of abstraction of how the data is dealt with compared to how the business logic is dealt with. So, you know, if it's a case of there is certain EU data which needs to be held within Germany or France or wherever it might be, that can be managed by the operations people through being able to do this automated configuration management. If they tie it all together and say now everything has got to be in one major database, whether it be a SQL or NoSQL or a different type of database, then that's going to cause problems 'cause, you know, you stick it on the East Coast of America and all of a sudden State of Delaware comes out with a disclosure warrant and all of that EU information will have to be handed over and that's against the GDPR. It's also against, you know, the Privacy Shield Agreement of what's going to be happening with the GDPR. So, you know, that sovereignty of data is going to be a major issue that the technical people have to really come to terms with and understand what that means to when they're writing code and when they're provisioning it out into the operations environment.

Andre: Right. Does that come into play more at an architectural level or is that also at a process level?

Clive: I think it's both. You know, at a process level, if you're a retail company and you're dealing with a global customer base then, you know, you'll probably be able to partition off certain parts of that data to be held in the different locations that are required. But if you are dealing with a more mixed bag of data, you know, as I say, what you gotta be able to do is to provide a level of abstraction which makes it – the business logic can still find the data no matter where it is, as decisions are made to move it around. Just, you know, a year ago nobody would've thought the UK would be leaving the EU, and so a lot of co-location data centers and cloud data centers were being built in the UK as being an ideal place to hold EU data. Now by 2020 we'll be out of the EU and so you can't hold EU data in the UK unless some special agreement has been put in place. Now, you know, we've got lots of elections going on in the EU over the next two years and a lot of those are standing on anti-EU tickets, so unless the abstraction is put into place enabling the data to be moved around without having to change the business logic, the IT people – development and operations – are opening themselves up to all sorts of problems that the business really won't thank them for.

Andre: Wow, some big challenges ahead, huh?

Clive: Well, that's what politics does for us.

Andre: So one of the other major trends in IT today is the adoption of container technology and it plays a pretty significant role in the discussion around DevOps. What are you seeing across Europe in terms of the adoption of container technology and your thoughts on how it will impact the DevOps adoption?

Clive: Yeah. I mean currently, you know, Docker is by far and away the big player in the container environment. It's good technology. The latest improvements to it have addressed some of the security issues which I found in the previous version were really worrying. If somebody wrote a badly-configured container, if that could be cracked by a black hat they could then go through to the underlying operating system and could impact all containers on that platform. You know, that is slowly being dealt with but, you know, the Linux containers, LXC and what Canonical's done with them with LXD, there's differences there. What CentOS has done with Rocket seems to be grinding to a bit of a halt at the moment but I felt that they were going in a much better direction of essentially compressing what the container had within it. When you look at it, you know, what is a container, it's a much smaller version of a virtual machine. Instead of it being a complete wrapper of absolutely everything, including the operating system, it's saying, "Well, what can we share at a lower level, what is it that has to be abstracted and kept within that wrapper?" Great. How about we start to move towards a metadata model where it's a case of, okay, give me a recipe within the container saying what I need to do is – because this is a process I need to call on this functional microservice which then the data that comes out from that I need to pass on to this functional microservice and the data that comes out from that I need to hand on to there. So, you know, make the container something which is far more of a processed flow, use functions which are already alive, because as time goes on and the commoditization of IT is happening the chances of finding microservices which are already live somewhere – so rather than have them taking up space, taking up more resource within a container itself, identify them, find them, use them, audit the process, audit what's happening with the data seems to be a much better way. But at the moment, you know, our advice to any end user is, yes, look at the use of containers, be aware of what some of the shortcomings are, be aware that we are still on generation two at best, generation one-and-a-half possibly, of container technology, and so don't tie yourself in a manner which means that in a year, 18 months time you don't have to reverse out of that dead-end and start all over again.

Andre: Yeah. That's very true. And so, you know, are your clients talking about the use of container technology in their development area, in their production area? I'm just curious where it's getting its start.

Clive: At the moment the majority are still using VMs in their operations environment. Development of finding containers, great; they're easy to set up, they're easy to provision within the development and test environments, they're easy to strip back down again. You know, you're not dealing with as many licensing issues because it's a shared operating system. The operating system is essentially already licensed. So, you know, there's less chance of coming under a license review and finding that you've got 2,000 VMs lying around all of which should've been licensed but aren't properly and so big fines coming through. So we're seeing the developments in test environment using them a lot. That begins to trickle through into operations where it's a case of, well, you know, do we really need to repackage this as a VM because that's the way you prefer things at the moment? Don't you believe that actually having this shared something environment means that the management of a container environment could be easier than the management of a multi-VM environment? Again, all sorts of issues around that. If you take a Docker-type environment and you update the underlying operating system and a few of your containers are actually dependent on a certain patch or upgrade level of that Linux environment then those containers will fail. For that you may need to look for systems containerization like Virtuoso does where it's a case of, no, we can have a name space in there which can capture any of those calls which are version-specific.

Andre: Right.

Clive: We can send those to a little stub which is held within the container at the moment. So, you know, as I say, this is – it's a sign of a young, immature, dynamic technical environment. We do believe that containers have a lot to offer at the moment, well worth using them, but do it with your eyes open.

Andre: Right, right. What are some of the other hot topics you're hearing from your clients about?

Clive: Well, obviously, the IoT is beginning to come through, although we've just done a big piece of research for Rentokil Initial looking at the use of IoT in the farm-to-fork food chain, and that's been very interesting because there we weren't talking to technology people, we were talking to people who have responsibilities for pest and hygiene control for farms and logistics, food processing and retail. And it was a very strong finding that the understanding of IoT is minimal in the business levels. It may be very strong in the technical levels but when it comes to the line of business, no, they don't know what's going on. So, you know, although the techies are banging the drum, saying the IoT is already happening, it may well be, but a lot of these people don't see it as being IoT. All of these chilled lorries that are going around with all of the different devices in there, monitoring the temperature, monitoring G forces and everything, they just see those as being logistics tools. They don't see them as being IoT.

Andre: Right.

Clive: The GPS and travel control systems in the cab of the lorries, they don't see those as IoT. Again, it's just part and parcel of what's going on; process line, automation tools, monitoring tools, they see them – maybe call them Scarta because that's what their engineers call them, but they don't see them as IoT. So, you know, in each case – we have to get a commonality of communication amongst people to get IoT to be a coherent message and then see what the impact is on what's happening. We're still seeing a lot around big data. Again, a lot of people in IT see that as being so last year. For a lot of organizations it's only just beginning to bite them. Globalization and regionalization seem to be big problems both at the business and IT level and how they deal with that availability. As we all saw recently, the downtime from AWS which hit various of their large sites. It's still clouding some people's view – for want of a better phrase – on whether cloud computing will work for them, although if they look at the actual underlying figures the availability of public cloud is far higher than the availability of most private datacenter environments.

Andre: Right.

Clive: You know, artificial intelligence, machine learning, all of those will be coming through over the next 6 to 12 months to start having some impact within certain areas, virtual augmented reality. You know, now that the tools are there to help people, the systems are becoming cheaper, more cost effective, and I think we're going to see quite a lot of different systems, different approaches, different needs that are going to be driven by the business coming into IT where IT really just needs to figure out, well, how can we respond to this in the fastest, most efficient and most effective manner? And if they haven't got a DevOps underpinning to all of that, they're dead.

Andre: Clive, thanks very much for your time today. I found the conversation very interesting and I look forward to seeing you in London sometime soon.

Clive: Look forward to that. Thanks very much for your time.

Andre: Thank you.

Clive: We'll talk again soon.

Andre: Thank you.