Skip to content
Contino
  • About Us
  • Our Services
  • Case Studies
  • Content Hub
  • Events
  • Blog
  • Join Us
  • Contact Us
David Dyke

Cloud-Native Software Development: What It Is and Why It Matters

(This is the second in a three part series on cloud-native. Check out part one: Cloud-Native Architecture: What It Is and Why It Matters! and part three: 23 KILLER Cloud-Native Software Development Principles and Practices!)

The public cloud is COMPLETELY changing the rules of the game when it comes to software development.

It removes many constraints and opens many doors...allowing devs to put their code (and therefore the customer) at the centre of everything they do.

And it turns out that this has MASSIVE implications for how you should go about developing software.

What Is Cloud-Native Software Development?

Cloud-native software development is about creating software in a way that maximises the game-changing capabilities of the public cloud.

The cloud is the biggest enabler in a generation.

It’s a massively scalable, flexible, distributed platform that comes with a huge amount of capability straight out-of-the-box.

Having all this power on tap inevitably changes how you develop.

How the Cloud Impacts How You Develop

Following on from our last blog on cloud-native architecture, let me reintroduce Tara, a keen young developer. This time she also has a friend, Dan, who heads up the Ops team.

Together, they’re going to take us through the way they are impacted by the cloud.

The Cloud Turns Your Ops Team into an API

In the cloud, infrastructure of all kinds can be defined as code and be deployed by running a quick script.

Effectively, the cloud turns your ops team into an API.

In the cloud-native world, Tara has turned Dan into code.

(Don’t worry, Dan learns some cloud and rejoins Tara later in the tale…!)

This frees Tara from all kinds of constraints (waiting for servers, negotiating with procurement teams, being blocked by environment logjams etc.).

All she has to worry about is her code.

Everything else just...happens.

The consequence? The flow of software is massively accelerated through the organisation.

Development becomes much faster.

(Check out our cloud-architecture article for an S3 bucket load more detail on this.)

Deploying to Production Becomes Routine

But even if you can develop quickly, what about the problem of deploying to production?

Deployments used to be so risky that the threat to a dev’s weekend plans of deploying on a Friday became meme-worthy.

In this code-defined world, however, deployments are reduced to nothing more than an API call.

The fact that deployment (and automated roll-backs!) are so easy instantly lowers the danger of running code in production to almost zero.

It makes running code in production totally routine.

Like brushing your teeth. It’s just something you do without thinking about it.

And this massive de-risking of the whole deployment/roll-back hullabaloo removes the biggest obstacle that stood between Tara and her user: FEAR!

Now Tara Can (And Will) Deploy Small, Fast and Often. With No Fear.

Deployments used to be a lot of effort. Because of the risk they would be done at night (when traffic was low) and would often go wrong, leading to outages that Tara would have to spend all evening fixing.

No surprise then that, when deployments were risky and painful, Tara would try to smash as much code as possible into as few deployments as possible.

This is seriously stressful.

It also puts a lot of pressure on the code you release being what the customer wants!

(You don’t want to bust a spleen deploying a new feature that your user doesn’t actually give a hoot about!)

But when the flow of code is freed from constraints...suddenly the whole problem dissolves!

You can release as small, fast and often as you like. No fear.

Tiny chunks of code can whizz through the whole development lifecycle insanely rapidly.

But developing and deploying fast is no use if you don’t know that what you’re doing is the right thing!

Insane Transparency and Operability Out of the Box

Cloud platforms offer an ever-rising tide of operability offerings.

There is a huge amount of out-of-the-box tools and services for monitoring, logging, tracing and so on along with in-built metrics for things like response times and failure rates.

This makes high-quality operability—Tara knows what’s going on, everywhere, all the time—the default!

This has two consequences.

Firstly, the system knows about errors and bugs before Tara (or her users!) do.

Because of the cloud’s epic observability features, you can trace problems through the entire tech stack to find the root cause.

On one cloud adoption project at a large energy company, I set up a system so that every request had a unique request ID that could be tracked through the whole tech stack.

If something failed somewhere I would be instantly notified via Slack with the request ID along with time-stamped logs. I could see everything that had happened in relation to that request ID throughout the system...without having to do anything!

I could then instantly see where the error was. It would then take only a few minutes to deploy the fix and voila: prod is working again!

Secondly, it brings Tara so much closer to her users.

Because Tara can see how they interact with her product she gets instant feedback on what works and what doesn’t.

(Although this is no substitute for a proper requirements elicitation process!)

If users are smashing the hell out of (say) her new chatbot but ignoring her new automated recommendations feature, then she knows where to concentrate her efforts!

This gives Tara data-driven insights that feed into the next dev cycle so she always knows what she needs to prioritise in the next sprint.

You Have All the Tools You Need On-Demand

The cloud has more commodity services available than Tara could ever build herself in 100 lifetimes.

At the time of writing, AWS has over 175 services covering everything from dev tools to image recognition software.

Plus, remember that you can even call services that aren’t in your cloud provider. Like the rising tide of ‘API-based SaaS companies’ such as Stripe (for payments), Twilio (for communications) or Segment (for customer data).

If Tara at any point starts manually implementing commodity technology, she should stop, pause and ask herself: hang on...this must exist somewhere! If there are more than 10 potential users for this it’s a safe bet that someone (somewhere!) has produced a cloud-native API for this. 

This frees Tara from even more constraints (having to run around to get all the tooling she needs) allowing her to focus solely on core business value: Her code. Her customer. 

Why Cloud-Native Development Matters

In the cloud-native world, Tara can dev fast, get tools quick, deploy on-demand and fix issues on the fly.

These huge quantitative changes in the size, sophistication, safety and frequency of code releases has a huge qualitative impact on how you develop software.

This is analogous to the history of writing.

The invention of ink, the printing press, the typewriter, the word processor, the internet, Medium, etc. enabled revolutions in the quantity of writing produced that had huge qualitative impacts on how people relate to writing.

Over time, trying ideas out became cheaper and easier. You can work much more freely with your ideas on a Google Doc than you can with a quill and inkpot!

The changes that have occurred in the world of development are similar. Let’s let Tara explain.

1. She Can Respond to Change

When Tara, firstly, can deploy stupidly fast at low risk and, secondly, is backed by an incredibly rich cloud-native tech stack a very cool thing happens.

She discovers that she suddenly has confidence in her ability to respond to change.

Dan used to hate change. It could only mean bad news. He always used to push back when Tara wanted to deploy something.

Since then, Dan has learned how to automate deployments in the cloud! Now, he can deploy a new feature to production at the push of a button. If it fails, he rolls it back just as easily.

If, after deployment, Tara decides that maybe another type of database would be more suitable, she can just get Dan to roll that out. Or if users dislike a new feature, she can just ditch it before investing any more time and money.

No stress.

You see what happened there? All of a sudden Tara doesn't need to worry about getting everything right upfront.

She can respond to change without fear. She can move with your customers’ needs and follow them more closely than ever before!

2. She Can Adopt an Experimental Approach

When change isn’t scary, you can try things out. Experiment.

Imagine that Tara is told that her software needs a password-less login feature.

In the old world she goes away, designs the whole thing, buys new hardware to build and run it on, gets her team working on it and voila: three months later she unveils the new feature.

What if it turns out users don’t want it? Or management changed their mind?

In the cloud-native dev world, you can rapidly build a minimum viable product, complete with in-built metrics, to measure whether or not users actually use the feature.

Then, based on genuine user feedback, Tara can make a decision on whether it's worth putting more dev time into the project or not.

The key point is this: Tara can invalidate ideas using data-driven feedback in DAYS. Not months.

This won’t necessarily bring joy to your product owners but it will bring value to your company!

3. She Can Bring Agile to the Core

The cloud brings the principles of agile to the core.

You could even say that the cloud is the technological manifestation of agile principles.

It puts the power back in Tara’s hands!

No longer is there a council of architects that dictate the kinds of resources that Tara can use and how they are deployed.

Infrastructure is now part of the circle of development (see below), rather than being the platform that the circle was built on.

This means that a major bottleneck to ‘real agile’—infrastructure—can now be managed in an agile fashion. Emergent architecture, i.e. evolving your architecture one sprint at a time, becomes a reality!

Every station on the circle of development can then be managed on a sprint-by-sprint basis.

Agile becomes real!

4. She Can Use Microservice and Event-Based Architectures to Accelerate Innovation

The cloud lends itself naturally to both microservices and event-driven architectures.

With microservices, apps are built as a collection of services, which pairs up perfectly with the distributed nature of the cloud. Each service can be hosted individually and treated as its own isolated ‘unit’ without needing to touch the rest of the application.

So, Tara can make changes to (say) her payment system independently of her personalisation system.

The situation is similar with event-based fun.

Everything that happens in the cloud is (by default) recorded as an ‘event’ that can be ‘consumed’ by other teams/services for their own purposes.

For example, when you do a Google search, that appears within the Google ecosystem as an event that can be exploited (in principle) by other Google teams for use in their own domain.

So the Google Ads team could use it to determine what ads you see, independent of the Google Search team. 

The key point is this: both microservices and events foster independence between teams. 

The result?

Now all of Tara’s product teams can innovate at different speeds and can independently find the maximum rate of innovation for their area.

The natural cadence of innovation can emerge organically. To add or trial new features you need only subscribe to an already-existing event—and all you need to know is how to consume it. This makes you entirely decoupled and independent from other teams (except for the type and structure of the events they produce).

Whilst Tara could still do this in an on-prem environment, it would take a significant amount of time, effort and resource to build this event-based system (not to mention the amount of maintenance required to keep it operational). In the cloud it’s readily available for you at much less cost than rolling your own and it’s all managed by the cloud provider.

5. Break Free From Legacy with Serverless

Serverless is the “most cloud-native” that you can get because the back-end is entirely invisible and automated.

Tara only worries about her business logic (plus a smidgen of orchestration). The cloud provider takes care of the rest.

The high degree of abstraction also allows Tara to completely break free from legacy architecture and processes that may have been preventing her from releasing at speed.

This is a HUGE win.

There is no better way for Tara to get close to her customer than by using serverless.

(It’s also is a key enabler for microservices-based or containerised applications. It makes infrastructure event-driven, completely controlled by the needs of each service that make up an application.)

From Idea to App in the Quickest Time Possible

With cloud-native approaches you can respond to change, experiment, be super-agile, and take advantage of the latest technologies to get from idea to app in the quickest time possible.

All of which frees Tara to hone in with almost obsessive focus on...the customer!

More Articles

9 Killer Use Cases for AWS Lambda

27th February 2020 by Richard Bennett

Who's Using Microsoft Azure? [2020]

20th February 2020 by Dave Tracey

Cloud-Native Architecture: What It Is and Why It Matters

13th February 2020 by David Dyke

Sign-up: Insights Directly to Your Inbox

Join tens of thousands of your peers and sign-up for our best content and industry commentary, curated by our experts.

You may unsubscribe from these communications at any time. For more information on how to unsubscribe, our privacy practices, and how we are committed to protecting and respecting your privacy, please review Privacy Policy.
Contino
  • Londonlondon@contino.io
  • New York newyork@contino.io
  • Atlantaatlanta@contino.io
  • Melbournemelbourne@contino.io
  • Sydneysydney@contino.io