Skip to content

Commit

Permalink
Clarification
Browse files Browse the repository at this point in the history
Signed-off-by: Bridget Kromhout <[email protected]>
  • Loading branch information
bridgetkromhout committed May 22, 2024
1 parent 020cda8 commit 67e169f
Showing 1 changed file with 1 addition and 1 deletion.
2 changes: 1 addition & 1 deletion blog/_posts/2024-05-21-aks-past-present-future.md
Original file line number Diff line number Diff line change
Expand Up @@ -21,7 +21,7 @@ It would be fair to say that the mission of providing a fully configured contain

So, it became clear that in order to better serve our users, our mission and direction had to evolve and focus. We needed a fully managed Kubernetes service that took care of bootstrapping, control plane and system component management, and simplified day-2 operations and developer experiences. Azure Kubernetes Service (AKS) was born as a result in October of 2017: a fully managed service where the control plane was fully hosted by Microsoft and the nodes ran in the user’s subscription. This enabled users to get compute from their existing quota, benefit from infrastructure reservations or saving plans, and integrate with existing infrastructure like hub and spoke architectures, while still being fully serviced by Microsoft. This allowed enterprises to meet their most complex requirements and transpose their architectures to AKS while benefitting from a modern cloud native platform.

At that time, the service was still very basic compared to what it is today. It only supported public clusters with no availability sets, no nodepools or autoscaling, no Windows containers, and a maximum of 100 nodes per cluster. It also lacked many features that are now considered essential, such as role-based access control, advanced networking, node repair, and cluster upgrades. Despite these limitations, AKS was still recognized as a huge leap forward from ACS and customer adoption was really fast. Users saw the value of having a fully managed Kubernetes service that integrated seamlessly with Azure and Microsoft tools. Plus, we quickly got to work delivering many of the key capabilities that our customers depend on today.
At that time, the service was still very basic compared to what it is today. It only supported public clusters with only one availability set, no nodepools or autoscaling, no Windows containers, and a maximum of 100 nodes per cluster. It also lacked many features that are now considered essential, such as role-based access control, advanced networking, node repair, and cluster upgrades. Despite these limitations, AKS was still recognized as a huge leap forward from ACS and customer adoption was really fast. Users saw the value of having a fully managed Kubernetes service that integrated seamlessly with Azure and Microsoft tools. Plus, we quickly got to work delivering many of the key capabilities that our customers depend on today.

## Present – Where we are today

Expand Down

0 comments on commit 67e169f

Please sign in to comment.