I recall on my very first periodic one to one meet with him, at my first software engineering job - I remember telling him, in a very convoluted and fragmented way, that I was struggling to build a mental model of things.
In hindsight, I didn't know know the concept of APIs when I first started, and more than half the things we build and/or use are APIs. Naturally, I was unable to imagine a mental model that helped me made sense of what I see on the job.
Back then, I work for Cloud Engineering. The main function of the team was to engineer a deployment platform which acts an abstract layer on top of the cloud providers in the industry that the bank was permitted to use.
In my opinion, the platform pre-dominantly acts as a control on how the bank can use various cloud services base on an established governance policy. Because it is controlled and hence limited options to tinker with for each service - convenience therefore becomes a by-product when using these services via the deployment platform, as compared to when interacting with the native cloud services.
My role was to engineer a supplementary application that supports the use of the deployment platform - to visualize and manage the deployed cloud resources at a governance and user level.
This is an internal web application with the following technology stack:
Language / Framework
Frontend - Typescript Angular
Backend - Java SpringBoot
Architecture Style
Both front and backend components are monoliths
Backend component adopted MVC pattern
Backend draws data indirectly by interacting with one of the AWS Serverless Lambda from the deployment platform which pulls data from a NoSQL data source
Authorization and Authentication
Communication between frontend and backend components is via REST. This is authenticated using JWT tokens.
User authentication and authorization at the frontend component is via Active Directory (i.e. LDAP Server).
Infrastructure
Compute - AWS ASG
File Storage - AWS S3
Data Storage - AWS DynamoDB
This might not be entirely correct. This was the first application I worked on and I barely knew enough to correctly identify their use in the stack, much less to categorize them.
What I did really miss and was fascinated about is how the context of the application was to support the use of the infrastructure itself. So by engineering the application to manage cloud resources - you inadvertently get exposure to how other applications uses the infrastructure in various manner.
Comments