(The following is a guest post by cloud transformation consultancy Contino, originally published here: https://www.contino.io/insights/what-is-cloud-native-architecture-and-why-is-it-so-important)
Cloud-native architecture is the biggest enabler of a generation. Done well, cloud-native architecture 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.
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.
What does this look like in practice?
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!
How does Cloud-native architecture unlock your ideas?
There are a ton of different ways that cloud empowers your team to create faster, safer and more innovative products:
- Removes constraints to rapid innovation
The quicker features get to users and the faster their feedback is received—the faster ideas can be turned into customer-pleasing reality.
- Brings you closer to the user
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.
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!
- 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.
These advantages mean that you can try out new instance types, databases, tools, whatever you need with minimal cost, risk and effort.
The cloud is event-based by default.
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.
- 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.
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.