IfC-2023: Technology Landscape

Part Three: An “Isometric” View and Summary


  • Programming Language — is an IfC product based on an existing mainstream programming language(s) or embarks on developing a new one?
  • Runtime Environment — does it still use some existing runtime environment (e.g. Node.js)?
  • API — is it proprietary or some form of standard/open source? Cloud-specific or cloud-agnostic?
  • IDE — does it assume its proprietary, presumably cloud-based, Integrated Development Environment or could be integrated with one or more of existing IDEs?
  • Deployment — does it assume deployment applications/services to its own cloud account or produced artifacts could be deployed to the customer’s own cloud account?

Language and Runtime Environment Map

Table 1: IfC Language vs Runtime Environment Space
Fig. 1: IfC to Hexagonal Architecture Mapping

Concluding Remarks and Way Forward

Fig. 2: IfC Open-End Architecture

Messy Coherence

Connecting the Dots

  1. Decisions about programming language and runtime environment support appear to be having a major strategic impact. In particular, these two choices determine the potential level of interoperability with existing solutions/libraries.
  2. Decision about the nature of APIs exposed to application comes right after and to a large degree determines how particular IfC product is going to be used. Specifically, this choice determines the level of application code portability between different cloud platforms.
  3. Decisions about IDE and Deployment, while probably not having the same weight in terms of underlying technologies, have tremendous impact on the overall system usability, operational efficiency, security, strategic partnership, brand building, and cost.
  4. Decisions about which cloud services from which vendor to support in which order appear to be belonging to particular IfC product roadmap reflecting its business model and go to market strategy.
  5. Providing proper implementation for selected cloud resource acquisition and consumption seem to be required from the outset (m.b. with some small variations).
  6. Level of support for resource configuration and operation may vary depending on tactical considerations, but neglecting them for too long would incur substantial risk for any serious production deployment.
  7. Decisions about cloud vendor API level to be used determine primarily potential efficiency, implementation effort and, to some degree, the level of portability between different clouds for the IfC product itself.
  8. Considering the current stage of IfC technology evolution, decisions about supporting different deployment locations (for detailed discussion of this topic, look here) seem to be always limited to the core cloud platform (some IfC products are edge computing oriented from the very beginning) with gradual extension towards additional location options in the future.

Resolving the Teminology Conflicts

  1. In the previous series by API I understood cloud vendor API used for implementation of particular interaction with cloud service. In this series by API I understood the API exposed to the application code.
  2. In the previous series by Deployment Option I understood the deployment location option (e.g. central cloud, edge, etc.) for programming artifacts produced by the IfC product in question. In this series, by Deployment Option I understood the cloud account ownership for the IfC product itself and produced artifacts.

The Fin



Software technologist/architect; connecting dots across multiple disciplines; C-level mentoring

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Asher Sterkin

Software technologist/architect; connecting dots across multiple disciplines; C-level mentoring