Silver Linings, No Silver Bullets: 3 Perspectives on Innovating with Cloud
Tags: devops, cloud, aws
Published: 2021-12-15 09:48:08

---
title: Silver Linings, No Silver Bullets: 3 Perspectives on Innovating with Cloud
canonical_url: https://www.luminis.eu/blog/silver-linings-no-silver-bullets-3-perspectives-on-innovating-with-cloud/
published: true
description: We live in times of accelerating change; organizations that can leverage the cloud effectively will survive them, even thrive in them. How well prepared are you?
tags: devops, cloud, aws
cover_image: https://dev-to-uploads.s3.amazonaws.com/uploads/articles/hgq9v8h0foyxufylt3dm.png
---

Authors: [Auke Noppe](https://www.luminis.eu/expert/auke-noppe/) and Piet van Dongen

**We’ve heard the phrase, seen the cynical stickers: “There is no cloud; it’s just someone else’s computer.” That might have been true 15 years ago, but the thing we call the cloud has evolved significantly since. We live in times of accelerating change; organizations that can leverage the cloud effectively will survive them, even thrive in them. How well prepared are you?**

Taking great advantage of the cloud requires a shift in thinking: technology no longer belongs to the IT department (if it ever did). To become cloud natives, organizations need to learn to streamline their effort around everything the cloud offers.

Let’s look at this paradigm shift from several perspectives: operations, development, and leadership. Each of these perspectives starts with describing the ineffective way of working. We use the term **cloud naive** (as in: [inexperienced or lacking knowledge](https://www.merriam-webster.com/dictionary/naive)). Or as the [State of DevOps report](https://cloud.google.com/blog/products/devops-sre/announcing-dora-2021-accelerate-state-of-devops-report) classifies it: the way of the low performers. Then, we cross the chasm and look at it from the **cloud-native** perspective, as used by companies that use cloud technology to accelerate their business continuously.

![Two male relay racers running](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ih975sbupkjerztya19w.png)

## Operations: embrace speed to reduce risk

### Low performance: cloud naive operations

In simpler times, developers delivered complete software packages to operations people, who in turn installed and ran them on the appropriate infrastructure. Preferably not too often and with as little change needed as possible. A similar rule determined a snail’s pace of change for platforms: standardization before innovation. Why? Because every change introduced risk and operations were held responsible for it, often having to clean up the mess when things went wrong.

This model led operations departments to push back hard on changes and reduce the speed of change—developers adjusted by increasing release sizes and time between releases.

The result: slow change, little cooperation, suffering users.

### Elite performance: cloud-native operations

The way out of this standoff is well-known by now but not always well understood or effectively implemented: [DevOps](https://newrelic.com/blog/nerd-life/devops-name). Making agile teams responsible for business outcomes forces down the classical barriers between the business, developers, and operations, leading to better customer outcomes. Cloud platforms have evolved by adding layer upon layer of abstraction onto the classic data center, leading to [hundreds of managed services](https://aws.amazon.com/products/) that teams can continuously leverage to decrease their time-to-value. Perhaps counterintuitively, this increased rate of change enables teams to manage risk better than ever.

Think about it: if [time-to-value is the most critical metric for success](https://aws.amazon.com/executive-insights/content/cloud-for-ceos/), change size logically also gets smaller. Minor changes are easier to manage in case of failure, and deploying multiple times a day yields teams totally in control of their technological solutions.

This cloud-native way of doing operations yields precisely what these teams aimed for in the first place: [less risk, more control](https://aws.amazon.com/blogs/enterprise-strategy/please-do-not-take-more-risks/).

![Two female relay racers running](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/cx3ebiwugo37pcwp55vh.png)

## Development: focus on outcomes, not technology

### Low performance: cloud naive development

Before the emergence of the cloud, servers had to be installed by hand, as did the software running on them. Installing and testing releases was a time-consuming process, mostly done by other teams. So, developers made sure their sparsely released work contained as many features as possible. Any infrastructural requirements and other dependencies had to be carefully communicated and planned with IT operations, dictating long lead times between innovative ideas and customer value.

As a result, developers preferred working with stable, minimally variable environments simulated on their development machines. Their products were massive monoliths often written using a single programming language, running on single application container instances. Development feedback might have been fast; customer feedback certainly wasn’t. Developers were often kept totally in the dark about the impact of their changes in production until nightly calls from frustrated IT operations, who spoke in an entirely different IT dialect.

Again: slow change, little cooperation, suffering users.

### Elite performance: cloud-native development

The step-by-step virtualization and containerization of servers, platforms, and runtime environments have enabled development teams to master what was previously the sole job of operations. And more importantly, the marriage of Dev and Ops has given birth to beautiful things like [infrastructure as code](https://martinfowler.com/bliki/InfrastructureAsCode.html), CI/CD, and [SRE](https://sre.google/). Managing complex systems this way has opened up opportunities for creating massively scalable but well-observable systems. The old monoliths have been split into small, modular services or even single functions that typically communicate asynchronously using a [mind-boggling number of events](https://aws.amazon.com/event-driven-architecture/).

Now the customer wins. Changing, replacing, or radically rewriting a single, small module and testing and deploying it in the blink of an eye has become a reality. Experimenting — seeing if an idea for a new [job to be done](https://jtbd.info/2-what-is-jobs-to-be-done-jtbd-796b82081cca) holds up in production — has become cheap as chips using the pay-as-you-go managed services as provided by cloud platforms like AWS, Azure, and GCP.

![A field of male relay racers running](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/sd899lwk64rbmo1g0mzh.png)

## Leadership: get out of the way of innovation

### Low performance: cloud naive leadership

During less volatile times, markets were predictable, transformations were carefully planned and budgeted, and users were okay with incremental changes every so often. Software, and the hardware it ran on, were complex and expensive beasts, mastered only by tech masochists stuffed away in cost centers called IT departments. Nothing got built until it was very meticulously specified in requirements documents. Even then, the delivered result was often wildly different from what the market specialists and innovators defined months or years before, if not already outdated.

Once more: slow change, little cooperation, suffering users.

### Elite performance: cloud-native leadership

[Software has been eating the world](https://www.wsj.com/articles/SB10001424053111903480904576512250915629460) for a while now. Organizations need to adapt or accept a slow and painful decline into irrelevance. Users now expect to get what they need before realizing they do: a new Netflix series, a recommended product, or even [an improved driving experience](https://www.tesla.com/support/software-updates). Understanding users is key to market success and requires continuous experimentation and software development mastery. The cloud is a massive enabler: it enables organizations to focus on user needs by handing the management of [undifferentiated](https://medium.com/wardleymaps/on-being-lost-2ef5f05eb1ec) technology over to the cloud provider.

But while technical [skill development is essential](https://aws.amazon.com/blogs/enterprise-strategy/training-the-entire-enterprise-to-harness-the-clouds-full-value/), it is just one part of the innovation puzzle. Another is [culture](https://medium.com/aws-enterprise-collection/culture-eats-strategy-for-breakfast-a9c2e091a070): leaders need to focus everyone’s attention on the importance of time-to-value and agility as the metrics for success. To create empowered, self-sufficient, and effective teams, people need to come together and shatter the walls previously separating them. Lastly, leaders need to take the long view and realize that short-term risk aversion can be a major innovation blocker.

![Two female relay racers running](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/v2hz31qwdlxs79dgd6hq.png)

## To boldly go, together

Transforming an organization from cloud naiveness into cloud-native isn’t for the faint of heart, but very necessary nonetheless. Luckily, Luminis has traveled this path many times before and is a very effective guide on the path to cloud-native. For example, we helped OHRA, one of the largest Dutch digital insurers, [migrate its complete data center to the cloud](https://www.luminis.eu/cases/ohra-cloud-migration/). Another example is the [digital transformation of The Learning Network (TLN)](https://www.luminis.eu/cases/the-learning-network-innovations-for-digital-education/) we helped shape and implement.

[Get in touch](https://www.luminis.eu/contact/) and let us help you kickstart your cloud-native transformation.