Cloud-Native Architecture: What It Is and Why It Matters
(This is the first in a three part series on cloud-native. Check out part two: Cloud-Native Software Development: What It Is and Why It Matters! and part three: 23 KILLER Cloud-Native Software Development Principles and Practices!)
Cloud-native architecture is the biggest enabler in a generation.
Done well, it lets the developer simply develop. To focus solely on what really matters: creating software that your customer wants (loves!) to use.
Everything else they need just happens.
What Is Cloud-Native Architecture?
Cloud-native architecture fully takes advantage of the distributed, scalable, flexible nature of the public cloud to maximise your focus on writing code, creating business value and keeping customers happy.
Going cloud-native means abstracting away many layers of infrastructure—networks, servers, operating systems etc.—allowing them to be defined in code.
As much infrastructure as you need (servers, databases, operating systems, all of it!) can be spun up and down in seconds by running a quick script.
All the developer has to worry about is orchestrating all the infrastructure they need (via code) and the application code itself.
Cloud native removes constraints, shortening the path to business value.
There is a seldom-spoken truth that bears being spoken: the only thing that really matters is the stuff that your customer is interacting with.
The less you have to worry about anything else beyond the code that gives life to your business, the better.
And that’s what cloud-native is about.
Unlock Your Ideas
Let’s illustrate this with an example.
Let’s say that user feedback for your mobile banking app suggests that users really want a bill-splitting function.
In the old world, you might first start by wondering how you would deploy it, what networking you need, what you’re going to write it in...and slowly what really matters (THE CODE! THE CUSTOMER!) slides into the background as niche technical concerns cloud the horizon.
In the new world, a decent cloud-native setup removes the need for servers, operating systems, orchestration layers, networking...putting your code front and centre of everything that you do.
You (or your team) can try things out straight away. Test hypotheses. Experiment.
Maybe this kind of database is best for the bill-split feature? Or that one? What about incorporating a machine learning tool?
Any kind of ‘what if we did this…?’ question can be (almost) instantly tested in practice, giving you a data-driven answer that you can build on.
When you’re constrained by infrastructure, your ideas are on lock-down. When you want to test something out, you instantly hit a brick wall: hardware!
And whatever solution you come up with will always be a compromise based on the limitations of what you have in your data centre. But compromises don’t always win customers!
When the cloud removes those constraints, rather than focusing on technology you can focus on the customer experience. Think about products, not pipelines. Fix errors in your app, not your database replication.
And all of this means that you can get from idea to app in the quickest possible time.
In a cloud-native world, your ideas gather feedback, not dust!
But there are many benefits to cloud-native architecture beyond the simple ‘it lets you focus on your code’. And that’s what we turn to now.
How Does Cloud Native Architecture Unlock Your Ideas?
Let me introduce Tara.
Tara is a teenage developer-in-training. Because she’s growing up in a cloud-native world, she will become an awesome dev without ever having to know how a server works.
When she learns what people had to go through before the advent of cloud-native to get their work done, she will be amazed.
Tara is going to take us through how cloud-native architecture unlocks your ideas!
Removes Constraints to Rapid Innovation
This is the circle of (dev) life. At the top is the user. At the bottom is Tara and her team.
The faster Tara can go round this circle—delivering features to users and getting their feedback—the faster ideas can be turned into customer-pleasing reality.
By removing time-consuming way stations from this circle, cloud-native allows Tara to whizz round much quicker than was previously possible.
There are other tricks as well. One example is traffic shifting: this allows you to ‘toggle’ (i.e. release) a given feature to a small percentage of users, gain feedback and then slowly expand access to more and more users.
Remember our bill-splitting example from above? The difference in time-to-market between being able to test things instantly and having to wait to procure a new database (for example) REALLY adds up.
Here’s an indicative sketch of the different timescales. (And, yes, this is a bit contrived and not necessarily true everywhere, but it illustrates the point).
In this example, after a few days Tara and her team have deployed a prototype of the bill-splitting feature and are gathering feedback. In the old world, she would still have been waiting for a server!
Try to force Tara to wait three weeks for a new server to try out an idea and she won’t be very impressed. She might even go and build a competing challenger bank in the meantime.
Brings You Closer to the User
Often developers don’t understand what users really want.
And every process you put between users and developers is a place where the original vision can go astray.
The closer you can put your dev team to the customer, the better the product will be. As we’ve seen, cloud-native’s key benefit is just that: eliminating non-customer-focused activities.
This goes deeper, though! Because of the move towards rapid innovation, customers now expect rapid delivery of MVPs that they know are going to be improved over time. People don’t expect new apps to have a host of functionality and a bug-free experience straight away, but they do expect continuous improvements over time.
Your customers also want small, rapid releases. It doesn’t only belong to the realm of mystical Netflix engineers or the people who edit CIO.com.
This shift in customer expectations is probably permanent. What this means for you is that prototype is now as important as product.
And because cloud-native architecture let’s you roll out features to a small percentage of your users, you can test prototypes with actual customers in real-life situations. Not testers in a UAT environment!
This way, Tara can get irrefutable proof that users like (say) her new bill-splitting feature before she invests in developing the idea further (or ditching it).
Very Cheap and Easy to Get Started
The barrier to entry for cloud-native infrastructure (cost- and effort-wise) is about as low as you can go.
Firstly, in the cloud you only pay for what you use and don’t have to buy anything upfront.
(In fact, some cloud providers will allow you to get started for free, by giving you access to some features for nothing.)
Secondly, these cloud providers are operating at insane economies of scale, which means you can access cutting-edge infrastructure and tooling at a fraction of what it would cost to deploy these in your own data centre.
Thirdly, once you have done the initial account setup, accessing any of the cloud providers’ massive range of infrastructure or tooling is approximately as complicated as ordering from a pizza from Just Eat (choose your ingredients => order => consume).
These advantages mean that you can try out new instance types, databases, tools, whatever you need with minimal cost, risk and effort.
Exactly what you need for rapid innovation and experimentation.
If Tara wants to see if database X or Y works best...she is free to just try them! Or if she wants to test a quick script? Whack it on AWS Lambda for five minutes and see. What about seeing what value machine learning could add? As soon as she has the idea she can spin up AWS Sagemaker and play around.
Try to convince Tara that she needs to go through a lengthy procurement process to buy a whole range of hardware and tooling that her team now has to manage forever...just to test out an idea?
Knowing What, Why and Where: Transparency, Security and Event-Based Fun in the Cloud
A major difference between the cloud and on-premises is that in the cloud—by default—everything that happens or changes is ‘stored’ as events that are transparently logged.
You know exactly what went on (or is going on), when and where.
This has some interesting consequences!
The cloud is event-based by default.
And this lets you set up awesomeness-inducing if-this-then-that workflows. Like when you search for “Cloud-Native for Dummies” on Amazon, this instantly triggers not only the search but also an update to your recommendations, your search history, the ads you see and so on. This is all event-based magic.
The clincher is this: all the events can be globally available!
So if a team posts an event (e.g. someone searches for something) then other people in other teams can start using those events as triggers for features in their own domain. So one event can trigger multiple reactions, each built by different teams across the business for their own purposes. All entirely independently of each other.
To do this on-prem, Tara would need something akin to three different Kafka instances and a ton of finicky infrastructure.
In cloud-native land Tara just says: when event X happens, do Y. She doesn’t have to worry about anything else.
Transparency and Observability
A server running on-prem is a black box.
Cloud-native tech, by contrast, automatically logs what’s going on and gives you nice metrics, colourful dashboards and automated notifications.
So Tara can create a serverless function, run it and be alerted via Slack or SMS if something goes wrong.
And this is just out of the box!
This opens up epic possibilities.
If you write crappy code (no amount of tech can save you from that…) it can alert you to problems and fix them before you realise they were there.
If you’re a bank and your customers can’t transfer money, the dev team will know there is a problem before the call centre gets overwhelmed with angry messages. Your deployment can be released to just a handful of users to transparently test it and automatically roll-back if things go awry, only affecting a couple of customers.
It can even help you take a data-driven approach to business decisions. Say 50% of customers going through Tara’s e-commerce checkout don’t actually complete the transaction. If you suspect that (say) the position of the button is causing a drop-off you can easily do a split test, log how many people check-out and work out the best solution.
This is HUGE from a business perspective. And it’s so simple from a technical perspective. (So long as you go cloud-native).
Without security expertise, with on-prem you could have a massive attack surface with loads of open ports and firewalls and such. And in my experience, no one would even know which ports were open because the spreadsheet tracking it hadn’t been updated in four months.
In the cloud, it is easier to make the attack surface much, much lower. If you create a container or a serverless function, for example, nobody has access to it—unless you allow them to. The declarative nature of access management, roles, and policies prevent unauthorized individuals from poking around where they don’t belong. There is less security expertise needed as your cloud provider takes care of a good chunk of it.
And your security standards can be very easily defined and replicated across your entire infrastructure. It’s even very easy for others to understand how security has been defined.
This means that security configurations can then be automatically deployed, tested, monitored and reported on across your entire IT estate. Not to be sniffed at! If any of your teams try to deploy something which breaks those rules, their pipelines can identify it and will stop before any damage is done.
By making security standards easy to consume (for humans as well as machines) you instantly remove the biggest constraint to rapid, effective security (reading the 97 page security manual) and make it instantly scalable by translating it into automated scripts.
It also becomes less of a mythical dark art that only a few people in the company understand. Instead, everyone is aware of how it works, which breaks down silos of responsibility.
After all, it doesn’t matter how fast Tara can code if she doesn’t have a means of guaranteeing security just as quickly!
How Cloud-Native Architecture Opens You Up to Rapid, Data-Driven Experimentation
Ultimately, the end goal you’re looking for is this:
Whenever someone says “what if....THIS?”
You can confidently lunge forward and reply: let’s try it!
Development becomes a science: you hypothesise, test, analyse the data and conclude the next course of action.
Did sales go down? Leave the button where it was.
Did sales go up? Move the button for everyone!
Tara can have an idea in the morning and it will have lunged its way to production by that afternoon—all without compromising on quality, security, or performance.
Rather than having to work out a business plan, including how much hardware she needs and how much it’s going to cost.
But...it’s not that simple is it?
OK. This all sounds great on paper. But we know it’s not so simple to turn the oil tanker around in real life.
We get it.
But we have jumped into massive organisations before and kickstarted cloud-native projects in only a few weeks.
In only five weeks we helped Green Flag to deliver a serverless cloud-native platform to break away from their legacy technology and build the foundation for a modern rescue service.
New features can now go from dev to prod in under 30 minutes using infrastructure that is much more cost-effective.
We helped Direct Line Group to create a serverless insurance start-up that utilises machine learning to treat customers on an individual basis. In DLG’s own words it is “built for tomorrow”: i.e. built around experimenting so they can take steer from what their customers want and adapt accordingly.
It is possible! Good luck ;)
(This is the first in a three part series on cloud-native. Check out part two: Cloud-Native Software Development: What It Is and Why It Matters!. Part three is on the way!)