<?xml version="1.0" encoding="UTF-8"?><rss version="2.0" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>paas &amp;mdash; A Bit</title>
    <link>https://baez.link/tag:paas</link>
    <description>A little bit of writing by Alejandro </description>
    <pubDate>Tue, 14 Apr 2026 16:22:57 +0000</pubDate>
    <item>
      <title>The A-Z Stack</title>
      <link>https://baez.link/the-a-z-stack?pk_campaign=rss-feed</link>
      <description>&lt;![CDATA[Let&#39;s say you wanted to write your own application platform from scratch in the modern workflow. &#xA;&#xA;!--more--&#xA;&#xA;Not too long ago Kelsey Hightower posted a tweet about what you may require to run an application platform. While his list may look large, it&#39;s not all encompassing. It&#39;s just an example of how ridiculous our abstractions have gotten. Even taking one or two service on each category in the landscape.cncf.io page, would not give the full list of dependencies. So I started thinking. What would a full encompassing list of the &#39;recommended stack&#39; look like?&#xA;&#xA;I&#39;ve been running a few posts now on striking a balance between what you do to run your software in a sustainable and manageable way. This post is not that. The design here is the A-Z stack. A platform of everything I could think of, from on top of my head, you may need for a modern application platform. Please don&#39;t try to implement the stack here at work. If you already have, I&#39;m sorry and I know your pain. There&#39;s consoling we can probably get for our insanity. &#xA;&#xA;First, you need a cloud provider. If we want to be realistic, this would certainly be AWS. A high chance you and your team are already AWS Architects with decades of experience collectively. &#xA;&#xA;Next, you need an infrastructure as code software. The list can get quite large here on implementation. For the purpose of the A-Z stack list, let&#39;s just say you use Hashicorp&#39;s Terraform. With a team of N   1, you most certainly will be working on the code in terraform together. In other words, you need two parts to make terraform work properly here. One, you must be using version control. The famous single options are git and github. The second part is you need to have a backend that&#39;s not local for your terraform state. Since we using AWS, might as well use S3 with DynamoDB for state locking. &#xA;&#xA;With your cloud provider and IaC ready, the next section is the OS. You should be running Linux, let&#39;s say CentOS. Make sure you have SELinux enabled and actually enforcing here. While the trend is to disable, don&#39;t. There are too many reasons to count why not. If you doing it to be fast, you are hurting yourself and your company far more later down the road. Moreover the OS security, you need something to actually provision the Linux of choice. Let&#39;s stay with Red Hat and go with Ansible. The provisioning alone can be its own series on lists of things you need, but we&#39;ll just keep it as is.&#xA;&#xA;Ok, here we go with the container orchestrator. Sticking to the norm and the standard being Red Hat, let&#39;s say openshift. Openshift comes with a lot of batteries included, so the list would be much larger with what isn&#39;t set by default. However, for peace of mind, bringing up cri-o for CRI, Flannel for CNI, and CoreDNS for service discovery. For CSI here means probably Ceph with Rook. Secret management is a must and should be Vault.  &#xA;&#xA;Now comes networking. Already gave Flannel for CNI and CoreDNS, but you still need an ingress controller. The popular one here would probably be ambassador. Don&#39;t forget your services in this platform need to be able to communicate with one another. That means a service mesh is necessary. Here I&#39;m going to cheat and use Linkerd. By cheat, I mean it covers the service proxy sidecar and the controller. Otherwise, we most certainly would then have to add Envoy. However, if your service does have proxy requirements not covered by the  linkered sidecar, then Envoy is still required. &#xA;&#xA;Here comes the home stretch! The actual application requirements. First is the Container registry, harbor. With it comes, Notary and Clair for build image security. Next, you need the deployments to Kubernetes using something structured like Helm. If not already brought up before, you need a key value store like etcd. You also need a CI/CD solution for your applications. So staying with the trends, Argo would suffice. Don&#39;t forget to monitor your application and platform. Most likely means Prometheus for metrics, Loki for logs, and Jaeger for tracing.&#xA;&#xA;Now you can finally begin to write your application. Just so the point is made clear, here&#39;s the list of all that you must know, like the creators of the software themselves, to get this type of modern day application platform working:&#xA;&#xA;Cloud Provider : AWS&#xA;IaC : Terraform&#xA;Version Control: Git&#xA;Version Control Host: Github&#xA;S3 and dynamodb for state locking on terraform&#xA;Linux Distribution: CentOS&#xA;SELinux enabled and enforcing&#xA;Linux Provisioner: Ansible&#xA;Container Orchestrator: Kubernetes, Openshift&#xA;10. CRI: CRI-O&#xA;11. CNI: Flannel&#xA;12. Service Discovery: CoreDNS&#xA;12. CSI: Ceph with Rook&#xA;13. Secret Management: Vault&#xA;14. Ingress Controller: Ambassador&#xA;15. Service Mesh: Linkerd&#xA;16. Service Proxy: Envoy&#xA;17. Container Registry: Harbor&#xA;18. Version Security Management: Notary&#xA;19. Build container image security: Clair&#xA;20. Kubernetes deployment: Helm&#xA;21. Key Value store: etcd&#xA;22. Continuous Integration and Delivery: Argo&#xA;23. Metrics Observability: Prometheus&#xA;24. Logs Observability: Loki&#xA;25. Tracing Observability: Jaeger &#xA; &#xA;&#xA;#100DaysToOffload #Day12 #Kubernetes #PaaS &#xA;&#xA;[1]: https://twitter.com/kelseyhightower/status/1245886920443363329&#xA;[2]: https://landscape.cncf.io/&#xA;[3]: https://baez.link/tag:StrikingABalance&#xA;[4]: https://www.digitalocean.com/&#xA;[5]: https://www.digitalocean.com/&#xA;[6]: https://www.terraform.io/&#xA;[7]: https://git-scm.com/&#xA;[8]: https://github.com/&#xA;[9]: https://www.terraform.io/docs/backends/types/index.html&#xA;[10]: https://www.terraform.io/docs/backends/state.html&#xA;[11]: https://www.terraform.io/docs/backends/types/s3.html&#xA;[12]: https://www.centos.org/&#xA;[13]: https://selinuxproject.org/page/Main_Page&#xA;[14]: https://www.ansible.com/&#xA;[15]: https://www.openshift.com/&#xA;[16]: https://cri-o.io/&#xA;[17]: https://github.com/coreos/flannel&#xA;[18]: https://rook.io/&#xA;[19]: https://www.vaultproject.io/&#xA;[20]: https://coredns.io/&#xA;[21]: https://www.getambassador.io/&#xA;[22]: https://linkerd.io/&#xA;[23]: https://www.envoyproxy.io/&#xA;[24]: https://goharbor.io/&#xA;[25]: https://coreos.com/clair/docs/latest/&#xA;[26]: https://github.com/theupdateframework/notary&#xA;[27]: https://helm.sh/&#xA;[28]: https://github.com/etcd-io&#xA;[29]: https://argoproj.github.io/&#xA;[30]: https://prometheus.io/&#xA;[31]: https://grafana.com/oss/loki/]]&gt;</description>
      <content:encoded><![CDATA[<p>Let&#39;s say you wanted to write your own application platform from scratch in the modern workflow.</p>



<p>Not too long ago Kelsey Hightower posted a tweet about what you may require to run an <a href="https://twitter.com/kelseyhightower/status/1245886920443363329">application platform</a>. While his list may look large, it&#39;s not all encompassing. It&#39;s just an example of how ridiculous our abstractions have gotten. Even taking one or two service on each category in the <a href="https://landscape.cncf.io/">landscape.cncf.io page</a>, would not give the full list of dependencies. So I started thinking. What would a full encompassing list of the &#39;recommended stack&#39; look like?</p>

<p>I&#39;ve been running a few posts now on <a href="https://baez.link/tag:StrikingABalance">striking a balance</a> between what you do to run your software in a sustainable and manageable way. This post is <strong>not</strong> that. The design here is the A-Z stack. A platform of everything I could think of, from on top of my head, you may need for a modern application platform. Please don&#39;t try to implement the stack here at work. If you already have, I&#39;m sorry and I know your pain. There&#39;s consoling we can probably get for our insanity.</p>

<p>First, you need a cloud provider. If we want to be realistic, this would certainly be AWS. A high chance you and your team are already AWS Architects with decades of experience collectively.</p>

<p>Next, you need an infrastructure as code software. The list can get quite large here on implementation. For the purpose of the A-Z stack list, let&#39;s just say you use Hashicorp&#39;s <a href="https://www.terraform.io/">Terraform</a>. With a team of <code>N &gt; 1</code>, you most certainly will be working on the code in terraform together. In other words, you need two parts to make terraform work properly here. One, you must be using version control. The famous single options are <a href="https://git-scm.com/">git</a> and <a href="https://github.com/">github</a>. The second part is you need to have a <a href="https://www.terraform.io/docs/backends/state.html">backend that&#39;s not local</a> for your <a href="https://www.terraform.io/docs/backends/types/index.html">terraform state</a>. Since we using AWS, might as well use <a href="https://www.terraform.io/docs/backends/types/s3.html">S3 with DynamoDB</a> for state locking.</p>

<p>With your cloud provider and IaC ready, the next section is the OS. You should be running Linux, let&#39;s say <a href="https://www.centos.org/">CentOS</a>. Make sure you have SELinux enabled and actually enforcing here. While the trend is to disable, don&#39;t. There are too many reasons to count why not. If you doing it to be fast, you are hurting yourself and your company far more later down the road. Moreover the OS security, you need something to actually provision the Linux of choice. Let&#39;s stay with Red Hat and go with <a href="https://www.ansible.com/">Ansible</a>. The provisioning alone can be its own series on lists of things you need, but we&#39;ll just keep it as is.</p>

<p>Ok, here we go with the container orchestrator. Sticking to the norm and the standard being Red Hat, let&#39;s say <a href="https://www.openshift.com/">openshift</a>. Openshift comes with a lot of batteries included, so the list would be much larger with what isn&#39;t set by default. However, for peace of mind, bringing up <a href="https://cri-o.io/">cri-o</a> for CRI, <a href="https://github.com/coreos/flannel">Flannel</a> for CNI, and <a href="https://coredns.io/">CoreDNS</a> for service discovery. For CSI here means probably <a href="https://rook.io/">Ceph with Rook</a>. Secret management is a must and should be <a href="https://www.vaultproject.io/">Vault</a>.</p>

<p>Now comes networking. Already gave <a href="https://github.com/coreos/flannel">Flannel</a> for CNI and <a href="https://coredns.io/">CoreDNS</a>, but you still need an ingress controller. The popular one here would probably be <a href="https://www.getambassador.io/">ambassador</a>. Don&#39;t forget your services in this platform need to be able to communicate with one another. That means a service mesh is necessary. Here I&#39;m going to cheat and use <a href="https://linkerd.io/">Linkerd</a>. By cheat, I mean it covers the service proxy sidecar and the controller. Otherwise, we most certainly would then have to add <a href="https://www.envoyproxy.io/">Envoy</a>. However, if your service does have proxy requirements not covered by the  linkered sidecar, then Envoy is still required.</p>

<p>Here comes the home stretch! The actual application requirements. First is the Container registry, <a href="https://goharbor.io/">harbor</a>. With it comes, <a href="https://coreos.com/clair/docs/latest/">Notary</a> and <a href="https://github.com/theupdateframework/notary">Clair</a> for build image security. Next, you need the deployments to Kubernetes using something structured like <a href="https://helm.sh/">Helm</a>. If not already brought up before, you need a key value store like <a href="https://github.com/etcd-io">etcd</a>. You also need a CI/CD solution for your applications. So staying with the trends, <a href="https://argoproj.github.io/">Argo</a> would suffice. Don&#39;t forget to monitor your application and platform. Most likely means <a href="https://prometheus.io/">Prometheus</a> for metrics, <a href="https://grafana.com/oss/loki/">Loki</a> for logs, and <a href="https://www.jaegertracing.io/">Jaeger</a> for tracing.</p>

<p>Now you can finally begin to write your application. Just so the point is made clear, here&#39;s the list of all that you must know, like the creators of the software themselves, to get this type of modern day application platform working:</p>
<ol><li>Cloud Provider : AWS</li>
<li>IaC : <a href="https://www.terraform.io/">Terraform</a></li>
<li>Version Control: <a href="https://git-scm.com/">Git</a></li>
<li>Version Control Host: <a href="https://github.com/">Github</a></li>
<li><a href="https://www.terraform.io/docs/backends/types/s3.html">S3 and dynamodb for state locking on terraform</a></li>
<li>Linux Distribution: <a href="https://www.centos.org/">CentOS</a></li>
<li><a href="https://selinuxproject.org/page/Main_Page">SELinux enabled and enforcing</a></li>
<li>Linux Provisioner: <a href="https://www.ansible.com/">Ansible</a></li>
<li>Container Orchestrator: Kubernetes, <a href="https://www.openshift.com/">Openshift</a></li>
<li>CRI: <a href="https://cri-o.io/">CRI-O</a></li>
<li>CNI: <a href="https://github.com/coreos/flannel">Flannel</a></li>
<li>Service Discovery: <a href="https://coredns.io/">CoreDNS</a></li>
<li>CSI: <a href="https://rook.io/">Ceph with Rook</a></li>
<li>Secret Management: <a href="https://www.vaultproject.io/">Vault</a></li>
<li>Ingress Controller: <a href="https://www.getambassador.io/">Ambassador</a></li>
<li>Service Mesh: <a href="https://linkerd.io/">Linkerd</a></li>
<li>Service Proxy: <a href="https://www.envoyproxy.io/">Envoy</a></li>
<li>Container Registry: <a href="https://goharbor.io/">Harbor</a></li>
<li>Version Security Management: <a href="https://github.com/theupdateframework/notary">Notary</a></li>
<li>Build container image security: <a href="https://coreos.com/clair/docs/latest/">Clair</a></li>
<li>Kubernetes deployment: <a href="https://helm.sh/">Helm</a></li>
<li>Key Value store: <a href="https://github.com/etcd-io">etcd</a></li>
<li>Continuous Integration and Delivery: <a href="https://argoproj.github.io/">Argo</a></li>
<li>Metrics Observability: <a href="https://prometheus.io/">Prometheus</a></li>
<li>Logs Observability: <a href="https://grafana.com/oss/loki/">Loki</a></li>
<li>Tracing Observability: <a href="https://www.jaegertracing.io/">Jaeger</a></li></ol>

<p><a href="https://baez.link/tag:100DaysToOffload" class="hashtag"><span>#</span><span class="p-category">100DaysToOffload</span></a> <a href="https://baez.link/tag:Day12" class="hashtag"><span>#</span><span class="p-category">Day12</span></a> <a href="https://baez.link/tag:Kubernetes" class="hashtag"><span>#</span><span class="p-category">Kubernetes</span></a> <a href="https://baez.link/tag:PaaS" class="hashtag"><span>#</span><span class="p-category">PaaS</span></a></p>
]]></content:encoded>
      <guid>https://baez.link/the-a-z-stack</guid>
      <pubDate>Sun, 10 May 2020 04:14:04 +0000</pubDate>
    </item>
  </channel>
</rss>