This is the second and probably final post in this series. If you haven’t read the first post I would highly recommend it. When we last left our erstwhile heroes, they had successfully setup the Azure authentication method on a Vault server and created a policy associated with a role in the Azure auth method. The policy grants access to a key-value store called webkv. Now comes the fun part, how does an Azure VM go about using the Azure auth method to access the secrets stored in webkv? So glad you asked!
I am currently working on a Getting Started course for HashiCorp’s Vault product. There was a pretty cool demo I put together for using Azure AD as an authentication source for Vault, but unfortunately I had to cut it for sake of time. I didn’t want it to go to waste though; so I figured I’d write about it here instead. Here’s what we’re going to do. Use the Managed Service Identity feature in Azure to give an Azure VM permissions to access secrets in Vault. This is the sort of thing that could be applied to anything that can receive an MSI in Azure, including App Service, Functions, VMSS, and more!
I don’t believe in making New Year’s Resolutions. Or at least, I don’t believe in making the type of New Year’s Resolutions that you might typically think of. A grandiose resolution to achieve an overly ambitious goal in an unrealistic time-frame. Whether it’s resolving to start working out five days a week when you don’t work out at all, or losing 100 lbs. and keeping it off, or finally reading War & Peace. Those are all laudable goals, but setting your sights too high tends to end in failure. As in all things, moderation is key. I think it’s important to have a high-level goal, along with smaller milestones, and achievable tasks.
Let’s take running a marathon as an example. The high-level goal is to run a marathon. But if you just leave your house and try to run without any kind of plan or milestones, you’re probably going to stick with that plan for about a week. You have to set milestones, like being able to run a 5k in one month, a 10k in three months, a half-marathon in six months, etc. Then break those milestones into smaller goals, like run three times a week for the first month. Each of the activities, each run per se, is a task that has a purpose. In week 1 you might set a goal of running for 30 minutes each day, regardless of distance or speed. Breaking a monumental goal, like running a marathon, into something simple – running for 30 minutes – makes the entire process feel realistic. And each time you achieve your tiny goal, you get a sense of accomplishment. And if you track those accomplishments over the course of the high-level goal, you’ll be able to see real progress. Seeing that progress is a true motivator! How do I know? In 2012 I ran my first marathon, and this is exactly how I did it.
All of this is a VERY long-winded way of saying that I don’t believe in typical New Year’s Resolutions. I believe in setting goals, no matter what time of year it is, and creating a realistic plan to achieve those goals. That being said, the end of the year is an especially good time to reflect on what you accomplished in the previous year, and what goals you have in-flight for the next year. Having a well-defined moment in time to pursue internal reflection is necessary to staying on track or updating your plans to accommodate changes to your situation, and I don’t see any reason not to use the changing of the calendar year as such. The following items are goals that I have for 2019. Most of these goals are based on something that is already in-flight – remember, I don’t wait until January 1 to start a new project. I am going to try to provide some actionable tasks for each goal as well as metrics for success. Away we go!
If you were going to build a brand new application today, your approach would probably be fundamentally different than five or ten years ago. And I do mean fundamentally, as in the fundaments of the architecture would be different. In the last ten years we have moved rapidly from traditional three-tier applications to 12-factor apps using microservices, and now things are shifting again to serverless. That’s all well and good for any business looking to build a new application, but what about organizations that have traditional applications? I’ve also heard them called legacy or heritage applications. These applications are deeply ingrained in the business and are often what is actually generating the bulk of a company’s revenue. The company cannot survive without these applications, and modernizing them will be costly and fraught with risk. Due to the inherent risk, most companies opt to either keep these applications running on-premises or move them as-is to the public cloud, aka life and shift. That’s the reality we’re living with today, but tomorrow is knocking on the door and promising hybrid cloud to fix all this. What’s the reality and what’s the hype? And what is the most likely journey for most companies?
There was a recent article on CNBC talking about how AWS is creating new solutions that could potentially put existing companies out of business. That prompted a tweet from Matthew Prince about how if you are running your company on AWS, you are feeding them data about how to beat you. Prince is certainly not the first to make this leap of logic, and I am certain he won’t be the last. During the Microsoft Ignite Keynote this year, Satya Nadella said something similar about choosing a public cloud partner. Here’s the direct quote:
“If you’re dependent on a provider, who through some game theory construct, is providing you a commodity on one end, only to compete with you on another end. Then you could be making another strategic mistake.”
Is any of this true? Does is matter if you run your company on AWS or Azure? Is AWS or Amazon going to destroy your business? I have some thoughts.