In order to explain how we can do that using TypeScript, I have created a small CDK application.
Typescript scratchpad code#
In CDK, because you are working with a familiar high-level programming language, you can use familiar techniques to organize your infrastructure code as well. When you look at a thousand lines of infrastructure code stuffed into one TypeScript file, you have to ask yourself: how is this any different from a huge CloudFormation template, and can we do better? TypeScript to the rescue
The problem is that if you keep adding stuff there, you end up with an infrastructure monolith, which is ugly.
In CDK, it is convenient to define all your resources somewhere in a file that cdk init generates for you. In Azure, for example, you can have many ARM templates that can be deployed through a main template, and I see that as an acknowledgement that super-sized infrastructure templates are not fun to maintain. Note that cloud providers already support features to break things down into smaller chunks. If you don’t think about this, you end up with a template that would easily grow to thousands of lines, and your eyes will bleed every time you have to look at it. As we are creating more and more cloud infrastructure as code these days, it’s important to find ways to organize your infrastructure code in a way that reflects that thinking. The infrastructure monolithĪs an engineer you learn to break your problem down in smaller chunks, so that you can write solutions to those chunks in a way that your code reflects “single-responsibility” tendencies: one program (a class, a module or whatever) does one thing and does it well. It enables a high return on investment on your learning of TypeScript. But then, you would expect a modern serverless application to have less overhead than this! Given that, I find it absolutely magical that today on AWS you can use TypeScript for almost everything you need to do at any tier of your application, and for me CDK is one piece of the puzzle that supports that vision. For example, you could have a declarative style template for your cloud resources (whether it’s CloudFormation or ARM templates on Azure), backend logic in a language that your cloud provider supports in serverless style, and then whatever you are using on the front end (which probably will include JavaScript in some incarnation + HTML/CSS). Today, depending upon your technology choices for your serverless applications you could face similar situation. So you were switching between various languages and between declarative and procedural ways of thinking as you are working on your application. SQL Server) with loads of SQL stored procedures. NET days (I know, I am old), we had multi-layered web applications that would use JavaScript on the front-end, a VBScript layer of classic ASP, a backend layer written in VB6 or ATL based COM components, and an RDBMS (e.g.
Typescript scratchpad software#
It is essentially a high-level layer that can be used through a number of modern OO languages to create AWS resources.Īs a software engineer, one of the things that I always find annoying is the need to switch between various ways of writing code as you are working on different tiers of your application. AWS Cloud Development Kit (AWS CDK) is an open source Infrastructure-as-Code library for AWS.
0 kommentar(er)
