IBM Cloud Satellite: Run and manage services anywhere Learn more

IBM Developer Blog

Follow the latest happenings with IBM Developer and stay in the know.

Learn new cloud-native methodologies that give us rigour, speed, engineering excellence, and happy users.


Oracle Code One 2018 talk

Monday, October 22, 12:30 p.m. Moscone West – Room 2011


We all know that cloud native is the thing in 2018, for very good reasons. The cloud promised us lower infrastructure costs, greater elasticity and scalability, and faster speed to market. But getting those benefits turned out to be tricky. Cloud native is a new way of building our applications so that the benefits of cloud are built-in. When talking about cloud native, it’s easy to focus on particular technologies: containers, kubernetes, microservices. That’s not wrong, but it’s not enough.

In order to live up to its promise, cloud native needs to be about how we create our applications and what we put in them, rather than just how we run them or how many pieces we split them up into. Containers are a great foundation for cloud-native apps, but cloud native is not a competition to see how many containers we can have. Cloud native isn’t a synonym for “microservices”. (If “cloud native” is a synonym for any architectural characteristic, it’s a synonym for “idempotent,” which could certainly do with a friendly synonym.)

Cloud native is about delivering value faster, which means value actually has to get delivered. As a consultant in the IBM Cloud Garage, I’ve worked with teams that, despite their best intentions and are made up of really smart people, aren’t able to get their product to the end users. They’re on the cloud, but they’re not benefitting from the cloud. What was going wrong? Sometimes the problem is a technical one – the CI/CD system is broken, and everyone is too pressured by their individual deadlines to fix it. Sometimes the problem is that important technical work got omitted; although there are automated unit tests, there are no automated integration tests. Effectively, on any given day, no one actually knows if everything still works together. That means shipping is too risky without an extensive UAT phase; a killer for business agility.

Another killer for agility is reluctance to compromise on scope. Minimum viable products (MVPs) and lean methodologies are now well-known, but there’s a gap between theory and practice. It feels uncomfortable to ship a product that’s small or that’s missing features that have been committed to the business. An MVP hurts. But the cost of waiting can be the difference between success and failure. There’s not much point in having a flotilla of containers, beautifully orchestrated in kubernetes clusters, if their contents only get refreshed twice a year. That means the business needs to be prepared to take risks and focus on responding quickly to user needs, rather than predicting them all in advance. Processes that used to add value for on-prem projects end up draining value for cloud ones.

The good news is that there are new methodologies that give us rigour, speed, engineering excellence, and happy users. The cloud is bright.