Skip to content

Dinosaurs can be Unicorns too

I don’t exactly know what Benedict Evans meant by his one word comment on this chart, but I found the data interesting because of the frankly incredible ongoing performance of Microsoft, rather that the potentially more sigmoid looking curve of Apple (a model of saturation in a population, an s-curve which will dramatically plateau).

Plenty of smart people talk about Steve Ballmer’s time as CEO at Microsoft as a failure but I really wish I could fail like that. I watch enterprise software, and Microsoft has been turning in organic double digit growth in multiple billion dollar plus businesses year after year for over 10 years now. That’s impressive execution. Microsoft servers and tools business is perhaps a triceratops – a dinosaur with more horns than a unicorn. Has Microsoft succeeded at everything? No – but show me the company that has. Execution is really hard – thus the idea of “unicorns”.

Microsoft catching IBM in revenues is what really strikes me, and is perhaps what Benedict was referring to. Outsourcing is not a good place to be right now.

Our current fetish for outsize valuations is certainly interesting – the companies we call unicorns are valued at over a billion dollars, but the term says nothing whatsoever about revenues. These valuations are based purely on private, somewhat illiquid markets (to be fair a lot of smart people think Mark Cuban is wrong about the bubble).

When I think of dinosaurs I think of incredibly successful life forms, that thrived over hundreds of millions of years. It is mankind that looks more like a blip. Maybe that’s what Benedict meant? A dinosaur offers sustained performance over time. I suspect of course, that’s not what he meant.


I leave the last word to Marc Benioff.

Some disclosure: Dell, IBM, Microsoft are clients and I am certainly not a stock picker.

Categories: Uncategorized.

Programming Language Rankings: Summer 2015

summer 2015 rankings

This iteration of the RedMonk Programming Language Rankings is brought to you by HP. The tools you want, the languages you prefer. Built on Cloud Foundry, download the HP Helion Development Platform today.


“The basic concept is simple: we regularly compare the performance of programming languages relative to one another on GitHub and Stack Overflow. The idea is not to offer a statistically valid representation of current usage, but rather to correlate language discussion (Stack Overflow) and usage (GitHub) in an effort to extract insights into potential future adoption trends.”

RedMonk continues its exploration of programming language discussion and contribution with our ongoing rankings. We know our methodology isn’t perfect, but has proved a useful guide to potential adoption vectors – notably in the case of Swift. [bonus update – after I posted this on Friday I realised I had missed some stuff important out. Namely talking about the growing influence of our regular rankings. You see, we’ve had some amazing highlights over the last six months – namely that our rankings were cited by Apple, both by Tim Cook in its Q2 earnings report, and in the WWDC keynote.]

Swift is certainly the first language to crack the Top 20 in a year. By comparison, one of the fastest moving non-Swift languages, Go, ranked #32 in the original 2010 dataset finally cracking the Top 20 in January of this year.

Less surprising is the ongoing jousting for top-spot by Java and Javascript.

As with last quarter, JavaScript maintains a slim margin on second-place Java, with the caveat that the difference between numerical rankings is slight. The language’s sustained performance, however, reflects the language’s versatility and growing strategic role amongst startups and enterprises alike.

The growth in interest in Javascript should surprise no-one – new frameworks emerge on a daily basis. It is an ecosystem characterised by a rewrite all the things mentality, with NPM becoming a key ecosystem hub – as ever it’s all about packaging. But the ongoing strength of Java is more interesting – given that we’re seeing a shift in programming models with the rise of 12 factor apps, continuous integration and micro-services. It will be interesting to see how Java continues to adapt in the era of the Cloud Native.

As Stephen says:

One of the biggest issues facing users today is, paradoxically, choice. In years past, the most difficult decision customers had to make was whether to use BEA or IBM for their application server. Today, they have to sort through projects like Aurora, Cloud Foundry, Kubernetes, Mesos, OpenShift and Swarm. They have to understand where their existing investments in Ansible, Chef, Puppet and Salt fit in, or don’t. They have to ask how Kubernetes compares to Diego. Bosh to Mesos. And where do containers fit in with all of the above, which container implementation do they leverage and are they actually ready for production? Oh, and what infrastructure is all of this running on? Bare metal? Or is something like OpenStack required? Is that why Google joined? And on and on.

There are two things to unpick there. Requirements lean to particular language choices – for systems programming Go has emerged as the natural choice, led by the inimitable Derek Collison of Apcera.

Go: A year ago, we predicted that Go would become a Top 20 language within a six to twelve month timeframe. Six months ago, it achieved that goal landing as the #17 language in our January rankings. In this quarter’s run, Go continues on that same trajectory, up another two spots to #15. In the process, it leapfrogged Haskell and Matlab

Systems programming is not general purpose application programming however- the biggest challenge for Java will be ongoing relevance in an era where stateless programming is the norm rather than the exception, and where fragmentation is seemingly a given. [second bonus update – joining the dots then, we’re still witnessing the slow motion fall out of a model where, as Stephen points out, so much of the core infrastructure was built into the app server. Java is going to need something like Spring Boot to sustain it going forward in this new world, after all, as we have shown frameworks lead language adoption.]

Fragmentation is creating opportunities for languages like Rust and Julia. We’re faced with an interesting model where we’re seeing stability at the core, but a fair degree of movement at the edges, with new languages swiftly (please excuse the pun) coming to the fore.

A final word of thanks to HP. The rankings are Internet-famous, but they have hitherto been something we didn’t charge for. By adopting a sponsorship model I think we have a nice balance between funding our open work, and highlighting a company that wants to engage more closely with developers. The New Patronage Economy, as it were.

Categories: Uncategorized.

The Developer Aesthetic: On developerWorks Open Tech

I have been thinking a lot lately that as Software Eats the World so a new aesthetic, a set of patterns, practices, modes, mores and in-jokes emerges – I call this phenomenon The Developer Aesthetic (with apologies to James Bridle). It’s a way of seeing the world and presenting ideas for consumption and feedback- through software of course. Some of this is clearly codified- for example Rails apps or Twitter Bootstrap – but some is more implicit. At RedMonk we believe that Developers are the New Kingmakers, and if you want to engage with them it pays to learn their aesthetic.

IBM’s is currently refreshing developerWorks, its venerable developer portal, and frankly it needs the update. Any site designed more than 10 years ago is likely to feel a little tired. But what’s a company to do when the hackers are going elsewhere? One of our clients asked us this week whether it even makes sense for tech companies to host their own sites for developers in the age of Github and Stack Overflow. The answer is federation – interesting information is distributed, just as much as today’s computing infrastructures are, which is why I really like the new design for IBM’s new developerWorks Open projects pages.

As you can see below, IBM introduces a clean header design, with an at a glance view of Github related activity on a project. When I first looked at the site, however, I noticed that not all the information in the header was clickable. I let IBM know, and Dirk Nicol fixed it within 2 hours (rather impressive if you’ve ever worked with IBM) The sidebar also adds to to the reduced click nature of the site, with nice use of microcopy, for example with the clone button.


node red on developerworks open tech

Note IBM is also using Slack, the new collaboration hotness, to talk to developers.


IBM is a client.

Categories: Uncategorized.

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.


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




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.

















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









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.