Kubernetes is very useful, there is no doubt about it. But if you are just starting with it or if you haven't used it for ages, there is tons of information to learn. Do you always have time to do it, especially if you don`t work with Kubernetes on a constant basis?
We at Mad Devs know about the issues. Even though Kubernetes offers amazing functionality, it is not always accessible so easily to those who aren't in it on a daily basis. So, our team has developed a boilerplate for basic AWS infrastructure with the EKS cluster.
We know that our boilerplate isn`t the only one available, so we did our best to develop it with the consideration of the main needs of users. If you have decided on this boilerplate, you can count on the following benefits:
- Infrastructure as Code (IaC): with Terraform, you get a smooth and efficient infrastructure. You don't need to write the same infrastructure code from scratch, just use the Terraform modules and customize them based on your needs. It is always updated to avoid outdated configurations.
- State management: Terraform saves the current infrastructure state. It means that further, you can review changes without applying them. You can also save the state remotely to work on the infrastructure in a team.
- Scalability and flexibility: if you build infrastructure on this boilerplate, you can be sure that it can be expanded or upgraded easily as soon as such a need arises.
- Comprehensiveness: along with the basic infrastructure, you get all the needed scaling and monitoring instruments. There is no need to implement any changes in the infrastructure manually. Just make the needed changes in Terraform and deploy them to AWS and Kubernetes.
- Control over resources: the application of Infrastructure as Code allows to prevent the waste of resources and make the entire infrastructure more observable.
- Clear documentation: the Terraform code becomes your project documentation. It means that if you add new team members, they will not find it difficult to learn about how the infrastructure works.
The set of benefits is astonishing, and if you have ever worked in Kubernetes, you know that these benefits move such work to a new level.
Now, you might be wondering for which projects this boilerplate works. We mean the project scale, load, and similar. We have used it for different projects on our own, among them were indeed large-scale and high-load projects. So, we can assure you that this boilerplate is absolutely safe and polished because we have been perfecting it for months. You can be sure that the results you get are secure, reliable, and safe to use.
You might prefer to build your own infrastructure like this. And yep, you will spend weeks working hard, making mistakes, correcting them. Another option is to rely on this boilerplate and get a positive result without wasting plenty of time. Why invent a bicycle if you can use it already?
Finally, you don't have to pay a single cent for using the boilerplate, it is absolutely free. We are happy to share the results of our work with anybody who needs it.
This repository contains the know-how of the Mad Devs team that can be efficiently applied for the rapid deployment of a Kubernetes cluster, the supporting services, and the underlying infrastructure in AWS. The main development and delivery tool is Terraform.
While performing our everyday tasks, we have tried many infrastructure solutions and have moved from on-premise hardware to serverless. Now, Kubernetes is our standard platform for application deployment. We do not insist on using Kubernetes and offer it only after the service architecture requirements are collected and analyzed. But 90% of our clients and their projects are hosted on AWS. as a Kubernetes platform, AWS EKS is used.
When you choose Kubernetes for your project, it makes almost no difference to the apps how the cluster is created. You can do it manually, through kops, or by using managed services offered by the cloud provider. The Kubernetes platform is the same everywhere.
The current boilerplate is still far from perfect. For example, we deploy services to the cluster by using Terraform which is pretty clumsy. It also contradicts the Kuber approach. But it is convenient because we convey IDs, ARNs, and other attributes to resources, and names to templates. From them, we generate values for the required charts within Terraform.
There are some more specific drawbacks. Say, the data “template_file” resources that we used for most templates are very uncomfortable for development and debugging. The number of tf.files is also questioned by many users. There is no doubt that this monolith shall be refactored and split into many micro-modules adopting the terragrunt approach. This is what we are going to do in the future.
Our boilerplate for basic AWS infrastructure with the EKS cluster facilitates the work of developers significantly. It is easy-to-use, provides the needed functionality, and can be customized based on the project needs and expectations. We are going to improve it in the future by addressing the drawbacks that are reported.
Previously published on the Mad Devs Blog.