Infrastructure as Code (IaC) is not a choice anymore in cloud, it is rather being the de-facto. There are mainly three areas of code in this sense.
Having EKS cluster requires you to also control complex infrastructure configuration such as VPC setting, security groups, and IAM roles and policies. It gets even crazier when you expand to another region or to another account in AWS cloud.
After you define the infrastructure part, it’s not the end! There are bunch of other things that you need to take care on Kubernetes. They are not necessarily related to the application layer directly, but it’s more of building the environment. It could be Namespaces, RBAC, ClusterAutoscaler or monitoring tools.
It depends on the organizational priority when it comes to who would cover the deployment of application part to kubernetes. However deployment script and k8s manifest are uncontroversially codes as well, which we would need to take good care.
Model it all
Modelling your entire infrastructure and application resources provides a single source of truth for all your resources and helps you to standardize infrastructure components used across your organization, enabling configuration compliance and faster troubleshooting.
Automate & deploy
It allows you to build and rebuild your infrastructure and applications, without having to perform manual actions or write custom scripts. IaC engine (CDK, Cloudformation, Terraform…) takes care of determining the right operations to perform when managing your stack, orchestrating them in the most efficient way, and rolls back changes automatically if errors are detected. It would lead to less chance of human errors.
It’s just code
Codifying your infrastructure allows you to treat your infrastructure as just code. You can author it with any code editor, check it into a version control system, and review the files with team members before deploying into production. Also just like you do with your code, when things go wrong, you can just roll back to previous version and make the recovery process a lot easier.
We cover the three layers of Kubernetes cluster like the following.
In Lab 3, we will clone a sample application and deploy it in two different regions. We won’t actually write the application, however, it is definitely recommended to take a look into app structure.