11. How do you move away from the management console?
In this episode, Luciano and Eoin discuss the good and the bad of the AWS Management Console (a.k.a. the web console) and why you should consider migrating to Infrastructure as Code (IaC) as soon as possible, especially for your production applications.
In this episode we mentioned the following resources:
Hello everyone and welcome to another episode of AWS Bites, the weekly show where we try to answer interesting AWS questions in about five minutes. My name is Luciano and today I'm joined by Eoin and before we get into today's question I will kindly ask you to like and subscribe what we are doing so you can be notified every time we publish a new episode. So today's question is how do you move away from the management console that is the AWS web console? And before actually we try to answer that particular question, I would like to try to describe what are the pros and cons maybe of that web console and why maybe you might want to move away from that. What do you think Eoin?
Yeah, the AWS console is, you know, everybody has some difficulty with it, but it's actually really good for learning about AWS services for the most part because it gives you a visual representation. You can try things fairly quickly and it's just good for looking around, debugging, understanding what components things are made of. And if you're getting into AWS early on, it makes sense to do things that way because the other methods could be quite a bit daunting.
But when it comes to, you know, getting into production mode, it's not so great really because you want to have repeatable, probably immutable deployments, you know, where you can create a stack with all your code and your infrastructure and it's reproducible, it's deterministic, and it can be tracked in your source control. And then when you deploy it to the cloud, you've got predictability around what you have and then you can deploy it to multiple environments. You can destroy it and recreate it easily. And it makes change management and iterating on features a lot easier than if you're trying to remember what you did in the console the last time and what you've configured and what you've forgotten to configure and what you've tagged and what you haven't tagged. So that's what the problem with the console is. So if you're using the console, what are the alternatives you think that we could suggest to people?
Yeah, I think there are many alternatives. Like for sure you could use the command line interface with the AWS CLI. You can also use the SDK in any language of your choice. But I would argue that those are not really tools for infrastructure as code. Like at best you can do either some scripts or maybe if you need to create resources at runtime inside your application, you can use the SDK. But they are useful alternatives, but I don't think they solve the problem of infrastructure as code.
For those I would recommend definitely CloudFormation, which is kind of the canonical service in AWS to do infrastructure as code. And that one will allow you to, in a declarative language, express all the resources that you want in your stack and allows you to deploy them kind of atomically. If something goes bad, you have a rollback process that is going to bring it back to the previous version.
So all those cool things. Of course the choice is not limited to CloudFormation. Even AWS itself has things like CDK and SAM, which are somewhat higher level abstractions on top of CloudFormation. You also have the serverless framework as another alternative that you can use, especially if you are building serverless projects. And also there is something like Terraform that maybe you are using already, especially if you use other cloud providers.
And that tool can be useful because with the same tool you can manage different cloud providers. So yeah, definitely there is no shortage of options, even though my recommendation would be to eventually learn CloudFormation because that's kind of the golden rule in AWS. That's the lower level and chances are you would need to deal with CloudFormation directly at some point. So yeah, I suppose at this point it could be interesting to explore a use case where maybe you have a production application that was, let's say deployed by clicking in the UI and provisioning things manually. What could be a reasonable path to move from that particular deployment to managing this application with infrastructure as code?
Yeah, I think the use case is actually kind of more common than people would like to admit. It's probably a secret shame in having created a massive application using the console. But you know, people do it and people do it successfully. The question is how do you get out of it because it's not very sustainable. And I suppose the first thing is try to not mess with what you have. You know, if you've got something, some people call that like a snowflake infrastructure because it was created.
And once it's gone, it's gone, you can't really repeat it. It's completely unique. What you can do is just, I would recommend trying to create a replica of that in a new account rather than trying to transition a set of resources in one account over to infrastructure as code. Because it's very difficult to make all those changes without breaking anything. So it's actually a good opportunity to get your organization and your account structure in place.
Create a new set of accounts, start to build a replica of what you have and then switch over. And you could do that by, first problem is what do you have already, right? So you kind of need to audit all of your infrastructure and resources. You might have a good handle on that, but you could also use maybe AWS config to query all the resources or you can use third party tools for that. There's also AWS used to have a tool called Cloud former, which isn't really maintained and I wouldn't recommend it.
But there's an open source product called former two, which we can link in the notes and it seems to be really good. I haven't used it yet, but it looks pretty good at generating Terraform, HCL code or CloudFormation templates from your existing resources. So then once you build up those templates, you can deploy them, test them in this new account structure. And then you have to just do a cut over using say DNS at the front end, synchronizing and migrating your data at the backend. And it's not going to be an easy process, but it's something if you do take that approach, you can at least rehearse it, practice it multiple times. You could even have two production environments that are almost replicas, A, B test it and then cut over when you're confident.
That's great. Yeah. I think I want to mention another thing, which is that in CloudFormation, you can import existing resources, but that's kind of a tricky thing. It's probably not the right thing to do because when you import a resource and then you create a template, if you try to deploy that template to another environment or another account, it's going to try to import the same resource and it suspects the resource is already there.
So that's not going to work for you to generalize your stack. It's just kind of an escape hatch. If you already have things in production and then you are managing something with CloudFormation and you want to reference that particular resource, we are going to link an article in the notes on how you can do that with CDK, but again, this is not something you should do to fully migrate something from clicky-clicky to infrastructure as code.
It's more if you really have to use a resource that exists in a production environment, then you can import it that way. If you need to recreate in other environments, you can recreate, for instance, for testing reasons, but yeah, it's kind of a borderline approach. All right. I think that's all we have for today. So thank you very much for listening and we are really curious to know what you think about this episode if you have been through this journey of trying to migrate something that was done by clicking the UI to infrastructure as code and what kind of solution did you find in the end. So please share your experience with us. And if you have any question that you would like us to answer next time, then let us know and we'll try to do that. Thank you very much and we'll see you in the next episode. Bye.
Use the arrow keys to move between transcript segments, Home or End to jump to the first or last segment, and Enter to seek in the video.
Help us to make this transcription better! If you find an error, please submit a PR with your corrections.