Blogs

RedMonk

Skip to content

On HP Discover, Devops and the Developer Aesthetic

 

HP is very much a company in transition, again, as it prepares for a demerger that will leave two Fortune 500 companies – HP Inc (PCs and printers) and Hewlett Packard Enterprise (everything else). This post is about the latter. One issue with any analysis is that the situation could so easily dramatically change – rumours abound for example that the newly demerged HPE will immediately merge with EMC, for example. Leaving such speculation aside, HP’s direction of travel makes sense- becoming more developer-friendly.

For all the brickbats thrown at Leo Apotheker, one thing that began to change at HP under his short watch was the company view on developers.

HP has historically sold to seemingly everyone in IT except developers – it did a great job of selling to network managers with OpenView, service managers during the ITIL service management wave with Service Desk, QA teams with the purchase of Mercury Interactive, which essentially acquire the 2006 load testing market, and so on. HP was creating an Enterprise IT Management play, rather than a developer play. HP was also very much a delivery vehicle for packaged software ISV partners, rather than inhouse development (IT doesn’t matter, remember?) – such as SAP. 2006 however may have been Peak Waterfall – we’ve been moving to agile ever since.

So what’s a company to do when it has a stack entrenched in customer shops aimed at a previous way of doing things? Emphasize the culture change in moving to the new era, and retool accordingly. Which is where Redmonk comes in. We were invited to HP Discover recently to talk to customers and partners about DevOps and what it would mean for them. We weren’t talking product, but all the soft stuff. After all, as Adrian Cockcroft says: “DevOps is a reorg”. The conversations were fascinating. While HP does have some customers that are already wearing the t-shirt and the hipster beard, having reorged, rolled out Chef and Puppet, and then decided to standardise on Ansible, the great majority are still just wondering just to embrace this new thing. Change is hard. For traditional enterprise ops people is is especially hard.

Related to the DevOps conversation is the related transition to test-driven development and continuous deployment – given the business need to deliver more digital services to market faster. HP is decomposing its ALM tools to make them more applicable to the new era, in the shape of new tools like leanFT for functional testing, which supports Cucumber and JUnit, and of course Git, (now essential for any modern dev tool).

HP has now adopted the software engineering mantra of Shift Left testing, and needs to encourage its customers to do the same. The idea of Shift Left, is that unlike Waterfall, testing is moved earlier in the development cycle. Agile is all about about Shift Left- testing is something developers do as part of their routine – any good engineering manager today is all about the tests.

Of course you can’t completely eliminate bugs before pushing to production, no matter how solid your testing approach, so I also found HP’s mobile app crash analytics platform HP AppPulse mobile interesting – because it feels reasonably modern, although its not crashalytics, which has the Developer Aesthetic down cold, obviously.

hp-grommet-open-source-framework-370x229

Which brings me me neatly to Grommet. Not Wallace and Gromit, but Grommet – a UX framework from HP based on ReactJS. I was walking on the shop floor when a purple logo caught my eye. I stopped to find out more, and HP was just about to launch Grommet. The code was already on Github, but the team was still wrangling the logo, trying to decide on the right shade of purple, before the press release went out. We had a great conversation. Grommet is now a framework that instantiates a set of HP design guidelines, and apparently the HP Software CTO has now mandated than all new software will use Grommet and adhere to the guidelines. So HP now has a framework designed to help developers and designers work together, based on a popular open source project from Facebook and Instagram. So much so now.

Talking of the Developer Aesthetic another thing that impressed me was the process whereby a developer gets access to HP’s Idol OnDemand machine learning tools. Unlike the sign on process from pretty much every enterprise software and or cloud asset, this one is dead simple, in fact what you’d expect from a cloud native company. Shortly after noticing this I met Sean Hughes, HP’s new worldwide developer relations lead. He gets it.

idol login

 

Before signing off for now, I will just say that like IBM, HP is all about packaging the open source cloud stacks- HP HelionCloud, the company’s hybrid platform, is a Cloud Foundry for polyglot developers, OpenStack for ops people burger, which will be supporting Docker etc. One final piece of evidence HP wants to engage with developers- it is sponsoring our latest programming language rankings.

HP isn’t there yet, and the demerger could still throw up a lot of surprises, but the company is making progress in better serving the New Kingmakers.

 

HP is a client, paid my T&E.

Categories: Uncategorized.

We have a new Monk: Fintan Ryan

fintan

 

 

My partner has already written a nice post welcoming Fintan Ryan to the RedMonk fold, which I humbly suggest you read. The hiring process was very tough, as Stephen says, because of the exceedingly high calibre of applicant.

Decision-making was also complicated for me by the facts that not only is Fintan is a good friend of mine, but he also did some good work for us working on events on a freelance basis last year. I needed to be scrupulous in avoiding bias but his emergence as front runner from an excellent field was eventually quite clear.

Fintan has a wealth of experience in large systems development, project and product management from his time at Sun Microsystems, and then Oracle. More latterly he has been working at Weaveworks, a London-based startup building management tools to support Docker-driven software development. He also has community chops, running the Business of IOT and CoreOS meetups. It will be fun to have a colleague in the same city!

Fintan has the innate curiosity you need to be a good analyst. As Stephen says he asks good questions. He communicates well, and understands how to manipulate data. He says tings for things. He wears good t-shirts. I am looking forward to having him on the team and I am sure our community will give him a warm welcome.

Fintan will be adopting the patented RedMonk ADD-driven research method, which means a wide coverage area, with lots of cross disciplinary dot-joining. Expect coverage in distributed systems, Cloud Native infrastructure, machine-learning, cloud, clustering, storage engines and data stores.

Looking forward to find out what name he chooses for his blog.

You can find Fintan here on twitter here and github here.

Categories: Uncategorized.

Google Cloud: It’s the Infrastructure, Stupid. On Joining the Open Stack Foundation.

kubenetes

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Containers + Private Cloud. Google Sponsors OpenStack Foundation

Google bringing container expertise to OpenStack

 

Having published this post earlier – IBM Cloud: it’s the infrastructure, stupid, which made the argument that OpenStack may not be hipster, but will see enterprise adoption, I could have updated it, but figured I would make a quick, related post.

“From the perspective of the tech hipster it’s easy to dismiss Openstack as something for old fuddy-duddies, but the thing about old fuddy-duddies is that they have budget. For now OpenStack is too many vendors chasing too few customers, but it will continue to shake out.

Why OpenStack? It’s the Infrastructure, Stupid. When everyone else in IT turned around one day and realised Amazon was going to eat their lunch just as surely as software was eating the world they had to do something about standardising and commoditising the infrastructure layers of the stack – storage, network and compute – in a topology that resembled Amazon’s own services, without directly aping them.”

and on Google,

“It’s easy to forget that Cloud Scale from a Cloud Native doesn’t automatically mean success in the cloud. It it did, Google would be number one.”

Google, coming from behind, is gearing up for a major push around hybrid cloud infrastructure, rather than PaaS services, leading with Kubernetes for orchestration, which hits the 1.0 milestone next week, and Open Container Format for standards-based containers. According to the Google cloud blog:

“Few enterprises can move their entire infrastructure to the public cloud. For most, hybrid deployments will be the norm and OpenStack is emerging as a standard for the on-premises component of these deployments.”

From Google that’s a huge statement, marking a pronounced shift towards a more pragmatic view of the world. Unlike Amazon, then, Google doesn’t expect enterprises to go All-In on cloud. The other company pushing forward most aggressively with Kubernetes is Red Hat, the open source packaging company enterprises the majority of enterprises rely on. RedHat’s OpenShift v3 PaaS platform looks like Kubernetes+Docker+Atomic (Red Hat’s container optimised thin OS).

For specifics on what Google is contributing to, the OpenStack blog tells us:

“Openstack’s Magnum project directly integrates with Kubernetes, the open source project Google introduced in June, 2014, enabling new cloud native apps to run alongside traditional enterprise workloads on a single platform. The community has also created an easy way to deploy Kubernetes on OpenStack via the Murano project and the new Community App Catalog.”

Google as an on prem company, playing vendor sports with foundations and partners. This transition will be very interesting to watch in terms of culture – it’s not clear how Google engineering culture will adapt to supporting enterprise newbies. Meanwhile the news from other companies in orthogonal spaces (right now in distributed everything is orthogonal, comparing oranges and transistor radios) must be coming faster a lot faster than Docker would like at this point – certainly no breathing space after the inaugural Dockerconf. And there is more to come.

Another shot in the arm for Infrastructure as a Service.

Oh yeah-for bonus giggles you should definitely read my colleague on What is Open Stack.

 

bonus update! So just after posting, I got these great comments from Jeff Sussna and Lydia Leong.

Google’s OpenStack play is indeed “about Kubernetes” but that doesn’t lessen the significance of the the move. Google is acknowledging OpenStack as a customer context, community and channel. Pivotal recently did something similar with an outpouring of love at the last OpenStack summit. Seems like OpenStack is becoming not just a Foundation, but a foundation layer, a framework for the Cloud Native buildout.

 

related pubs – On Critical Mass: What now for OpenStack? Red Hat’s entirely rational position on OpenStack

IBM, Red Hat and Pivotal are all clients

Categories: Uncategorized.

IBM Cloud: it’s the infrastructure, stupid

I recently attended IBM’s Cloud Summit in New York City. Here are my subsequent reckons.

Firstly some semiotics – rather than a trip to Vegas or White Plains, NY, IBM had invited industry analysts to its new Astor Place facility in the East Village (just a few doors down from the Village Voice). The building is beautiful, staffed with people from the Watson team, but also IBM Design – which means a younger, hipper vibe than normal at an IBM facility, with tattoos and piercings. Also – you can get decent coffee nearby. Robert LeBlanc, who runs cloud for IBM, was even sporting a Valley Mullet (jacket, jeans combo) though he wasn’t wearing sneakers.

Further indications of change could be seen by the presence of Jesse Proudman, friend of Redmonk and founder of Blue Box Cloud, recently acquired by IBM. Jesse said the blue washing process (the acquisition process after you take the big blue pill) was surprisingly easy, and he was looking forward to dramatically accelerating data center rollouts globally. He also has some budget to run around and hire some fellow cloud natives, like Jill Jubinski and Tyler Britten, who both joined IBM in the last 2 weeks. I know he’s talking to some more (core engineering) talent, and we’ll hear more soon.

Blue Box builds OpenStack-based private clouds for customers than can be deployed on prem or off. But the company is also interesting because of its pre-Docker adoption of containers. It was already building a management stack designed for containers on Open Stack, rather than just VMs.

From the perspective of the tech hipster it’s easy to dismiss Openstack as something for old fuddy-duddies, but the thing about old fuddy-duddies is that they have budget. For now OpenStack is too many vendors chasing too few customers, but it will continue to shake out. IBM bought Bluebox. Cisco bought Piston. Oracle picked up the Nebula engineering team.

Why OpenStack? It’s the Infrastructure, Stupid. When everyone else in IT turned around one day and realised Amazon was going to eat their lunch just as surely as software was eating the world they had to do something about standardising and commoditising the infrastructure layers of the stack – storage, network and compute – in a topology that resembled Amazon’s own services, without directly aping them (Eucalyptus, acquired by HP, tried that route).

Enterprises generally want something solid and supported they can rely on, even if it isn’t “cool”.  But while OpenStack engineering was getting done, albeit somewhat slowly given all of the competing interesting involved, the industry got a notion they could simply leapfrog Amazon by moving up the stack – namely Platform as a Service, exemplified by Cloud Foundry, a Heroku knock off that you could run on prem or off. Marketing and strategy people got all excited about about PaaS. In IBM’s case this meant a deal to standardise on Cloud Foundry and a massive marketing campaign around its implementation, known as BlueMix.

The beauty of Cloud Foundry from a vendor perspective is that while the code is open source and portable, which gives customers the warm and fuzzies, the APIs exposed through may not be. It allows for some API-level lock-in (although good engineering and API choices can mitigate the issue in a cattle vs pets world) and data gravity (a potentially significant lock in in the longer term run). An IoT API for example might available in BlueMix but not Pivotal, for example. It’s easy to understand why IBM got excited about The New Middleware. So IBM and Pivotal are fighting it out for partner and API ecosystem dominance.

For PaaS though share of enterprise wallet remains unclear. Lots of POCs, not so much purchasing, barring some high scale exceptions. In the meantime, Amazon has continued to dramatically grow its business. Meanwhile – it’s easy to forget that Cloud Scale from a Cloud Native doesn’t automatically mean success in the cloud. It it did, Google would be number one.

But back to the Summit – IBM knows it has a lot of work to do. One reason I came away with a more positive impression of IBM’s strategy was the focus on Infrastructure. Jim Comfort, General Manager, GTS Cloud Development & Delivery, did a good job of talking up infrastructure issues, rather than BlueMix getting all of the attention. He talked about emerging customer topologies such as Scale Out Compute with Scale Out Storage, for example. Perhaps more importantly IBM was explicitly positioning to the effect that not all workloads are Cloud Native, 12-Factor etc. Enterprise developers are not used to building or running stateless apps.

So IBM offers Oracle in the Cloud. It signed the global deal to run cloud for SAP. One area it has some customres that hasn’t received enough is traditional Microsoft workloads shifted to the cloud. Amazon is making a killing there. Bottom line – IBM needed to give it’s infrastructure story more attention. In that sense job done. SoftLayer should not be a junior partner to BlueMix given infrastructure is the quickest potential route to volume.

Another important narrative that came through strongly from Don Rippert, GM Cloud strategy was the understanding that to Benjamin’s Black tweet above, the world has both stable layers and hipster layers, which evolve and degrade at different speeds. Sometimes a hipster stack becomes a stable layer. It is IBM’s job to ensure customers can use both where appropriate. The cloud business at scale is a packaging exercise. Because open source, not just for IBM but for everyone.

IBM still has a huge amount of work to but the major reorg announced at the beginning of the year is beginning to bed in.

IBM paid T&E. Amazon, IBM, HP, Pivotal and Salesforce are all clients.

Categories: Uncategorized.

In Tech We Trust: Eternal Sunshine of the Spotless Mind

The “rational optimists” say we’re moving in the right direction, and how can you argue against Hans Rosling’s bubble charts or Bill Gates’ multibillion dollar positivism/activism?

This morning the optimism was in high gear. Within about 10 minutes on Twitter we had

The BBC announced the Micro Bit, a potentially worthy successor to the BBC Micro, in getting kids to code. One of the lovely organisations behind it is called Technology Will Save Us.

And even better

Well thats good news. But there is more.

Or how about reforestation?

Or perhaps we don’t need tech per se, just the power of our imaginations

An argument based on empathy doesn’t seem so dumb when we have stuff like this

But then we live in a society that reveres banks over countries and communities. Optimism or not we’re clearly facing real and substantive challenges and dangers – mass extinction is pretty compelling evidence. Science is not a Cargo Cult, whatever the deniers might claim, though it increasingly looks like a religion in terms of the the faith we put in it. I am in the lucky position of being half-American so I am naturally pretty optimistic, but I am also a European so I believe in resource constraints. We all have a lot of work to do.  Technology can’t save us. Only we can do that, by choosing how to use it.

 

 

 

 

Categories: Uncategorized.

On Drawbridges and SecOps

drawbridge

 

 

 

 

 

 

 

Last night I gave a short (paid) talk over dinner at the Quality Chop House for a customer and prospect event held by Cohesive Networks – an app centric security company. It was interesting to compare notes with a group of London bank tech execs, and they had some amusing war stories. Anyway I talked about micro-services of course, and my theory that drawbridges are more important than moats. We also had fun talking about the cattle vs pets microservices distinction. While most cattle is somewhat disposable, not all of it is – think prize bulls… 

We all agreed that a key problem was domain knowledge. Too often the security people know about security, but not the rest of the stack. This has to change. SecOps know the business, the stack, and all the security goodness. Such people are hard to find. Similar situation obviously to DevOps.

It’s not just banks and enterprises that are ratcheting up their security investments. Seems like Cloud Native companies are also getting the memo – many have been remiss at securing assets behind the load balancing tier – they have not deperimiterised any more effectively than traditional enterprises = and so there is a lot of investment in that area at the moment. Related – Transport Layer Security (TLS), the successor to SSL for encryption, is making an impact, with Amazon releasing a new open source implementation, S2N earlier this week. Varnish Software CTO Per Buer told me earlier this week that his SF clients have all said TLS support is non-optional and has to be in place by year end…. 

The Cohesive pitch is that once the perimeter is breached, all other services are at risk. All apps should be individually secured at the network level.

Which brings me to to drawbridges. Generally when we think of security we think of fences, moats and high walls. These all play a role in security, but real security is granular control of who and what you let you in. A state of permanent siege is not a great way to get business done. Microservices need drawbridges as much as they need moats. Enterprises, cloud native companies and service providers should build all services as if they expect them to be exposed externally, just as you should write code so that it can be open sourced, with clean docs, clean interfaces and manageable granularity.

Anyway – here were my key takeaways.

  • Shift testing left
  • Develop all services as if they will be exposed to the cloud
  •   same as you should develop all code so it could be open sourced
  • Focus on drawbridges not moats
  • Microservices as a forcing function for better security
  • SOA underpins API Management, which will underpin Microservices
  •   performance not just features – see Amazon S2N lib
  • SOA as a style to manage internal and External access to resources
  • SecOps is now a thing

Categories: Uncategorized.

Java Development, Cloud Services, Continuous Deployment and PaaS

The world of application development, delivery and platform choices is changing absurdly quickly, as this great post from CircleCI – It’s the Future! – makes clear.

Web native companies are now used to getting new memos every day, but for enterprises generally, and certainly Java shops, all this change can be a little overwhelming. But change, like death and taxes is a certainty, and businesses are crying out for helping making digital transformations. There is no reason Java shops can’t be part of the transformation as software eats the world. After all, when web companies grow up, they turn into Java shops (see Twitter and Facebook to name two).

With all the current frenzy about “Unicorns” and greenfield web native opportunities it’s easy to forget that Netflix started life as a monolithic Java app running in a tomcat container.  Or that Amazon wasn’t born as a micro-services company – that came some time after the company was founded. Point being – Enterprises need to learn from innovative (or “disruptive”) companies, rather than using them as an excuse not to change.

Tomorrow I am doing a webinar with Oracle where we’ll be tackling many of these issues, looking at the role of Java development in the age of PaaS, Continuous Deployment, Agile and so on, in the age of the new kingmakers. Hopefully you’ll join us for what I hope will be a good conversation after the presentations. Please register here.

 

 

Categories: Uncategorized.

Refreshing APM: on Agile, Continuous Deployment, Hybrid and Micro-services

Application Performance Management (APM) is going through one of its periodical refreshes as new platforms and methods emerge and pressure grows on enterprises to become more like web native companies in terms of velocity of digital product and service delivery. This video, sponsored by IBM, represents some of my current thinking on the subject. Let me know what you think.

Categories: Uncategorized.

Opinionated Infrastructure Podcast: Java 20 years in, past, present, future.

Introducing a new podcast series, called Opinionated Infrastructure, for those of that don’t like to watch video rants while you’re driving. This first one is sponsored by Salesforce.com, which might surprise you given the theme is 20 years of Java, past, present and future. More surprising perhaps is that the guest is Joe Kutner, JVM Languages Owner at Heroku. Now don’t imagine we spend the show saying Java sucks, but JVMs are cool. That is not the point. Rather – what is the role of Java in a web native era? How did we get here, and what comes next. Heroku wants to be be a home for the new Java workloads.

Hope you enjoy the show. I will be making this a regular thing.

Categories: Uncategorized.

20 Dos and Don’ts about Presenting at Developer Events

from James Governor

A couple of months back I presented at IBM Interconnect about developer events and why they’re increasingly important. IBM is a client and paid my travel etc.

Some of the reasoning is fairly obvious. Twilio for example, is now adding $1m in annual recurring revenue every seven days, driven by participation in more than 500 developer events in 2014.

IBM itself has been investing heavily in developer ecosystems, events and locations, through its Ecosystems and Digital Cities initiatives. It’s been running tons of BlueMix (IBM’s Cloud Foundry implementation) training events, hackathons and so on. And of course it supported the Shoreditch Village Hall venue, by Shoreditch Works, helping to fund a space in which we ran developer community events and conferences such as London Node User Group, London Java Community, and Cleanweb throughout last year.

But for traditional companies, IBM’s core customer base, the obvious isn’t always so obvious, so I put together this deck to help IBM clients (and Big Blue holdouts) understand the value of face to face interactions with developer communities, but also to provide some advice about how to come across.

So here are some dos and don’ts. I bet you have your own pet loves and hates. Please make your own suggestions.

do and dont

 

 

 

Categories: developers.