🗂 Link: CIO interview: Simon McNamara, chief administrative officer, RBS Group

Mobile banking is another key area of innovation, including NatWest’s personal finance app Mimo, which uses open banking application programming interfaces (APIs), artificial intelligence and data analytics to create a social feed that helps customers manage their money. Mimo is being beta tested with 5,500 customers. NatWest aims to extend the roll-out later this year.

“These kinds of projects mean the people that work here feel much better about themselves than they did at the outset,” he says.

“I like the fact that our mobile platform is held in high regard by customers, because I see that feedback all the time. And it also irritates me that there are other services we provide that they don’t seem to hold in the same regard. So, that’s an opportunity for us, but also a challenge.”

Source: CIO interview: Simon McNamara, chief administrative officer, RBS Group

Link: CIO aan het woord: Sjoerd Blüm

The only assignment I have is to ensure that my teams get the job done. It is an illusion that I can or should be hooked one-on-one. My task is to put a point on the horizon where all those people move with their knowledge and skills and then ensure that there is an optimal setting where they can function.

Source: CIO aan het woord: Sjoerd Blüm

Google Cloud stuff

A brief overview:

The expansion centers around Google’s new open-source hybrid cloud package called Anthos, which was introduced at the company’s Google Next event this week. Anthos is based on – and supplants – the company’s existing Google Cloud Service beta. Anthos will let customers run applications, unmodified, on existing on-premises hardware or in the public cloud and will be available on Google Cloud Platform (GCP) with Google Kubernetes Engine (GKE), and in data centers with GKE On-Prem, the company says. Anthos will also let customers for the first time manage workloads running on third-party clouds such as AWS and Azure from the Google platform without requiring administrators and developers to learn different environments and APIs, Google said. 

And from an interview with Kurian:

So for us to grow, the primary thing is to scale our go-to-market organization. And we’re very committed to doing that. We just need to hire and train and enable a world class sales team at scale.

Today we have a great sales team, but we are far fewer in number than the other players. We just need to expand that. And as I talked to customers, they asked us to, one: expand our sales organization and our go-to-market teams. Second: specialize (that sales team) with deep expertise in technology and in industry. And third: make it easy to contract and do business with us. We are extremely committed to doing all three of them.

Also, from the product bucket:

Google also announced Anthos Migrate, a beta service that automatically moves virtual machines running on on-premises or other cloud providers into containers on GKE. Assuming it works, that’s a much easier path to the cloud for companies worried about breaking mission-critical applications during the move.

And, a good round up of analyst Tweets.

Every cloud providers, every tech vendor, wants to go up the stack, close to The Business where there’s more money to be had:

During his keynote, Kurian referred to Google Cloud as a “digital transformation provider” – he didn’t say an ‘IaaS alternative to AWS and Azure’. In fact, Google Cloud is open to the fact that enterprises may use multiple IaaS providers (more on that later). Kurian is clearly making a play for Google Cloud to become an enterprise technology vendor that has deep skin in the game with customers, focused on meaningful outcomes, rather than just a pay per usage alternative to other IaaS vendors.

They’re trying a more open source company friendly approach, adding in some popular databases as a service:

Initial technologies include those from open source database system providers Confluent, MongoDB, Elastic, Neo4j, Redis Labs, InfluxData and DataStax.

Also, see the very well written Anthos documentation.

Q&A on the Book Evidence-Based Management

The most important issue in organizational data quality is whether you have the data you need to test whether your beliefs about the organization are really true. So if I believe my organization has a reliable backoffice in terms of transactions, do I have the data that show how many errors are made a day or a month for a given volume of transactions.? Counts tell us almost nothing; we need rates, like errors/daily volume. If I am relying on my impressions, I am talking to myself.

Source: Q&A on the Book Evidence-Based Management

Link: OpenStack 2018: Mark Shuttleworth chats to The Reg about 10-year support plans, Linus Torvalds and Russian rockets

While he would obviously be very happy to welcome new customers to the Canonical fold, he points out that IBM is a “smart company” and says that “the guy who led the acquisition is the guy who engineered machines to beat Gary Kasparov. You might hope that there’s a good chess game going on there behind the scenes.”
Original source: OpenStack 2018: Mark Shuttleworth chats to The Reg about 10-year support plans, Linus Torvalds and Russian rockets

Link: Penn Jillette, In Conversation

“The things I worry about the most is that I’m completely uneducated. You couldn’t even really give me credit with a high-school education. That troubles me a lot. If we had to discuss trigonometry I would have to go and actually do homework before I could talk about it. I also just don’t have a solid liberal education. People who are very well-educated always tell me that education means nothing. But that’s because they have it. I also know, because I keep a very elaborate journal, that I am unreliable in terms of what I’m talking about. These are all things which come down to my worrying about not knowing what I’m talking about, and that’s the worst kind of bullshit. Also, like anyone who’s had success, I tend to give lip service to luck.”
Original source: Penn Jillette, In Conversation

Link: Can IT finally deliver innovation without busting its own budget? Docker’s CEO says yes.

“What we’re seeing at companies like MetLife or Northern Trust is they’re taking their app and infrastructure management cost, and cutting it in half. Let’s say that you can cut 15 million dollars out of your app and infrastructure management cost, which by the way, some of our customers are at. That’s 50 million dollars you can go spend on innovation. That’s not going to the CEO and saying look, I need another hundred million dollars in my budget. That’s freeing up 50-100 million dollars of your existing budget.”

I assume that jump from $15m to $50m is a typo, or something.
Original source: Can IT finally deliver innovation without busting its own budget? Docker’s CEO says yes.

Link: Q&A on the Book Agile Management

“Most of the available maturity models measure the degree to which the agile techniques and tools are deployed. I prefer to look at it from a different angle. First, define what your most important performance indicators are with respect to agility. For instance, time-to-market, employee satisfaction, customer satisfaction, and so on. Then benchmark these, if possible. And also follow their development over time, to determine whether they are improving or not.”
Original source: Q&A on the Book Agile Management

Link: Serverless at Bustle

‘Probably the biggest is: how do you deal with the migration of legacy things? At Bustle we ended up mostly re-architecting our entire platform around serverless, and so that’s one option, but certainly not available to everybody. But even then, the first time we launched a serverless service, we brought down all of our Redis instances — because Lambda spun up all these containers and we hit connection limits that you would never expect to hit in a normal app.

‘So if you’ve got something sitting on a mainframe somewhere that is used to only having 20 connections and then you moved over some upstream service to Lambda and suddenly it has 10,000 connections instead of 20. You’ve got a problem. If you’ve bought into service-oriented architecture as a whole over the last four or five years, then you might have a better time, because you can say “Well, all these things do is talk to each other via an API, so we can replace a single service with serverless functions.”’
Original source: Serverless at Bustle

Docker CEO Steve Singh Interview: All About That Migration To Cloud

The single biggest one is the move to public cloud, and this is where Docker is focused today. This is the number one area that we are putting all our investment in. We have this great container platform that allows you to do a lot of things, but just like any company, we need to pick an area of focus and for us, helping customers take legacy apps, moving them to the Docker platform, and allowing them to run it on any infrastructure because it’s hybrid cloud world, does a couple of things — it drives massive savings for customers, typically 50 percent cost reduction in a cost structure, but it also opens up real opportunities for the customer and our partners to innovate within that environment

Also, this is an insanely good example of a fluffy leather chair conference interview, plus, The Channel filter.

More:

Where does the 50 percent savings come from? A few different areas. The biggest is, honestly, in the mass reduction in number of VMs [virtual machines] and that’s not good or bad, it’s just the reality. The other is that there is a massively increased density factor on compute, and so we can put a lot more workloads on a fewer number of servers. If you are a [company like] Nestle, and you are going to take a bunch of information and business systems and move it to the public cloud, doing a one-to-one move is not necessarily all that advantageous.

Partners:

When I joined Docker I had a good conversation with someone over at Microsoft that said ‘I’d love to partner with you.’ His view was, the more people move to Docker, the more business they get on Azure. In fact, for every dollar we generate, he generates $7.

Momentum and the EBIT(A) chase:

we’re growing at 150 percent-plus year over year and expect that to continue for at least another few years. I’m hoping to get to profitability in mid-2019, and that’s important

Source: Docker CEO Steve Singh On The VMware Relationship, Security, And The Opportunities Around Containers For Partners

Core DevOps (tech) metrics, from Nicole Forsgren

Everyone always wants to know metrics. While the answer is always a solid “it depends – I mean, what are your business goals and then we can come up with some KPIs,” there’s a reoccurring set of technical metrics. Nicole lists some off:

These IT performance metrics capture speed and stability of software delivery: lead time for changes (from code commit to code deploy), deployment frequency, mean time to restore (MTTR), and change fail rate. It’s important to capture all of these because they are in tension with each other (speaking to both speed and stability, reflecting priorities of both the dev and ops sides of the team), and they reflect overall goals of the team. These metrics as a whole have also been shown to drive organizational performance.

And, then, further summarized by Daniel Bryant:

Key metrics for IT performance capture speed and stability of software delivery, and include: lead time for changes (from code commit to code deploy), deployment frequency, mean time to restore (MTTR), and change fail rate.

Also in the interview, a concise DevOps definition:

I define DevOps as a technology transformation that drives value to organizations through an ability to deliver code with both speed and stability.

See the rest.

Pivotal Conversations: The management perspective on transforming Allstate, with Opal Perry

I’m always interested to hear how management manages to change how software is done in large organizations – it can seem impossible! As ever, Allstate provides a fascinating stream of information here, and I was lucky to get the chance to interview Opal Perry there on how Allstate has been doing with all that cloud-native stuff.

Check out the listing on SoundCloud, and be sure to subscribe to the podcast if you like it.

Also, if you want to hear more, Matthew Curry and I had a similar conversation a few weeks ago at OSCON.

Gary Gruver interview on scaling DevOps

I always like his focus in speeding up the release cycle as a forcing function for putting continuous integration in place, both leading to improving how an organization’s software:

I try not to get too caught up in the names. As long as the changes are helping you improve your software development and delivery processes then who cares what they are called. To me it is more important to understand the inefficiencies you are trying to address and then identify the practice that will help the most. In a lot of respects DevOps is just the agile principle of releasing code on a more frequent basis that got left behind when agile scaled to the Enterprise. Releasing code in large organizations with tightly coupled architectures is hard. It requires coordinating different code, environment definitions, and deployment processes across lots of different teams. These are improvements that small agile teams in large organizations were not well equipped to address. Therefore, this basic agile principle of releasing code to the customer on a frequent basis got dropped in most Enterprise agile implementations. These agile teams tended to focus on problems they could solve like getting signoff by the product owner in a dedicated environment that was isolated from the complexity of the larger organization.

And:

You can hide a lot of inefficiencies with dedicated environments and branches but once you move to everyone working on a common trunk and more frequent releases those problems will have to be address. When you are building and releasing the Enterprise systems at a low frequency your teams can brute force their way through similar problems every release. Increasing the frequency will require people to address inefficiencies that have existed in your organization for years.

On how organization size changes your managerial tactics:

If it is a small team environment, then DevOps is more about giving them the resources they need, removing barriers, and empowering the team because they can own the system end to end. If it is a large complex environment, it is more about designing and optimizing a large complex deployment pipeline. This is not they type of challenges that small empowered team can or will address. It takes a more structured approach with people looking across the entire deployment pipeline and optimizing the system.

The rest of the interview is good stuff. Also, I reviewed his book back in November; the book is excellent.

Link

Puppet and containers

When we’re talking with customers about the value that Puppet brings to them, invariably we talk about the future, and the future in their mind in some ways includes containers. There’s a lot experimentation going on. There’s a lot of Docker work being done and container work being done, Kubernetes work being done on their laptops. The conversations we have with them is how does Puppet help you bring it into production, into mission-critical production? How do you keep it secure? How do you operate it? All of those things that we know how to do and have done with various kinds of infrastructure, whether it was OpenStack, whether it was virtual machines, whether it’s just server configuration. For us, we take the same approach to containers and are evolving our road maps to make sure that customers have the same benefits they’ve have had over the years now with containers or other technology.

From an interview with Puppets CEO, Sanjay Mirchandani.

Link

Enterprise DevOps interview with iThome Weekly

A little while back I did an email interview with Ray Wang from iThome Weekly, in Taiwan. It’s a little piece about DevOps getting more and more into the enterprise. To read the Google, robot translation, it looks like I did some things “single-handedly,” where in fact I was one of many hands.

As always, here’s the original email exchange we had:

Q. You mention about software-defined business in your article, can you tell more details about what is software-defined business? Why CEO have to think about the software-defined business? Why DevOps is so important for software defined business?

“Software defined businesses” are companies that are using custom written software to dramatically change and enhance how they run their business. Uber is a good example. Instead of just being a taxi or car service, they use software they wrote to change how their business runs: calling and paying for a taxi on your sell phone is much different than hailing a cab and paying in cash. Insurance and banking companies that are moving more and more of their daily business and interaction with customers to run over mobile apps and other custom written applications are another good example; we see this happening at Pivotal customers lie Allstate, Humana, and banks that use Pivotal Cloud Foundry.

Q: What’s your definition of DevOps? Does DevOps equal to Continuous Delivery?
Which definition of DevOps you don’t like most and why?

In general, I think of DevOps as the process and “culture” you wrap around continuous delivery to get the full effect of CD. I tend to speak about them interchangeably at this point; I suppose you don’t need DevOps to get the full benefits of continuous delivery, but they seem to go together well (you could always have just a jelly or just a peanut butter sandwich, but they seem to show up together a lot). CD is always looking to automate as much as possible, delivery to production frequently, and use the feedback loop this rapid cycle gives you (you an observe what your users does each week or day instead of each six months) which are many of the things DevOps seeks to enable as well.

It’s easy to get caught up in DevOps conversations that spend all of them time talking about “culture” and the need to change. I’m interested in that, but I always want to hear about actual, tactical things companies can do to get the benefits of DevOps. We all know how businesses use IT needs to change to be better, and that it’s hard to do so. I want to make sure the overall community is giving advice that’s helpful and, dare I say it, “actionable.”

Q: Should companies have to implement agile development before implement DevOps? Why?

It certainly helps to know what agile development is as a school of thought and to have done some form of agile to trust that way of thinking. If you’ve never done agile before, it just becomes part of trying to do DevOps. It’s certainly hard to think of being successful at DevOps without also doing agile software development.

Q: If CIO want to tell his CEO boss about what’s the value for non-technology companies , what’s your suggestion?

Time to market is the main, measurable, benefit. What that means, to me, is that software is being given to customers more frequently. New features and fixes come out weekly instead of once every 6 to 12 months. The business (the CEO) has to figure out what to do with time to market. If you can put a new features in production each week, how will that help the business? In the consumer space (where much of this mentality comes from) you can add more and more features to out-compete competitors. In the business space, the actual business has to change and evolve at a fast pace to fully take advantage of time to market. All that said, I don’t think any CEO is satisfied with the pace of change in IT. They’d all like it to move not just “faster,” but to get more meaningful features in production more often. Humana provides an interesting example: because they had been honing their software delivery process they were able to launch an Apple Watch app in just five weeks. That timeline is pretty amazing for most enterprise IT projects, let along being in the App Store on the first day of the Apple Watch’s release.

Q: Gartner say 2016 will be the year of DevOps. Do you agree with that? why or why not?

Sure, but I think you’ll see the next 3 or so years be the year of DevOps. I don’t think there’s any one year in particular that will stand out. I don’t think there was “a year of Agile Software Development” in the 2000s, it just took over slowly. What important is for companies to understand what DevOps can help give them – faster time to market for their software-driven products and services – and figure out what they’d do with that new ability. “Doing DevOps” is not easy, so you really need to value the end result or you’ll likely loose interest in the transformation process and let it unhelpfully fizzle out.

And, check out the recording of the DevOpsDays Austin talk referenced in the article if you’re interested.