A lot of companies have done the lift and shift into the cloud, but they can still be very reliant on virtual machine servers. From some of our own (internal) experience using cloud native technologies, I'll to try and provide some ideas and information about their implementation. What I've found is that once you start with cloud native services, it can then become very familiar to start leveraging others via similar methods. Here I'll be covering a bit about using some of these services in general, I'll also publish some other posts about specific services in some more detail.
Disclaimer: I understand that something like application modernisation can seem and even become a very large project, but I would still encourage you to explore some of these native services, as they can help make large complex systems, modular, more manageable and even open opportunities for interim migration solutions.
Image shows the five foundational pillars of cloud native
If you've not yet dabbled in cloud native services, some of your initial thoughts might include:
Some good:
- Cheap to get started (with some exceptions)
- Huge scalability
- Integrations with other cloud services
Some maybe more daunting:
- Do I need a developer to use them?
- How do I monitor and manage them?
- How do I use them securely?
- Integrations with other cloud services
- Where do I start to look for use-case opportunities?
I'll try to tackle some of these possibly more daunting points here with some general explanations.
Is a developer needed?
Hardly - there are obviously low/no-code options in Azure such as Logic Apps and Power Platform that can integrate with other native services. But even the code methods, if using something like function or container apps, have great templates available with a lot of triggers and bindings to other native services.
The Azure SDKs do a great job in making those triggers and bindings just a couple of lines of code so you can focus on the logic that might be needed. The SDK modules do a lot of the heavy lifting in the background even for scaling so you don't have to worry about much to implement something fairly robust.
The level of learning a person or team needs wouldn't be much different to that of other vendor specific technologies, if I think about systems like web filtering, endpoint NAC and encryption agents, next generation firewalls, even digital phone systems (thing of the past now).
In my opinion, the amount of learning, along with a fair amount of trial and error, that was required on technology solutions for these things is no more than for cloud native services. Plus, there is actually a lot more published content and help available for these more modern technologies. You can also get started for pretty much free, which is not something that can be said for some of those other solution types that would often have substantial licence costs. So with cloud services, you have everything to gain with minimal financial investment required.
Monitoring and management
Getting something working is one part of the challenge; next is then how to spot if a problem occurs. Luckily this is pretty simple within Azure. Once you understand the basic trigger and binding of the technology you've started using, these will have corresponding metrics that can be easily configured within an Azure Monitor rule. These are generally setting a static or dynamic (anomaly) threshold for when there is something getting stuck or happening when it shouldn't be, or vice-versa. From this you can notify and/or even trigger an action to maybe retry an operation.
Even if using code templates, the app hosting it will easily integrate with Application Insights, which also then has simple alert configuration options in Azure Monitor to capture when errors and exceptions occur. Then as a slightly more advanced step, apps can also have health checks that can be configured and used for more robust monitoring additionally.
Secure usage
When it comes to secure usage of Azure cloud native technologies, this mostly comes down to network access, storing secrets and using up-to-date versions of anything and everything that has versioning.
With networking, it can depend on environment rules you might have, or some industry regulatory requirements, or just based on the data you might be handling. You can use native services close to the usual default, which means the resources are usually accessible from the internet (still with authentication required). Or you can choose to virtual network integrate them, which usually requires a private endpoint (network card) for that resource to connect to the virtual network. Once you start networking with private endpoints, just like in traditional networking, you also need DNS for those virtual network integrated resources to resolve to their local IP addresses.
Integrating to virtual networking can increase costs. The networking and DNS is often low cost, but some cloud native technologies you are using might require you to leverage a more premium SKU to enable the virtual networking support. Also with the DNS, this is simple when using Azure native DNS, but if you have lifted and shifted and all of your cloud environment still refers to domain services on virtual machines, there are still some good solutions (like Private DNS Resolver) to quickly link the two. It could be that the solution you are implementing with cloud native technologies doesn't need to speak to your existing domain data and might not be required to connect to or be accessible internally from your existing network.
When it comes to networking, my recommendation is start with the default, get your solution working and tested, and then decide on if you want and need to network it. There is no need to get bogged down in this at the early stages. After all, cloud services are quick to deploy, so pivoting to making a networked version is not too big a task once you've identified value in the core solution.
Secret management is simple, most native services have a way to attach connections strings securely to them, or getting to grips with using key vaults is also not a difficult task, if you do start using key vaults, this can then enable you to fairly easily introduce automated rotation at a later stage to introduce some more robustness.
Additionally you will start to see that there are a lot of native options for adding layers of encryption in cloud services. Also, if you're already using Role-Based access, this is another layer you can introduce for access and even disable access key/connection string methods.
Service integration
When you start looking at cloud native services, it can seem a little daunting. You can feel like as soon as you're starting to learn one service, you quickly then need it to talk to another. But this is actually the power of cloud native services; once you become familiar with some of the common integrations such as access and networking, you'll find they are then repeatable between lots of services. But the key here is that you don't need to make a single service very complex or learn advanced features, you can just leverage other simple services to integrate and share the management load overall. So in my opinion, what starts out as a daunting aspect, quickly becomes a key benefit.
Getting started
The simple answer to this (from me) would be look at what you're using spreadsheets for currently. Where is the information coming from and then being leveraged by and for what purpose? If I think about a lot of solutions I have implemented using cloud native technologies, they have been things that previously lived in a large spreadsheet and have then generally expanded from there.
I would encourage you to explore these technologies. I'll be posting some information about specific services we frequently use. You can also talk to us at Advania, I'll be happy to answer questions or have a discussion.
There is one last thing to think about, which goes back to the spreadsheet example. Utilising services such as Azure cloud native technologies can be an introduction into different and better ways of working. However, once you achieve a small solution, try to resist then making tens or hundreds of things (like you might have done in the past with spreadsheets). Consider maybe an agile methodology where you make something simple and then evolve it, instead of making another ten duplicate simple things.