In a previous blog post I said I would provide an overview of how I structure the Cloud Native Applications that I build. As always with software, there are a ton of different ways to do this. My approach is only my approach, you might find something here that helps you or you might be offended by the way I do things.
I build Cloud Native applications. That is, I develop applications that run in the Cloud and leverage Cloud services. This means I write application code and deploy Cloud infrastructure. I believe there are exactly 1,034,343 ways to deploy Cloud infrastructure. There is a wide range of tools available from a variety of vendors that want to help you deploy your Cloud infrastructure and get it connected to your application.
More often than not, these days, deploying Cloud infrastructure means writing Infrastructure-as-Code. If you are still doing anything in the console we can’t be friends. I recently became aware of Ampt and the new (to me) concept of Infrastructure-from-Code (IfC). I’m really struggling with how I feel about it and thought I should try to solidify my feelings in a blog post.
The thing I really want to talk about is abstraction. That is, each of the 1,034,343 solutions that help build Cloud infrastructure provide a layer of abstraction on top of foundational ways to build Cloud infrastructure. This layer of abstraction is often titled towards a particular use case to make it easier to build the infrastructure that satisfies the use case. Some solutions are focused on declarative infrastructure, some on support for multiple clouds and some on building applications in the Cloud.