Melting the special snowflakes in Federal IT

“One of the things that as I’m looking across government is that we all think that in every agency we have such unique, special situations, and yet, every single time you go to another agency, they have that same unique, special situation,” she said. “Really opening that conversation and saying, we’re not all that unique and we are facing common elements and common practices and challenges… those are the things that we’re really trying to change the mindset of.”

Source: Only the beginning for agencies’ push toward agile

Pivotal Cloud Foundry 1.6, getting beyond the blinking cursor into the application layer

There’s a new release of Pivotal Cloud Foundry out this week. We’ve been seeing great pick-up from customers, and the nature of conversations I’ve been seeing while visiting them has been changing from operations, IaaS-driven topics to discussions about improving application development and delivery. This release also reflects that shift “up the stack.” Here’s my brief take on how things are going for Pivotal Cloud Foundry.

The most typical path to using Pivotal Cloud Foundry

First, this is how I see most customers arriving at Pivotal Cloud Foundry:

Who does Pivotal see as their toughest competition? According to Watters, that distinction belongs to AWS. Cloud customers often believe that AWS itself is enough. [James] Watters says that there wouldn’t even be the concept of cloud-native apps without Amazon, but “people need more than just Amazon to be successful.” Watters believes that some of Pivotal’s best customers are those who first tried to creates platforms themselves, but then asked “what’s the right thing to do for my organization?”

The rest of the piece is a good, brief overview of the new feature in Pivotal Cloud Foundry 1.6.

What I see in this release is a movement “up the stack” to address application architecture and development concerns. You can see this in the incorporation of Spring Cloud (which supports, among many other things, a microservices approach), support for .Net (almost every large organization wants and needs this for the way they develop applications), and the numerous integrations with ALM tools (like Cloudbees, GitLabs, etc.).

For many years – and still! – the focus of “cloud” has been on the infrastructure layer: setting up the “operating system” for the cloud, your big datacenter, and everything that results in that magical blinking cursor:

I think of this as the “blinking cursor” problem. You know that softly pulsing cursor: it’s the result of millions ­—if not billions! — of dollars spent on cloud projects. These “private cloud” projects see companies redoing how their IT department provides infrastructure. They move from physical to virtual management; move from manual ticket processing to self­-service, automated provisioning; and after efforts that must have seemed like building all of the furniture for a new IKEA store with just a pocket knife, they might end up with their own cloud. And then, after all of this, they’ve gotten the blinking cursor up! The servers are ready to use! Now the hard work of designing, developing, deploying, and managing the applications that run the business starts. There is little wonder that 95% of folks in [a poll asking “what went wrong with your private cloud project?”] were not completely satisfied with their private cloud projects.

I still see much of the conversation centering around getting the blinking curser up, and too little on how to create and manage good applications. So, obviously I like our new positioning “up the stack,” not only providing application-centric services, cloud-ified middleware, and the operations capabilities needed keep those application up and running.

In addition to the actual product, you can see this reflected on the team (the evangelist/advocate/community team) I’m on where we’ve added people who focus on explaining how to do better software development, in addition to the more operations-centric people we started with.

Momentum: customer and ecosystem growth and character

Momentum wise, I measure Pivotal Cloud Foundry based on customers and the overall Cloud Foundry ecosystem.

Customer wise, we’ve gone from about $40m in bookings in 2014 to a $100m annual bookings run-rate this year. Those are two, slightly different type numbers, but you can get a feel for the amount of business we’ve been doing, and more important, the high growth and fast traction we’re getting. What I like about out customer base is that they’re everyday, big brands and companies. This not only means I can better explain what I do to my non-tech friends and relatives, but also means we have a sustainable customer base: these Global 2,000 customers aren’t going away anytime soon, esp. if they keep up the strategy that brought them to Pivotal Cloud Foundry: transforming to a software defined business.

There’s a Cloud Foundry Summit this week in Berlin and it evidenced the ecosystem momentum around Cloud Foundry, the open source project that Pivotal Cloud Foundry is based on. There’s now just north of 50 members. When you look at those logos notice how many non-tech companies are on there: it’s still mostly tech companies who want to use or extend Cloud Foundry, but there’s a delightful number of non-tech companies who want to support the platform that’s supporting their business. And, of course, the work with Microsoft to support .Net brings that whole ecosystem very close as well. As I mentioned above, many of the every organization I talk with really wants .Net support. Another interesting thing to watch is growth in use of Azure; that’s an option that I hear companies exploring a lot now-a-days, and, indeed, as Microsoft said in the press around this release, “[t]he demand for Azure was so high that we already have Fortune 100 customers building their next-generation applications with Pivotal Cloud Foundry on Azure.”

Obviously, working at Pivotal I’m highly biased on all this. Still, I think there’s good evidence that things are panning out. My main hope, as always, is that we can help improve the state of software, globally, and, thus, improve how organizations are operating.

More on Pivotal Cloud Foundry 1.6:

Avoiding screwing up your cloud strategy: the greenfield journey

I’m doing a series of webinars based on my cloud native journey blog series, see the slides above (once the recording posts, I’ll embed it here as well!).

The gist of this series is my collection of advice on getting your cloud strategy right, mostly for large organizations. It starts with defining why you’d care (custom written software can now be used as a core competitive advantage, like never before), what the goals are (getting good at custom software development and delivery), and then gives advice across three different phases (greenfield, legacy, and organization transformation), or parts of the “maturity cycle” (a phrase I didn’t really use in the series).

Check out the first webinar on Nov. 5th at noon central, with two more coming in December, on the 1st and then the 15th.

Cloud Native Journey Series

I’ve been working on a series of blog posts on “the cloud native journey.” I put that in quotes because it’s admittedly a cheesy marketing phrase. The point of it is: if you’re looking to start using all these new cloud-based ideas for improving how your company does custom software development, what’s that look like. You know, what’s the “journey.”

Cutter Survey

All four parts are now up:

  1. The introduction to the series
  2. The Purity & Tyranny Of A Blank Screen: The Greenfield Journey – see also a recording of my webinar on this section, also the slides.
  3. Dealing With The Stuff That Makes All The Money: The Legacy Journeycheck the recording of the webinar on this section, too. Also, the slides.
  4. The Cloud Native Journey: Enterprise Transformation – check out the recording of the webinar on this part. Also, the slides.

There’s also a PDF of the whole thing if you prefer that format.

Tell me what you think of it!

Who run IT-town? Ops or Dev?

At container-oriented conferences, whenever a vendor or an open source contributor demonstrates the ease with which developers deploy containers to production, usually there are cheers. But in large enterprises, especially those that maintain strict compliance guidelines, it’s IT that makes the decisions about what gets moved from development to production, and how it is done.

This is what you might call the anti-RedMonk stance. In reality, nothing is as cut and dry as developers XOR operators being king. I’ve been in many strategy discussions over the past 5 years where the people involved would love for just one of them to be rulers of the roost. It’s make setting strategy so much easier than catering to both.

In my experience, it’s more like this: developers have a tremendous amount of influence and devilish-steering over long-term IT department purchases, while IT people control the gates and money.

  • Developers can also just subvert IT and totally ignore them. You get speed and flexiblity, but the trade-off is inefficiencies in the long-term: everyone is doing something slightly different so there’s no economies of scale with respect to knowledge, culture, or costs. (There’s a loop-hole where you all decide, for example, to run on AWS and “bottoms-up” decide to start collaborating and “work together” and all that – I’m not sure that pans out in donkey-land without a lot of centralized change management, though see below on DevOps.)
  • Operators can set orginization wide standards but have to “force” developers to follow their dictates. So, if you want orginization-wide standardization and “someone else” to pay the bill and help run it, you have to go through IT. Here, you have ultimate control and “governance”, but you sacrifice flexiblity and speed. (There’s a loop-hole here where IT establishes a centralized “cloud platform” [to use my work’s parlance] and lets the developers do whatever they want in the confines/contract on that box/platform.)

Of course, many of us have been trying to reuinite this “house divided” for several years, cf. DevOps. Hopefully that’ll pan out because what we really need are both those functions working together to not build boxes or subvert corporate best practices, but to focus on building good products and IT services. Good luck!

Composable Cloud At HP

“It’s not a microservice-built application; it’s not moving to a true CI/CD model; but it gets them incrementally on that path, and they start to get some value more short-term from that.”

“That’s where we focus: hit ’em where their problems are today,” he says. “‘Skate to where the puck is going,’ to use the Gretzky saying, but at the same time don’t skate out of the rink. Don’t come at them and say, ‘Hey, we have the microservices platform for you.’ ‘Awesome. What am I going to do with my SAP system?’ Getting that balance right is what we’ve been focused on.”

Bill Hilf on HP’s cloud approach.