Nine Ways to Fail At Cloud Native

Share this post:

Cloud native is the perfect recipe for innovation, adaptability and engineering excellence – when it goes right. When it’s not right, it can be a monster spaghetti, a quality headache, and frustratingly inflexible. Why so negative? The physicist Niels Bohr said “An expert is a person who has found out by their own painful experience all the mistakes that one can make in a very narrow field.” In the IBM Garage, I co-create cloud native applications with clients. We end up in a good place, but sometimes there are a few bumps on the way.

1 – The Magic Morphing Meaning

What even is cloud native? Built for the cloud? Running on Kubernetes? Microservices? Modern? Idempotent? If you ask five people to define cloud native, you might get seven different definitions. That’s not necessarily a problem, but if it can lead to disappointment if a stakeholder imagines they’ll be getting microservices and their team cheerfully builds a born-on-the-cloud monolith.

2 – The Muddy Goal

The most useful way to define cloud native is to think about what we’re really trying to achieve. Why do we want to be cloud native? Elasticity? Speed to market? Reduced operational and maintenance costs? Having a clear goal in mind will help everyone pull in the same direction.

3 – The Not-Actually-Continuous Continuous Integration and Deployment

Many cloud native programs don’t achieve their goals because only part of the dev organisation is working in a cloudy way. If code gets written, but not released, that’s value which is setting on the shelf. Sometimes the ‘continuous’ part of continuous integration and deployment gets forgotten. Releasing every six months isn’t continuous, no matter how many modern pipelines were involved. CI/CD is something you do, not a tool you buy.

4 – The Locked-Down Totally Rigid Inflexible Un-cloudy Cloud

A huge benefit of the cloud is that it makes it easy to provision infrastructure. This can feel a bit scary, so some organisations wrap a protective process around the fast cloud provisioning. In extreme cases, this process makes cloud provisioning exactly as slow and unwieldy as it was for traditional infrastructure. I heard of a company where standing up cloud servers took three months – on investigation, it turned out there was an eighty-six step approval process.

5 – The Mystery Money Pit

While heavy governance is pretty miserable, not having any idea what’s been provisioned isn’t ideal, either. The cloud makes it delightfully easy to provision infrastructure, but it doesn’t give any guarantees that what’s provisioned is useful. It’s easy for abandoned experiments to live on indefinitely, consuming electricity and money. When there are dozens of accounts and multiple cloud providers involved, getting a complete picture is hard. Who is using what? What for? How much does it cost? This is where smart tooling and multicloud management becomes essential.

6 – Cloud Native Spaghetti

“Cloud native” is sometimes understood as a synonym for “microservices.” An essential design characteristic of microservices is that they are decoupled, but I can report from experience that this is more of an aspiration than a guarantee; it is quite possible to write highly-coupled microservices systems (the “distributed monolith”). I was once called in to untangle a client system where any change to a microservice broke all the other microservices.

Explore cloud native tutorials: https://ibm.co/2uwmt13

7 – The Someday Automation

In the race to deliver features, it can be tempting to leave test and release automation for last. Automation is skilled work, which makes it even more tempting to defer until after the next release, or after the next funding cycle. Unfortunately, “our testing is manual” is equivalent to “we don’t know if our product currently works.” That’s not a happy situation. Automation is particularly critical for microservices, where release cycles should be quick and inter-service compatibility is not guaranteed.

8 – Microservices Ops Mayhem

Decoupled is great, but being distributed is more mixed. It has advantages, but also costs. Inter-app communication travels over the network, and there’s no compile-time checking – how should we handle API compatibility, integration testing, operations, service discovery, and fault-tolerance? Releasing is also harder – or rather, there’s a lot more of it. A traditional application might require a handful of deploys a year. If a cloud native application contains a dozen microservices, all deployed independently about once a week, that’s over six hundred deploys a year. Manual deploy processes with lots of handoffs are no longer going to work. The only way an organization can sustain that number of releases a year is if releases are deeply boring. All verifications, such as quality, compliance, and security, need to be automated and baked into the deployment process.

9 – Microservices envy

Some of the most technically advanced organisations in our field have achieved brilliant things with microservices. That doesn’t mean they’re the right fit for everyone: there isn’t a competition where the organization with the most containers wins. If you’re already working in a small team, not planning to release independently, don’t want the complexity of a service mesh (or, worse yet, a home-rolled service mesh), or your domain model doesn’t split up neatly, microservices may not be the right choice for your team.

No one’s getting to get everything right all of the time, but my job in the Garage is to help clients succeed. Learning from the mistakes of others and keeping a determined focus on “why” and “what problem are we trying to solve” of any new technology pattern is a great start.

I got together with colleagues from across IBM and one of our clients Ricky Delandro from Apater to share experiences and success of building cloud native. Watch the recording of our discussion to help you build cloud native at pace: http://ibm.biz/CloudNativeWeb