[Azure] Your first Azure project
Although Azure is definitely not new any more, there are still a lot of developers, product owners, testers and other project members out there who have never seen it or worked with it. On the Azure projects I embark on, I notice that this is usually a difficulty, which surprised me at first. But there are repeating patterns and lessons to be learned here, so I’m hoping to address some of those with this blog post. Hope it helps!
- It’s a platform, not a feature
- It’s the cloud, Microsoft deals with security!
- We’re DevOps, we can manage
- I don’t understand it and therefore: Azure sucks!
1. It’s a platform, not a feature
Using Azure does not mean your problems are now all magically solved. Yet I come across a lot of people who at some point ask the slightly rhetorical question “But we’re using Azure, right? Doesn’t that mean we do not have to worry about this?”. This can apply to many different topics, which includes back-up and security.
The cloud comes in different forms and I’m sure that by now you probably know the different between Software-as-a-Service (Saas), Platform-as-a-Service (PaaS) and Infrastructure-as-a-Service (IaaS). When using PaaS or IaaS components you will need to still worry about these kinds of things. Heck, even when using SaaS you usually still have to think about these items. For example; you might be storing your documents in Office365, but for those really important documents you might want to consider having an offline back-up as well.
The same goes for Azure Storage. The redundancy features of Azure will provide you with a lot of resilience depending on which type of storage you select. But that mainly protects you from failures inside of the datacenter(s). It does not protect you from yourself deleting that important file or VM disk that was in there. And although Microsoft support might help you recover things in certain scenarios: please do not bet on that, but have a solution in place. These are just two examples, there’s more where these came from.
Lesson learned: simply consider the same stuff you would when designing an on-prem solution and be grateful when Azure already fulfills your needs with what is there in-the-box. Just don’t assume everything’s already taken care of.
Example cloud architecture (source)
2. It’s the cloud, Microsoft deals with security!
Microsoft does a tremendous job in keeping your data safe, there’s no denying that. In the time Azure existed, I have never read about any serious security issues that actually exposed customer data. That doesn’t bring any guarantees, but at least the track record is solid.
That said, your colleague (not you, obvisouly) can still make mistakes. He/she can use dumb passwords. He/she can expose your database to the Internet and by accident publish the connectionstring to it on GitHub. He/she can send a SAS storage token in an e-mail and forward that to the wrong customer. There’s tons of things that go wrong. And Microsoft won’t secure you from your own mistakes.
The cloud brings a new security perimeter with it. Instead of building a huge wall around a network, we shift towards building smaller walls instead for all components. But you still need to think about building those walls. Here’s a few questions you might want to consider:
- Do all of my components need to be accessible via the Internet? There’s pretty good ways of making them “internal” to your Azure virtual network, or limiting traffic using IP restrictions.
- Who needs access? Just adding every developer as resource group owner in your production environment might not be a good idea.
- What technology do you want to use for authentication and authorization? Azure AD can help you out there, but that as well requires planning. Especially in (but not limited to!) enterprise set-ups.
- Where do I store my passwords? Check out Azure Key Vault if you haven’t already!
Lesson learned: always think about security. It’s important. You’re storing data in a more sensitive place, even with Microsofts security in place. People make mistakes and your solution design should try to mitigate the risk of those.
Update; Microsoft released some new best practice guidance for Azure. Download it here.
3. We’re DevOps, we can manage
This one might be a bit controversial, I fully admit. But if I’m honest, I still have to meet the first team that does real DevOps in the way it’s written in the books. All team members are equally skilled, they run their software in production without needing any help and all the backlog tickets can be picked up by any team member. If you’re in such a team: good! You’re probably part of the 1% of teams that can do this. In the rest of the world though, people have their expertise and skill sets which usually do not align.
The (or: a) definition of DevOps (source)
Under the “DevOps” label, teams of developers tend to get quite some permissions within the environment. As I stated above already, maybe not what you want from a security perspective. But probably also not what you want from a management and maintenance perspective. Cause there’s a high chance that you’ll end up with the situation that operations folks in on-prem environments have been fighting for years. Something breaks and them team then relies on Pete, because Pete wrote that bit and he know where the log file is written. That’s all fine and well, until the day that Pete is on holiday or he left the company.
Now what does this have to do with Azure? Well in a lot of companies, Azure is not well understood by the operations people (yet). And so it becomes the domain of the developers and they get the permissions they need to facilitate this behavior. I myself am quite a fan of not having any permissions in the production environment. Use an automated pipeline to get the software in there, and use Application Insights or Log Analytics to get the information you need out of it. Maybe some read permissions on components, but that’s it. This forces the DevOps teams to think about this stuff and do it the right way, getting them on the path to success with a little bit of force applied 😉
Lesson learned: think about a good permission model. Keep it limited and keep it consistent. DevOps does not imply everyone needs to have god-mode access to everything.
4. I don’t understand it and therefore: Azure sucks!
It really baffles me how people start using a cloud platform like Azure without any proper training or education. I understand you might not have the luxury of time to do a full certification before your first project, but still. It’s quite a beast of a platform with thousands of options to chose from. And with great power, comes great responsibility, to quote that super corny quote once more.
So these people embark on their Azure journey without having the proper knowledge. And sure, the platform is pretty accessible and you can deploy your stuff literally in minutes. But that doesn’t mean that you truly understand how you can use it. And with Microsofts new inclusive attitude, these people might not even be coming from a Microsoft stack. These are Linux or Mac folks who run PHP, Ruby, Java or any other stack on the Azure platform. And when it doesn’t work the way they expect it to: it’s the crappy platform. It really never ever seems to be their fault. This is the Windows vs Linux vs Mac discussion all over again, and here I was thinking we we’re passed that by now. I was wrong.
Lesson learned: team members need to learn the platform before they start using it. Especially when they’re out of their normal comfort zones. If they do not have the required knowledge, they’ll fail and they’ll blame the platform for it. And if you have influenceable management, they might believe it. Who knows what will happen, but it’ll be based on false information unfortunately.
Conclusion
So those are four things I learned in the field. Even though Azure can offer an organization great things, it also comes with challenges. It definitely does not mean you do not have to think about things any more. So keep those brains running and don’t get lazy just because you’re finally in the cloud. Designing and building software solutions is a craft, and this is a new tool on your belt that takes time learning about.
Leave a Comment