|
1 | 1 | # Easy EKS (Pre-Alpha) |
2 | 2 |
|
3 | | -## What problem does this solve? |
4 | | -* EKS is a double-edged sword: |
5 | | - * Good: |
6 | | - * It simplifies the setup of a Kubernetes Cluster on AWS. |
7 | | - * It works great after it's set up. |
8 | | - * Bad: |
9 | | - * Set up is left to end users who have a high risk of setting it up poorly, taking months, or |
10 | | - both. |
11 | | - * It has a terrible FTUX (first time user experience) and OOTB (out of the box) UX (user |
12 | | - experience). |
13 | | -* Easy EKS is a solution to EKS's problems related to its slow and flawed set up process, FTUX, and |
14 | | - OOTB UX. |
15 | | - * https://www.reddit.com/r/aws/comments/qpw36d/aws_eks_rant/ |
16 | | - * https://www.reddit.com/r/devops/comments/y5am95/why_is_eks_and_aws_in_general_so_much_more/ |
17 | | - * https://matduggan.com/aws-eks/ |
18 | | - |
19 | 3 | ## What is Easy EKS? |
20 | | -* Easy EKS is a user experience optimized approach to EKS, where using it becomes `simpler`, `accessible`, and `enjoyable`. |
21 | | - |
22 | | -------------------------------------------------------------------------------------------------------- |
23 | | - |
24 | | -### Simpler EKS |
25 | | -1. **Deployment <u>and baseline configuration</u> are both automated:** |
26 | | - * `cdk` is used to automate the provisioning of production ready EKS Clusters. |
27 | | -2. **The administrative overhead associated with managing multiple clusters is minimized:** |
28 | | - * A `kustomize inspired` design pattern is used to make the deployment and management over time of multiple clusters much easier. |
29 | | -3. **Complexity is simplified, by shielding the end user engineers from unnecessary complexity that's practical to hide away:** |
30 | | - * A `helm inspired` design pattern to abstract away complexity. |
31 | | - * helm hides complexity in templatized yaml files, and helm values.yaml files, which represent sane default values of input parameters to feed into the templating engine. |
32 | | - * Here's an example of how helm allows end uesrs to see a significantly simplified interface: |
33 | | - * A 15 line long `kps.helm-values.yaml` file (of values representing overrides of |
34 | | - kube-prometheus-stack helm chart's default input parameters) |
35 | | - * With a command like `helm upgrade --install kps oci://registry-1.docker.io/bitnamicharts/kube-prometheus --version=9.6.2 --values=kps.helm-values.yaml --namespace=monitoring --create-namespace=true` |
36 | | - * Can deploy over 10,000 lines of yaml to a cluster. The complexity still exists, but it's |
37 | | - hidden, abstracted away, and replaced with a simplified interface for end users. |
38 | | - * Easy EKS hides it's complexity in: |
39 | | - * /lib/ (a cdk library) |
40 | | - * /.flox/ (a recommended, yet optional method of automating dev shell dependencies with `flox activate`) |
41 | | - * Easy EKS presents a simplified workflow to end users: |
42 | | - * Edit /config/ (which is an intuitive and simplified end user interface inspired by kustomize and helm values) |
43 | | - * `cdk list` |
44 | | - * `cdk deploy dev1-eks` |
45 | | - |
46 | | -------------------------------------------------------------------------------------------------------- |
47 | | - |
48 | | -### Accessible EKS |
49 | | -| **Accessibility Concerns** | **The following Common EKS Barriers** | **Are replaced with a streamlined happy path** | |
50 | | -|----------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| |
51 | | -| Learning how to deploy a Production Ready Cluster | Often takes `weeks` to learn the basics, `months` to become proficient. | Often takes `hours` to learn the basics, `days` to become proficient. | |
52 | | -| Installation Experience | It's like building a custom computer from parts, each potentially `needing research and troubleshooting`, then installing an OS. | It's like installing an OS on a `preassembled` computer. (Still work, but significantly less) | |
53 | | -| Installation Docs | EKS and components need to be installed, often `over 10 installation docs` are needed, and spread across AWS and multiple 3rd party repositories. | A bundled and automated installation allows for `more centralized installation docs`. | |
54 | | -| Prerequisite Knowledge | AWS's cdk based EKS Blueprints, can make things easier, but it `requires prior knowledge` of JavaScript, TypeScript, npm, and EKS Blueprints. It's also worth pointing out that `EKS Blueprints, is not a turn key automated platform`, it's the building blocks that could be used to build one. | Easy EKS is designed to prioritize FTUX (First Time User Experience), minimize cognitive complexity, be intuitive, and documented enough for those with `zero prior knowledge` to find it easy. | |
55 | | -| Successful adoption needs EKS specialists, which create staffing concerns. | It's not uncommon to dedicate at least 1 full-time engineer to managing "DevOps Yak Shaving" and "engineering toil heavy tasks" tasks associated with EKS. `Expensive Staff` Augmentation can set things up quick, Cheaper Engineers still end up being more expensive from needing more time or creating a patchwork that will need to be reworked. "Bus factor", job mobility, time off, and skillset bottlenecks are common concerns. | A standardized, easy to learn, free open source product allows staff to be more fungible. `Specialized Knowledge is still needed, but orders of magnitude less`, even a Jr Engineer could become proficient within a week, and wouldn't need to dedicate their time on low value toil tasks. | |
56 | | - |
57 | | -------------------------------------------------------------------------------------------------------- |
58 | | - |
59 | | -### Enjoyable EKS |
60 | | - |
61 | | -* User Experience is what makes cars enjoyable products. The same is true for Easy EKS. |
62 | | - * Cars have complexity, |
63 | | - * But it's the car maker that deals with the complexity. |
64 | | - * You the end user get a simplifed turn key user experience. |
65 | | - * It's designed to be intuitive, learning how to drive isn't hard. |
66 | | - * Easy EKS has complexity, |
67 | | - * But you will be shielded from the majority of the complexity, it's abstrated away where practical. |
68 | | - * `You get to enjoy a turn key, batteries included, production ready user experience`. |
69 | | - * It's designed to be intuitive, and even FTUX (first time user experience) and OUX (onboarding UX) |
70 | | - are prioritized to make it easy to learn. |
71 | | -* You can enjoy: |
72 | | - * Being able to get meaningful work done quick: |
73 | | - * Learn the basics within a day. |
74 | | - * Deploy a cluster in under an hour, with a production ready baseline configuration. |
75 | | - * Develop working proficiency in under a week. |
76 | | - * Not having to think through engineering toil: |
77 | | - * Instead of choices, that make engineer's stress over identifying the best chocie. |
78 | | - * You get an opinionated approach of wise decisions that are best for most people. |
79 | | - (They're sane well optimized defaults that can be overriden if needed.) |
80 | | - * opinionated with decisions made = standardized |
81 | | - * standardization is a pre-requisite for end to end automation. |
82 | | - * Being confident in your choice to use Easy EKS: |
83 | | - * Easy EKS was designed and automated by a platform engineer, with over 6 years of kubernetes |
84 | | - consulting experience. Who has been a senior architect, builder, IaC coder, and automation |
85 | | - engineer of over 5 built from scratch kubernetes platforms. |
86 | | - * ADR's (Architectural Decision Records) are available to verify reasoning behind all choices. |
87 | | - * This isn't just a platform that claims to follow best practices. |
88 | | - * It's a platform that includes justifications of why it's practices are best practices. |
89 | | - |
90 | | -------------------------------------------------------------------------------------------------------- |
91 | | - |
92 | | -## Why Easy EKS Exists |
93 | | -| **Basic Functionality you'd expect to see, for normal usage and production readiness:** | **GCP's GKE AutoPilot:**<br> (a point of reference of what good looks like) | **AWS EKS:**<br> (The default out of the box user experience is a collection of dumb problems to have) | **Easy EKS** <br> (Smart solutions to dumb problems that make EKS easier, brought to you by doit.com) | |
94 | | -|-----------------------------------------------------------------------------------------|-----------------------------------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| |
95 | | -| A well configured VPC | Default VPC ships with Cloud NAT | Default VPC doesn't ship with a NAT GW, and Managed NAT GW is so bad [(link 1)](https://www.lastweekinaws.com/blog/the-aws-managed-nat-gateway-is-unpleasant-and-not-recommended/), that fck-NAT exists [(link 2)](https://fck-nat.dev/stable/). | Ships with fck-NAT (order of magnitude cheaper), and dualstack VPC for IPv6 based EKS, which eliminates potential problem of running out of IPs. | |
96 | | -| Optimized DNS | DNS is optimized by default via Node Local DNS Cache and Cloud DNS | Ships with nothing. A relatively easy install won't be Fault Tolerant, won't have a dns auto-scaler, nor node-local-dns-cache. Figuring out production grade optimizations takes days. | Alpha ships with Node Local DNS Cache, core dns autoscaler, and anti affinity rules for increased fault tolerance.<br> Planned for Beta: verify/optimize core dns autoscaler's config. | |
97 | | -| Easily populate ~/.kube/config for Kubectl Access | A blue connect button at the top of the Web GUI, shows a command. | Access tends to be a multistep process, so you look up docs for something that should be trivially easy. | When cdk eks blueprints finishes, it outputs a config command. | |
98 | | -| Teammates can easily access to kubectl and Web Console | GCP IAM roles map to GKE's rbac rights by default. | In general, access needs to be explicitly configured per cluster, nuanced limitations make it hard. | Pragmatic workarounds to access limitations are set by default to make access easier. | |
99 | | -| Metric Level Observability | Ships with preconfigured working dashboards | Ships with nothing, figuring out how to set up takes days. | PLANNED (alpha) | |
100 | | -| Log Level Observability | Ships with intuitive centralized logging | Ships with nothing, figuring out how to set up takes days. | PLANNED (alpha) | |
101 | | -| Automatically Provisions storage for stateful workloads | Ships with a preconfigured storageclass | Ships with broken implementation, fixing is relatively easy, but how/why is this not a default functionality baked into the platform? | Ships with KMS Encrypted EBS storageclass | |
102 | | -| Automatically Provision Load Balancers for Ingress | Ships with GKE Ingress Controller and GKE's Gateway API controller | Ships with nothing, and the solution: AWS Load Balancer Controller, is considered a 3rd party add-on, with a complex installation that can take days to figure out. | Ships with AWS Load Balancer Controller | |
103 | | -| Pod Level IAM Identity | Ships with Workload Identity (pod level IAM roles) | Ships with nothing, making it work is relatively easy, seems reasonable to have this be a default baked into the platform. | Ships with Amazon EKS Pod Identity Agent | |
104 | | -| Worker Node Autoscaling | Ships with NAP (Node Auto Provisioner) | Ships with nothing, figuring out how to install cluster autoscaler or karpenter.sh can take days. | Ships with Karpenter.sh (Note: currently an outdated version to avoid compatibility issues, waiting for Karpenter 1.2.x / stable version planned for alpha) | |
105 | | - |
106 | | -------------------------------------------------------------------------------------------------------- |
107 | | - |
108 | | -## How do I get started? |
109 | | -[Check the docs page](/docs) |
| 4 | +An opinionated bundling of automation & Infrastructure as code that aims to: |
| 5 | +1. Make it easy to provision EKS clusters that are production ready by default. |
| 6 | +2. Maintain a heavily standardized opinionated set of IaC, which makes automation easier. |
| 7 | +3. Apply a helm like design pattern to AWS CDK. |
| 8 | + |
| 9 | +## What is the current status of Easy EKS? |
| 10 | +Pre-Alpha |
| 11 | +* Most remaining breaking changes are likely to be variable renames. |
| 12 | +* There are multiple production readiness goals that have not yet been met. |
| 13 | +* Upgrade paths and everyday usage aren't well tested. |
| 14 | + |
| 15 | +## If you're interested in trying it: |
| 16 | +1. Try the quickstart |
| 17 | +2. If you want to adopt it fork |
| 18 | + |
| 19 | +## How do I get started / use it? |
| 20 | +1. Try the [quickstart](./docs/03_Quickstart/Quickstart.md) |
| 21 | +2. Fork the repo for long term usage. |
0 commit comments