Forem: Tomasz Fidecki

The cost of serverless application development on AWS: A Collector's Platform case study

Tomasz Fidecki — Wed, 27 Aug 2025 07:00:00 +0000

Serverless architecture represents a paradigm shift in deploying and managing applications. This approach not only alters the way companies design solutions but also significantly redefines the cost structure in cloud services.

Defining serverless computing

Serverless computing, contrary to what the name suggests, does not eliminate servers but abstracts their management from the users. It is a cloud-computing execution model where the cloud provider dynamically manages the allocation and provisioning of infrastructure and accompanying resources. Essentially, developers can build and run applications and services without the overhead of managing the infrastructure typically associated with computing. This distribution of responsibilities can influence and potentially reduce software development time.
In a classic architecture servers run continuously to allow the client to execute a query at any time. In contrast to this approach, serverless solutions do not generate any additional costs (except for data storage fees) during the absence of user activity. This makes it possible to reduce the cost of operating a server by up to several times, down to zero when application is not used.

Key Characteristics

Event-driven and Scalable - Serverless architectures are inherently event-driven. They are designed to respond to a variety of events, such as HTTP requests, database changes, or specific actions triggered by the user. This setup ensures automatic scaling, allowing the application to handle varying loads without manual intervention.
Micro-billing and Cost-effectiveness - one of the most appealing aspects of serverless computing is the 'pay-as-you-go' pricing model. Costs are based on the actual amount of resources consumed by an application, down to the function execution level, rather than on pre-purchased capacity.
Faster deployment and time to market - Serverless computing enables developers to focus solely on writing code and deploying functionalities, as the cloud provider manages the underlying infrastructure, scaling, and maintenance. This results in faster development cycles and a quicker time to market for new feature development.

Benefits

Serverless computing offers numerous benefits, including reduced operational costs, simplified scalability, and a focus on innovation rather than infrastructure management. It is particularly advantageous for applications with variable or unpredictable traffic, as it ensures efficient resource utilization. The adoption of serverless computing is growing rapidly across industries, driven by its ability to enable more agile and cost-effective cloud solutions.

Challenges

Despite its advantages, serverless computing also comes with challenges. These include concerns around vendor lock-in, limitations in runtime environments, and complexities in monitoring and debugging. Understanding these challenges is crucial for decision makers and architects considering adopting a serverless architecture.

Conclusion

In the following sections, we will delve into the specifics of serverless computing and explore how this model impacts the cost and efficiency of cloud-based applications, with a particular focus on our case study: a platform designed for collectors.

Building the Collectors' Platform with serverless application model

The Collectors' Platform, an exemplary application, is thoughtfully designed for hobbyists and enthusiasts. This section provides an overview of the platform's purpose, its key features, and the technical requirements needed to bring such a concept to life with a serverless paradigm.

Purpose of the platform

The Collectors' Platform is a virtual space where collectors from various domains can connect, showcase, and manage their collections. It serves as a hub for like-minded individuals to share their passions, exchange insights, and even discover rare items. From vintage stamps to contemporary art, this platform caters to a wide range of collecting interests.

Key features and technical requirements

We assume that the only actor in the designed system is the user, who should be able to perform the set of actions listed below.

Registration: allows users to create accounts using their Facebook, Google accounts, or email and password. Technical requirements: integration with OAuth for social media logins, secure database for storing user credentials, and encryption for data protection.
Login: provides users access to their accounts. Technical requirements: secure authentication process, session management, and possibly multi-factor authentication for enhanced security.
- Password reset: assists users in recovering their accounts. Technical requirements: email integration for password reset links, secure token generation, validation process and user interface to enable workflow.
Managing a network of friends: enables users to connect with other collectors. Technical requirements: friend request system, database to track connections, and real-time updates of friend lists.
Profile editing: allows users to personalize their profiles with personal information. Technical requirements: user interface for profile editing, database updates, and data validation.
Avatar photo: lets users upload and update their profile picture. Technical requirements: image upload capability, server-side processing for image resizing and storage.
Managing collections: users can add, edit, and delete their collections. Technical requirements: interface for managing collections, database support for storing collection details, image hosting for collection items.
Managing items in a collection: facilitates the addition, editing, and deletion of items within a collection. Technical requirements: detailed item description fields, image upload and management, and categorization features.
Viewing collections: allows users to view their own and others' collections. Technical requirements: gallery view, search and filter functions, and user access control for private collections.
Reacting to collections and items: enables users to interact with collections and items through likes, comments, or shares. Technical requirements: interactive elements for user engagement. For the sake of simplicity real-time communication is not used.

The Collectors' Platform, with its array of features, is designed to be a comprehensive solution for collectors to celebrate their passions. As we proceed, we will explore how serverless computing may support these features, particularly in terms of scalability, performance, and cost-effectiveness.

Serverless services used in the Collectors' Platform

In adopting a serverless architecture for the Collectors' Platform, various cloud services are employed to manage different aspects of the application. Each service plays a major role in ensuring the platform is scalable, efficient and user-friendly. Here, we focus on the key serverless services utilized in the platform, including AWS Lambda, Lambda@Edge, Amazon S3, Amazon API Gateway, Amazon DynamoDB, AWS Cognito and Amazon CloudFront.

Database

The core component of most systems is the database, which stores and handles user input. Designed platform will make use of DynamoDB service which is a fully managed cloud database. DynamoDB offers a NoSQL database service that handles the platform's data, including user profiles, collection details, and interaction records. It provides fast and predictable performance, seamless scalability, and is fully managed, which reduces the overhead of manual database administration.

Identity and access management

Another key element of today's systems is access management, specifically authentication and authorization. First is checking that the user is who they say they are, and latter is checking whether the user has the permissions to perform desired action. It might seem that delegating identity management to another provider is less secure than implementing and maintaining security systems yourself. However, this is not a true hypothesis, as creating an independent, mature and secure system on one's own would require a huge amount of time and labor, and consequently money. Leading companies are investing billions of dollars a year on cybersecurity. Therefore, it is usually much more secure and cheaper to use an off-the-shelf solution. In our design we will use AWS Cognito to simplify user sign-up, sign-in, and access control processes for the platform. It enhances security, scales to millions of users, and integrates easily with other AWS services, providing a comprehensive identity and access management solution.

File storage

Several functional requirements of the designed platform relate to binary files, especially images. To meet this requirement, one could use Amazon Simple Storage Service, known as Amazon S3, a highly scalable and secure file store capable of storing and processing petabytes of data. In this context Amazon S3 is utilized for storing user-uploaded content, including avatar photos and images of collection items. S3 offers high durability, availability, and scalability. It is an ideal solution for large-scale storage needs, ensuring data is safe and easily accessible.

Execution of business logic

In order to take advantage of the functionality of the platform, business logic must be implemented to properly handle the user requests. However, in order for the code to execute, you need some kind of computer to execute it - this is where the AWS Lambda service is used, which allows the cloud client to use the computing power running the code. Functions that can be run at any time are the essence of the serverless approach. Specifically, considering scalability, AWS Lambda provides as many computing resources as are needed to meet the application's requirements. In this scenario AWS Lambda handles the platform's backend processes, such as user authentication, database operations, and dynamic content generation.
In most of the cases cloud providers enable developers to execute the code created using various technology stacks e.g. Node.js, Python, Go or Java.
With AWS Lambda, the platform benefits from automatic scaling and only pays for the compute time consumed, contributing to significant cost savings and efficiency.

Authorization@Edge using cookies

When architecting Collectors’ Platform we are applied common accessibility patterns and best security practices. In order to protect Amazon CloudFront content from being downloaded by unauthenticated users we will use a solution that also uses Lambda@Edge and Cognito along with HTTP cookies. Using cookies provides transparent authentication to web apps, and also allows secure downloads of the platform content. With help comes a service Lambda@Edge which will set the cookies after sign-in and browsers automatically send the cookies on subsequent requests. Lambda@Edge extends the capabilities of AWS Lambda, allowing for function execution closer to the user's location by leveraging the AWS global network. This is particularly useful for customizing content delivered through Amazon CloudFront. It improves application performance by reducing latency, enhances user experience through personalized content delivery, and reduces the load on origin servers.

API Gateway for RESTful APIs

Amazon API Gateway acts as the front door for requests to the platform's backend services hosted on AWS Lambda and elsewhere. It provides efficient management of RESTful APIs, offers scalability, ensures security through various mechanisms, and handles traffic management, authorization, and access control.
Having implemented all of the services described above it is now possible to handle incoming requests from the users. For example to add an item to a user's collection the following workflow must be applied:

User request will be authorized by CloudFront and Cognito
API Gateway will invoke the addItem() function
Lambda will execute the addItem() function code
DynamoDB will store the new item in the database.
S3 will save the item image in the bucket.

Optimal cloud-based content delivery

Amazon CloudFront is a content delivery network (CDN) service that securely delivers data, images, applications, and APIs to users globally with low latency and high transfer speeds. By caching content at edge locations closest to users, it accelerates content delivery, reduces server load, and improves overall user experience. Collectors’ Platform architecture makes use of CloudFront in case of data delivery as well as web application that is an end user facing frontend. In addition this service provides capabilities in the area of cybersecurity providing protection against network and application layer attacks and SSL traffic termination.

Summary of services used

In summary, the Collectors' Platform leverages a combination of serverless services to create a robust, scalable, and cost-effective architecture. The combination of these serverless services provides a solid and reliable foundation for the Collectors' Platform. AWS Lambda and Lambda@Edge offer powerful compute capabilities, Amazon S3 and DynamoDB handle storage and database needs, AWS Cognito secures user authentication, while Amazon API Gateway and CloudFront ensure secure, efficient and fast content delivery. Together, these services create a seamless, scalable, and cost-effective serverless architecture for the platform.

Figure 1: Overview of Collectors’ Platform serverless architecture.

Cost analysis framework

Understanding the cost implications of serverless architecture is crucial for any platform, including applications like the Collectors' Platform. This section outlines a framework for analyzing and estimating the costs involved in a serverless environment, focusing on the unique aspects of serverless billing and cost optimization strategies.

Cost factors in serverless computing

Serverless computing introduces a different cost structure compared to traditional cloud services. The key factors affecting costs in a serverless environment include:

Compute time: costs are incurred based on the amount of compute time consumed by functions (e.g. AWS Lambda). This includes the execution time and the resources allocated to the function.
Number of requests: each request to serverless functions (e.g., Lambda invocations) is billed. High-frequency interactions can impact costs significantly.
Data transfer and storage: costs are associated with the amount of data stored (e.g., in Amazon S3) and transferred, especially when data moves across different regions or out of the AWS ecosystem.
Additional services: utilizing other AWS services, such as DynamoDB or API Gateway, adds to the cost based on their specific pricing models.

Methodology for cost analysis

To accurately estimate and analyze costs, the following approach is usually applied:

Identify and categorize usage: break down the platform's operations into distinct categories (e.g., user authentication, data storage, API calls, storage) to understand where costs are incurred.
Quantify resource utilization: assume or measure the usage of each service in terms of compute time, number of requests, and data storage/transfers.
Apply pricing models: using the specific pricing models of each AWS service, calculate the costs based on the assumed usage. Tools like AWS Pricing Calculator can support this analysis.
Include scaling considerations: factor in the scalability of serverless services, estimating costs for both average and peak loads.

Cost optimization strategies

Implementing cost optimization strategies can significantly reduce expenditures in a serverless environment. Key strategies to follow:

Efficient coding: optimize serverless function code to run faster and consume fewer resources. Reducing execution time directly lowers costs.
Resource allocation tuning: adjust the allocated resources for serverless functions (e.g., memory size for Lambda functions) to match the actual need, avoiding over-provisioning.
Caching strategy and mechanisms: implement caching (e.g., using Amazon CloudFront or DynamoDB Accelerator) to reduce the number of function invocations and database reads/writes.
Monitoring and alerts: Regularly monitor usage and set up alerts for unexpected spikes in usage or costs, enabling quick response to potential issues.

A thorough understanding of the cost factors, coupled with a strategic approach to analyzing and optimizing these costs, is essential for efficiently managing serverless expenses. By applying this framework, the Collectors' Platform can not only enjoy the benefits of serverless architecture but also maintain cost-effective operations. The next sections will explore a detailed cost analysis of the platform's specific features and offer insights into potential cost savings.
In the upcoming section, 'Detailed Cost Analysis,' we will delve deeper, applying this framework to present a granular breakdown of the Collectors' Platform's costs, offering a clear view of the financial landscape as we scale our serverless solution.

Detailed cost analysis

Building on our established framework, this section goes through a detailed cost analysis of the Collectors' Platform. We will examine the costs associated with each major feature of the platform, utilizing serverless computing, and highlight areas where costs can vary significantly.

User authentication (AWS Cognito, Lambda@Edge, CloudFront): Registration, login, and possible password reset features predominantly utilize AWS Cognito and Lambda functions. Cost factors are related to and arise from the number of user authentications, Lambda invocations for custom authentication flows, and data storage for user credentials. Considering the platform’s user base and frequency of authentication actions, we can estimate a monthly cost based on AWS Cognito's pricing for active users and Lambda’s per-invocation pricing model.
Social features (API Gateway, Lambda, DynamoDB): Features like friend network management, profile editing, and avatar management primarily use API Gateway, Lambda, and DynamoDB services. Costs are mainly driven by API calls, the execution time of Lambda functions for processing requests, and the storage and retrieval of data in DynamoDB. The cost is calculated based on the API Gateway request pricing, Lambda execution time and memory allocation, and DynamoDB’s read/write capacity units.
Collection management (Lambda, S3, DynamoDB): The management of collections, which includes adding, editing, and deleting collection information and images, primarily utilizes AWS Lambda for backend processing, Amazon S3 for image storage, and DynamoDB for data storage. The costs for this feature are based on the compute time used by Lambda functions, the storage space occupied in S3, and the read/write capacity and storage used in DynamoDB.
Item management within collections (Lambda, S3, DynamoDB): Managing individual items within collections involves similar services as collection management. Costs in this area are incurred due to Lambda executions for processing item-related actions, S3 for storing item images, and DynamoDB for maintaining item data. The estimated costs include charges for Lambda compute time, S3 storage, and DynamoDB’s usage.
Viewing collections (CloudFront, Lambda@Edge): Viewing collections and items efficiently uses Amazon CloudFront and Lambda@Edge. The costs for this feature arise from CloudFront data transfer and request handling, and Lambda@Edge for any edge computing needs. The cost estimation is based on the data transfer out rates of CloudFront and the number of Lambda@Edge requests, which helps in delivering content faster and more efficiently to users globally.
Interacting with collections and items (API Gateway, Lambda, DynamoDB): Interactions such as likes, comments and shares on collections and items are handled through API Gateway for request management, Lambda functions for executing the necessary backend processes, and DynamoDB for recording these interactions. The costs here are calculated based on the frequency and volume of user interactions, leading to charges for API Gateway requests, Lambda function executions, and DynamoDB read/write operations.

Variable vs fixed costs in serverless environments

In serverless environments, most costs are variable, scaling with the usage of the application. This is evident in the usage of Lambda, where costs are incurred per execution, API Gateway calls, and DynamoDB operations, which scale with the read/write requests. However, some costs are relatively fixed, such as the storage costs in S3 and a minimal baseline throughput in DynamoDB, providing a predictable element in the overall cost structure.

This detailed cost breakdown illustrates the various factors contributing to the operating expenses of the Collectors' Platform in a serverless architecture. It underscores the need for ongoing cost management and optimization strategies to maintain financial efficiency. The next section covers the details necessary to estimate the costs that make up a platform, providing a practical approach to financial planning in serverless architectures.

Estimated costs

Our journey through serverless architecture has highlighted the flexibility and efficiency it offers. However, it's crucial to translate these benefits into tangible cost implications to truly understand the economic impact. This chapter aims to demystify the cost structure of the Collectors' Platform by providing a granular view of the expenses based on assumed usage data.

We will examine each key component of the platform - ranging from user authentication to various data interactions - and present an itemized list of costs. This cost analysis will not only aid in comprehensively understanding the financial dynamics of serverless computing but also serve as a practical guide for budgeting and financial planning for similar projects. This will empower decision-makers, developers, and financial planners with the knowledge to make informed choices when selecting technology solutions.

Assumptions for cost estimation

To accurately estimate the costs associated with running the Collectors' Platform on a serverless architecture, it's essential to base calculations on realistic user activity assumptions. This section outlines the specific usage assumptions for a single user on a monthly basis. These assumptions will provide the foundation for a detailed cost breakdown.

User activity assumptions (per month):

Requests made: each user is assumed to make 300 requests to the platform. This includes actions like logging in, browsing collections, and interacting with items.
Data transfer:
- downloads: users are expected to download approximately 15MB of data. This might involve viewing high-resolution images of collection items or downloading collection details.
- uploads: on average, a user will upload about 1MB of data. This includes actions like updating profile information or adding new items to a collection.
Function invocations: users will trigger backend functions (e.g., AWS Lambda) leading to a total of 300 seconds of execution time and a total memory allocation of 30MB. This equates to 9 Gigabyte-seconds (GB-s) of compute time.
Database storage: each user is assumed to store data in a database with a total size of 1MB. This includes user profiles, collection details, and interaction records.
Database operations:
- Write capacity units (WCUs): each user is estimated to consume 30 write capacity units per month, reflecting the frequency of adding or updating data in the database.
- Read capacity units (RCUs): a consumption of 150 read capacity units is assumed for each user per month, indicating the frequency of data retrieval operations.
Image storage: users are expected to store images, such as avatars or collection items, with a total size of 10MB.

Activity	Assumption
Requests Made	300 requests
Data Downloads	15MB of data
Data Uploads	1MB of data
Function Invocations	Total duration of 300 seconds
	Total memory of 30MB
	Total of 9 Gigabyte-seconds (GB-s)
Database Storage	1MB of data
Database Operations	30 Write Capacity Units (WCUs)
	150 Read Capacity Units (RCUs)
Image Storage	10MB of data

These assumptions are crucial for a few key reasons:

Realism - they reflect typical user behavior and interactions within the platform, providing a realistic basis for cost estimation.
Scalability - understanding individual user costs helps in scaling these estimates to larger user bases.
Cost optimization - identifying the key areas of resource usage allows for targeted cost optimization strategies.

Calculations: understanding the cost components

In serverless architecture, especially in a diverse platform like the Collectors' Platform, the final bill is composed of various services and their respective pricing factors. Each service contributes to the overall cost based on its specific usage and pricing model. This section explores the variety of services utilized and the parameters that form the final cost calculation.

Breakdown of services and pricing factors

CloudFront
- Data transfer out to the Internet: the cost depends on the amount of data transferred out to the internet. CloudFront offers the first 1,024 GB/month for free, which is beneficial for platforms with moderate data transfer needs.
- Data transfer out to origin: charges are incurred for data transferred back to the origin server from CloudFront.
- Number of requests (HTTPS): CloudFront also bills based on the number of HTTPS requests, with the first 10 million requests per month being free.
AWS Lambda
- Number of requests: Lambda charges per request, making high-frequency actions a significant cost factor.
- Duration of each request: costs are calculated based on the execution duration of each function, measured in milliseconds.
- Amount of memory allocated: the allocated memory size for each function affects the cost, with higher memory allocations leading to higher charges.
- Amount of ephemeral storage allocated: the temporary storage used by a Lambda function also contributes to the cost.
Lambda@Edge
- Similar to AWS Lambda, Lambda@Edge charges are based on the number of requests, duration of each request, and the amount of memory allocated. The key difference is that Lambda@Edge runs closer to the user, reducing latency.
API Gateway
- HTTP APIs: charges for API Gateway are based on the number of HTTP API calls made.
- Average size of each request: the size of each API request can influence the cost, especially for data-rich applications.
Amazon DynamoDB
- Data storage size: DynamoDB charges for the amount of data stored, measured in GB.
- Average item size: the size of each item stored (including all attributes) affects the cost, especially for write and read operations.
- Number of writes and reads: DynamoDB's pricing model includes charges for read and write operations, which can be significant for platforms with heavy database interaction.
Amazon S3
- Standard storage: S3 charges for the amount of data stored in the standard storage class.
- Requests: costs are incurred for PUT, COPY, POST, LIST, GET, SELECT, and other requests.
- Data returned and scanned by S3 Select: using S3 Select for querying stored data incurs additional costs based on the amount of data returned and scanned.
- Data transfer: inbound data transfer to S3 is free, while outbound data transfer to Amazon CloudFront is also free, reducing costs for content delivery.
Amazon Cognito
- Number of Monthly Active Users (MAU): Cognito charges based on the number of MAUs.
- Advanced security features: utilizing advanced security features in Cognito incurs additional costs.
- SAML or OIDC Federation: additional charges apply for users who sign in through SAML or OIDC federation.

The cost calculation for the Collectors' Platform in a serverless environment is a complex process involving multiple services and varied pricing factors. Understanding these components is crucial for accurate budgeting and cost optimization. By analyzing each service's usage against its pricing model, we can derive a detailed and accurate estimate of the platform's operational costs.

The numbers: cost estimates for different user tiers

To provide a comprehensive understanding of the operational costs for the Collectors' Platform under the Serverless Application Model (SAM), we have calculated detailed estimates for five different user tiers: SAM-1k-U, SAM-10k-U, SAM-100k-U, SAM-1M-U, and SAM-10M-U. These tiers represent varying levels of user engagement, from 1,000 to 10,000,000 users, offering insights into how costs scale with the platform's growth. All calculations include always free tier limits for every service.

User Tier	CloudFront (USD)	Lambda (USD)	API Gateway (USD)	DynamoDB (USD)	S3 (USD)	Cognito (USD)	Monthly Total (USD)	Annual Cost (USD)
SAM-1k-U	0.01	0.74	0.33	0.34	0.77	0.00	2.19	26.28
SAM-10k-U	0.18	7.83	3.33	3.46	7.7	0.00	22.5	270
SAM-100k-U	66.3	135.89	33.3	34.66	77	275	622.15	7,465.8
SAM-1M-U	1,535.71	1,420.74	333	346.64	775.52	4,415	8,826.61	105,919.32
SAM-10M-U	13,786.08	14,269.28	3033	3,466.3	7,704	33,665	75,923.66	911,083.92

Table representing the estimated costs for the Collectors' Platform across different user tiers.

Observations and findings

The cost estimates for the Collectors' Platform across different user tiers reveal insightful patterns and implications about the scalability and economic aspects of serverless architecture. Here are the key observations and findings:

Scalability costs: as the user base grows from 1,000 to 10,000,000 users, there is a noticeable increase in costs across all services. This underscores a fundamental characteristic of serverless computing: while it offers scalability and flexibility, the costs associated with these benefits rise in tandem with increased usage.
Service-specific cost dynamics:
- CloudFront: the cost increases significantly at higher user tiers, reflecting the increased demand for content delivery and data transfer as the number of users grows.
- Lambda: the cost increment is steady and substantial, indicative of the growing computational needs associated with a larger user base.
- API Gateway: the cost growth here is notable, particularly at the highest tiers, highlighting the increased API interaction with a larger number of users.
- DynamoDB: similar to Lambda, the increase in costs is steady, reflecting the escalated database interaction and storage requirements.
- S3: the cost follows a rising trend, correlating with the increased data storage needs for user content.
- Cognito: initially, there is no cost, but as the platform scales up to 100,000 users and beyond, the cost becomes significant, emphasizing the importance of user authentication and security at scale.
Exponential growth in costs at higher tiers: while the costs for lower user tiers (1k and 10k users) are relatively modest, there is an exponential jump observed as the platform scales to 100k users and beyond. This jump is particularly evident in services like CloudFront and Cognito, reflecting the increased complexity and resource demand of a larger user base.
Economies of scale: despite the overall increase in costs, the per-user cost may decrease or the value derived per user may increase as the platform scales. This economy of scale is a crucial factor for platforms anticipating rapid user growth.
Importance of cost optimization: the analysis highlights the need for strategic cost optimization, especially for higher user tiers. Efficient use of resources, caching strategies, and optimizing serverless function executions can significantly control costs.
Budgeting and financial planning: the estimates provide a foundation for financial planning and budgeting. Companies can use this data to forecast expenses related to technology, plan resource allocation, and strategize for funding as the user base grows.

Deciphering the technology costs

The detailed cost analysis of the Collectors' Platform sheds light on the economic realities of serverless computing, particularly as it scales across various user tiers. One of the most striking aspects of deploying new technologies like serverless architectures is the often unpredictable nature of associated costs. While serverless computing offers remarkable scalability and operational flexibility, this analysis reveals that with these benefits come significant, and sometimes unforeseen, financial implications.

Key Findings:

The cost increases exponentially, especially as the platform scales to higher user tiers (100k to 10M users). This underscores the need for careful financial planning and resource management.
Services like CloudFront and Cognito, which initially seem cost-effective at lower scales, can lead to substantial expenses as the platform grows.
The analysis underscores the possible need for strategic cost optimization, especially on a larger scale. Effective resource utilization, implementing caching strategies, and optimizing serverless function executions are vital to controlling costs.

The uncertainty in technology costs, particularly in a field as dynamic as serverless computing, poses both challenges and opportunities. On one hand, companies must navigate these uncertainties, balancing technological advancement with financial viability. On the other hand, this unpredictability necessitates innovation in cost management and optimization strategies.

For businesses and developers venturing into serverless applications, this analysis serves as a reminder of the importance of continuous monitoring and adaptation. With the expansion of user base and the evolution of application demands, strategies for managing operational costs must also adapt and evolve. This proactive approach is key to harnessing the full potential of serverless computing while maintaining economic sustainability and efficiency.

In conclusion, while the costs associated with serverless technologies can be unpredictable, thorough analysis and strategic planning can provide a roadmap for navigating these uncertainties. By understanding and preparing for the potential financial impacts of scaling, organizations can make informed decisions that balance innovation with economic wisdom.

Conclusion

Selecting the right technology partner is a key decision that can significantly influence the success and efficiency of any serverless project. A knowledgeable and experienced partner brings to the table not just technical expertise, but also the foresight to make smart design decisions that are crucial for long-term sustainability. They can identify potential areas for optimization early in the development process, ensuring that the architecture is both cost-effective and scalable.

Good design decisions made in collaboration with a capable technology partner can lead to a more robust and adaptable serverless application. This approach minimizes the risk of encountering unforeseen costs and performance bottlenecks as the application scales. In essence, the right technology partner doesn't just aid in building a solution, they help in architecting a future-proof, scalable, and economically viable digital ecosystem.

Infrastructure pipelines: the core of Continuous Integration

Tomasz Fidecki — Tue, 26 Aug 2025 08:00:00 +0000

Modern software development focused on building the components faster and in a predictable manner requires seamless collaboration between the development and operations teams. When properly designed and executed it leads to a very efficient, flawless, and less exposed to vulnerabilities software, being at the same time a door opener for continuous deployments to various environments. DevOps, as a combination of engineering and best practices, builds competitive advantage and business value.

Keep things in tip-top shape

Nowadays with the great support from communities the role of open source software brings a high dynamic to a software development life cycle (SDLC). The code base is evolving fast and on a daily basis which brings the burden of having things always tied up. Hence, the automation of separate steps in the software development process takes on importance. These steps, often referred to as jobs, form a logical sequence of events leading to the final result. The sequence is named as a pipeline and a transportation medium for all the jobs executed along the way. The jobs, theirs results and the pipeline which acts as an umbrella defines the Continuous Integration (CI) practice. The integration of code changes along with the validation and testing may lead to deployment into the selected environment. This practice is named continuous Deployment (CD) and in some cases may be directly interconnected with a Continuous Integration forming the CI/CD practice. It starts from the tiniest change in the code base and ends with tangible changes in the observable environment.

Pipelines may have different purposes with varied complexity. Organized into stages containing jobs, pipelines create powerful concepts to automate processes and deployments - even without human intervention. Overall organizations may benefit from well designed automation in various ways. It may start from accelerated development, better code quality, stability and predictability and ends with contented customers receiving high quality products.

Infrastructure as Code

With the rise of cloud computing the infrastructure became the topic and control over it started to be as important as in any other piece in the software development process. It turned out that infrastructure may be thought of as a code and the same concepts may be applied. Once the management and provisioning of the infrastructure is performed through the code, manual handling is minimized or completely eliminated. At the same time it automatically brings the benefits of versioning and documenting while easing the process of traceability. Infrastructure may be subjected to the same rules that apply to the application source code. It means that it can be statically analyzed, validated and tested before merging to the concurrent versioning system. As in programming, the OOP paradigm can be applied here, allowing templating, modularization and automation finally. The latter may drastically improve software development efficiency through the elimination of need of manual provisioning and managing loose components that make up the whole infrastructure such as machine types, operating systems, attached storage, networking or even functions as a service. Having infrastructure defined declaratively (describing the intended goal and not separate steps) e.g. using Terraform, gives means to control the economic aspect of the venture. This means that with every iteration of infrastructure modification the costs may be estimated and compared with previous state to have a clear understanding of upcoming changes.

Infrastructure pipelines

Pipeline as top level component in Continuous Integration concept may be successfully utilized when infrastructure is being developed. As with a regular application code pipelines can be granular to build awareness whenever changes are aimed to be merged to a branch or it is required to apply changes into different deployment environments either fully- or semi-automated. These pipelines are often referred to as merge request pipelines.

Infrastructure merge request pipeline

This type of pipeline is triggered for execution whenever engineers are planning to commit the changes to any or selected branch. In case of infrastructural changes it is a good practice to have implemented stages that are validating, formatting and previewing changes planned to be introduced.
When Terraform is used as a tool to create and manage infrastructure as code then abovementioned pipeline stages are using command line interface and built-in commands. Once executed, the validate command validates all of the configuration files in a defined directory. It does not access any of the services but checks the completeness, consistency and overall correctness of the configuration. After validating the good and recommended practice is to automatically rewrite infrastructure configuration files to a canonical form and style. It is easily achievable with the Terraform fmt command which transforms files content to conform to the Terraform language style convention. This way the writing style is consistent and does not provide a basis for discussion during the code review phase. The last stage of the pipeline is to preview changes planned to be introduced to the infrastructure. Terraform’s plan command provides the possibility to read the current state, make comparisons with previous configuration and plan changes that are needed to achieve the desired state of the infrastructure. It is worth mentioning that using GitLab, information contained in merge request is presented in a convenient UI. The data consist of a brief summary of changes planned to be introduced to the infrastructure along with a link to the full execution plan.
Merge request pipeline for infrastructure may be expanded to various deployment environments such as development, staging and production to stay consistent while still introducing changes specific for each environment.

Infrastructure post merge request pipeline

This pipeline consists of several other stages to apply the intended changes to the deployment environments. Once fundamental changes were successfully checked in the merge request pipeline then infrastructure may be updated in fully- or semi-automated manner. Full automation is advisable/recommended when introducing changes to non-production environments due to the fact that the risk of exposing unwanted changes to the customers is usually low or non-existent. On the other hand, application of infrastructural changes to the production environment often requires full awareness, attention and controllable release management. Thus, such pipelines are created with the possibility to manually release changes to the production environment.

Continuing considering usage of Terraform tool the exemplary pipeline may be composed with the following stages:

Initialization: needed to properly initialize a working directory containing Terraform configuration files,
Plan: create an execution plan with changes that are to be introduced to the infrastructure. When building a pipeline it is beneficial to pass over the artifact with a plan to the next stage (Apply). This allows to avoid potential inconsistency in subsequent calls of the same command as well as the need to invoke this command again,
Apply: actual introduction of changes to the infrastructure. It is a good practice that the ‘Apply’ stage is manually invoked to avoid introducing unwanted changes in the production environment. Common practice is to remotely store a state and lock it to prevent concurrent executions against the same state. This operation is supported by Terraform itself by defining a suitable backend. Remote state storage allows seamless collaboration within team members. In addition, when utilizing a cloud computing model and one of the well known service providers, the state is often stored within the object storage.

Exemplary pipeline aimed for automation of two environments staging and production is shown below. Here, the execution environment is a GitLab Runner that controls and processes CI/CD jobs and sends back the results.

Final thoughts

Proper design and organization of the software development process using Continuous Integration concept and supported by automation brings a lot of benefits. It is not only the rise of the efficiency and delivery acceleration but also improved collaboration. Overall it leads to shorter cycles of software development while maintaining quality and security.

Need support in automation? Let us do it in a DevOps way.

Maximizing Efficiency with Dev Containers: A Developer's Guide

Tomasz Fidecki — Mon, 21 Jul 2025 07:00:00 +0000

Part I: The Role of Dev Containers in Modern Development

In the software development landscape we are often dealing with the necessity of not just innovative thinking but change the way we work and build efficient setup of development environments. The deployment blueprint was changed with the rise of containers, bringing in a lightweight and scalable nature, ideal for Kubernetes or cloud services.
At the same time, the development workflow adopted the concept of containerization, with all its benefits, to create an isolated, predictable and transferable development environment. With applying a finite number of steps, one can create an image definition with all dependencies needed, build the image and finally spin up the container.
Visual Studio Code as an open-source code editor with extensive plugin support for development, offers Dev Containers extension enabling developers to use containers as development environments. This way developers can make use of the full feature set of VSC, while introducing a seamless, consistent, and reproducible development experience across any platform. Moreover, as projects grow in complexity, especially in areas like AI/ML, embedded systems, and web development, the need for a consistent, reproducible, and scalable environment becomes even more critical.
In this guide, we will discuss how Dev Containers can transform your development workflow, ensuring consistency, efficiency, and scalability from start to finish.

Reshaping Development: The container approach

Developing inside a container transforms the traditional approach to software development by leveraging the power of Visual Studio Code's Dev Containers extension. This innovative method allows developers to utilize containers not just as a deployment mechanism but as dynamic, fully-featured development environments. By encapsulating the development environment within a container, it abstracts away the underlying operating system and hardware, providing a consistent, isolated, and reproducible workspace.

The core of this approach lies in the devcontainer.json file, a project-level configuration that instructs Visual Studio Code on how to access or construct the development container. This file specifies the container's tool and runtime stack, ensuring that every developer working on the project has an identical setup.

Project files can be seamlessly integrated into the container environment, either by mounting from the local file system or by copying or cloning directly into the container. This integration extends to Visual Studio Code extensions, which are installed and executed within the container, granting them full access to the container's tools, platforms, and filesystems. Consequently, developers can enjoy a rich development experience with features like IntelliSense, code navigation, and debugging, regardless of the location of the tools or code.

The Dev Containers extension offers two primary use cases for containers in development:

As a primary development environment: this model allows developers to use a container as their main workspace, ensuring that all development activities, from coding to debugging, are done within a consistent and containerized environment.
For inspection and interaction with running containers: developers can attach to and interact with containers that are already running, which is particularly useful for debugging, inspecting state, or testing changes in a live environment.

Note that it is totally possible to attach to a container in a Kubernetes cluster with additional Kubernetes extension.

Supporting the open Dev Containers Specification, the extension encourages a standardized approach to configuring development environments across different tools and platforms. This specification aims to foster consistency and portability in development setups, making it easier for teams to collaborate and for individuals to switch projects without the overhead of reconfiguring their development environment.

Enhancing the Concept of Developing Inside a Container with Configuration Files

After introducing the transformative approach of developing inside a container, it's essential to address how this environment may be precisely defined and configured. The heart of configuring Dev Containers in Visual Studio Code lies in the devcontainer.json file, accompanied by Dockerfile and Docker-compose files for a comprehensive environment setup. This trio of configuration files forms the backbone of a Dev Container, ensuring that the development environment is not only consistent but also customizable to project-specific requirements.

Utilizing devcontainer.json for Project-Level Configuration

The devcontainer.json file acts as a project-level guide for Visual Studio Code, detailing how to access or construct the development container. It specifies the container's tool and runtime stack, aligning every developer with an identical setup. This configuration eliminates the common dilemma of "it works on my machine" by standardizing the development environment across the team. Here, you can define settings such as the container image to use, extensions to install within the container, and port forwarding rules for accessing web applications running inside the container.

Leveraging Dockerfile for Custom Environment Setup

While devcontainer.json specifies the environment's configuration, the Dockerfile goes a step further by allowing developers to define a custom image that includes all the necessary tools, libraries, and other dependencies. This file is crucial for projects with specific requirements not covered by existing container images. By customizing the Dockerfile, teams can create a tailored development environment that perfectly fits their project's needs, ensuring that all dependencies are pre-installed and configured upon container initialization.

Orchestrating with Docker-compose for Complex Environments

For more complex setups that involve multiple containers (e.g., a web application that requires a database and a redis cache), Docker-compose files come into play. These files allow for the definition of multi-container Docker applications, where each service can be configured with its own image, environment variables, volumes, and network settings. Incorporating Docker-compose into the Dev Container setup enables teams to mirror their production environment closely, facilitating a smoother transition from development to deployment.

Bringing It All Together

By understanding and utilizing the devcontainer.json, Dockerfile, and Docker-compose files in tandem, developers gain unparalleled control over their development environments. This level of customization ensures that no matter the project's complexity or specific requirements, the development workflow remains streamlined, consistent, and efficient.

Incorporating these detailed configurations within the section on developing inside a container not only enriches the reader's understanding but also showcases the depth of customization and control Dev Containers offer. This addition would reinforce the message that your consultancy is well-versed in the nuances of modern development environments, further establishing trust and expertise in the eyes of potential clients.

Dev Containers and the Power of modern IDE

Dev Containers leverage the power of containerization, specifically Docker, to provide developers with a consistent and portable development environment addressing inconsistencies and inefficiencies in development environments.

Consistency and portability: with Dev Containers, your development environment is defined by a single devcontainer.json file in your repository. This means that every developer working on the project will have the exact same setup. Whether you're working on an AI/ML project in Python without the need for virtual environments, or diving into embedded systems, Dev Containers ensure that everyone is on the same page.
Flexibility: Dev Containers are incredibly versatile. You can use pre-built container images, modify existing ones, or even build your environment from scratch. This flexibility ensures that your environment is tailored to your project's specific needs.
Integration with host machine: one of the standout features of Dev Containers is their ability to integrate seamlessly with the host machine. For instance, in embedded development, while the build process takes place within the container, the resulting files or artifacts are readily available on the host machine, thanks to mounted volumes. This ensures a smooth transition between development and deployment.
Quick onboarding and environment replication: setting up a new development environment can be a time-consuming task, often fraught with installation errors and configuration hiccups. Dev Containers streamline this process, enabling new team members to get up and running with a fully configured development environment in minutes. This ease of replication also extends to deploying environments across different machines, ensuring that every developer works within the same setup, dramatically reducing the time spent on troubleshooting environment-specific issues.
Enhanced productivity with pre-configured workspaces: Dev Containers come with the ability to pre-configure workspaces with the necessary tools, extensions, and settings for your project. This out-of-the-box setup saves developers from the hassle of manually configuring their development environment, allowing them to focus on what they do best: coding. Moreover, these containers can be customized to include additional software or packages specific to your project's needs, further enhancing productivity.
Isolation from the host system: by leveraging Docker containerization, Dev Containers keep your project and its dependencies isolated from your host system. This isolation not only ensures that your project's environment remains clean and uncluttered but also prevents potential conflicts between different projects' dependencies. Moreover, since everything runs within a container, you can experiment with new tools or packages without the risk of affecting your host system's setup.
A catalyst for collaboration: the reproducibility and portability of Dev Containers not only streamline the development process but also enhance team collaboration. With every member of the team working within an identical environment, sharing work, and collaborating on code becomes more straightforward. This uniformity helps in minimizing compatibility issues, making it easier to review and merge code changes.

Limitations of Dev Containers

While Dev Containers offer numerous advantages, it's essential to be aware of their limitations:

Docker dependency: to leverage Dev Containers, Docker must be installed on the machine. This adds an additional layer of setup for developers unfamiliar with Docker.
Device limitations on Windows and MacOS: due to the way Docker operates on Windows and MacOS, there are challenges in passing and using devices, such as USB ports or graphics accelerators.
Potential performance overheads: running within a container might introduce some performance overheads compared to native development, especially when dealing with resource-intensive tasks.
Cost implications: while Docker offers free licensing for personal use, businesses and larger teams might need to consider the pricing options provided by Docker. Depending on the scale and requirements of the project, this could introduce additional costs that need to be factored into the development budget.

Overcoming Dev Container Challenges: Performance and Device Compatibility

While Dev Containers offer a transformative approach to development, certain challenges such as performance overhead and device limitations on Windows and MacOS can affect their efficiency. In this section, we delve into strategies and best practices to mitigate these issues, ensuring a smooth development experience across all platforms.

Mitigating Performance Overhead

Performance overhead, particularly in resource-intensive applications, can be a concern when using containers. However, several strategies can help minimize this impact:

Resource allocation: Docker allows for the specification of CPU and memory limits for containers. Adjusting these settings can ensure that your containerized environment has sufficient resources without overburdening your system.
Volume optimization: for applications that require extensive read/write operations, consider using Docker volumes. Volumes are managed by Docker and can offer better performance compared to bind mounts, especially on Windows and MacOS.
Docker Desktop settings: on Windows and MacOS, Docker Desktop's settings can be tweaked for improved performance. For example, increasing the allocated memory and CPUs in Docker Desktop can significantly enhance the speed of your containers.
Use .dockerignore files: similar to .gitignore, a .dockerignore file can prevent unnecessary files from being built into your Docker context, reducing build time and minimizing potential performance issues.

Navigating Device Limitations on Windows and MacOS

Device limitations, such as accessing USB devices or specific hardware from within a container, can pose challenges, particularly on Windows and MacOS. Here are strategies to work around these limitations:

USB passthrough: while direct USB passthrough might be challenging, solutions like virtualizing the USB device or using network-based USB sharing software can help bridge the gap, allowing containers to interact with USB devices indirectly.
Using Docker Toolbox: for specific use cases, Docker Toolbox on Windows can sometimes offer better hardware interfacing capabilities compared to Docker Desktop, especially for older versions of Windows.
Leveraging network protocols: for devices that can be accessed over the network (e.g., network-attached storage or certain IoT devices), configuring your container to communicate over the network can circumvent direct device access limitations.
Hybrid development environments: for development scenarios that heavily rely on specific hardware, consider a hybrid approach. Use containers for the majority of development tasks but switch to native development environments for tasks requiring direct hardware access.

Real-world Applications of Dev Containers

AI/ML development: with the rise of machine learning, setting up environments with the right libraries and dependencies can be a challenge. Dev Containers simplify this process. For instance, a Python-based machine learning project can leverage a Dev Container with pre-installed libraries like TensorFlow or PyTorch, ensuring that all developers have the same setup without the hassle of virtual environments.
Embedded systems: embedded development often requires specific toolchains and configurations. With Dev Containers, these setups can be encapsulated within a container, ensuring consistency. Moreover, as mentioned earlier, the build process can occur within the container, with the resulting files available on the host machine, streamlining the development-to-deployment pipeline.
Web Development: whether you're working with Node.js, Django, or any other framework, Dev Containers provide a consistent environment for all developers. This ensures that the application behaves consistently across all stages of development.

The Value Proposition for Businesses and Project Leads

For businesses and project managers, the value of Dev Containers is clear:

Efficiency: streamlined setups reduce onboarding time for new developers and eliminate environment-related bugs.
Consistency: ensuring that all developers work in the same environment reduces discrepancies and ensures that the application behaves as expected across all stages.
Scalability: as projects grow, Dev Containers make it easy to update the development environment without affecting individual developers.

Part II: A Comprehensive Developer's Guide to Utilizing Dev Containers

The examples provided below demonstrate the use of Dev Containers across various scenarios, showcasing how this approach can significantly enhance development efficiency. In the following sections, we will outline the workflow for creating readily available Dev Containers, modifying images using a Dockerfile, and exploring a more advanced scenario: attaching Visual Studio Code (VSC) to a container already running within a Kubernetes cluster.

The programming challenge

Imagine we're tasked with developing a Python application. For this example, we'll use a script inspired by an official PyTorch tutorial. This tutorial addresses the challenge of approximating the function y=sin(x) using a third-order polynomial. The model, equipped with four parameters, employs gradient descent to optimize its fit to randomly generated data by minimizing the Euclidean distance between its output and the actual values.

In our adaptation, we'll increase the training iterations to enhance learning accuracy without falling into the trap of overfitting. Given that our container lacks GPU support, computations will be performed solely on the CPU.

# -*- coding: utf-8 -*-

import torch
import math


dtype = torch.float
device = torch.device("cpu")

# Create random input and output data
x = torch.linspace(-math.pi, math.pi, 2000, device=device, dtype=dtype)
y = torch.sin(x)

# Randomly initialize weights
a = torch.randn((), device=device, dtype=dtype)
b = torch.randn((), device=device, dtype=dtype)
c = torch.randn((), device=device, dtype=dtype)
d = torch.randn((), device=device, dtype=dtype)

learning_rate = 1e-6
for t in range(4000):
    # Forward pass: compute predicted y
    y_pred = a + b * x + c * x ** 2 + d * x ** 3

    # Compute and print loss
    loss = (y_pred - y).pow(2).sum().item()
    if t % 100 == 99:
        print(t, loss)

    # Backprop to compute gradients of a, b, c, d with respect to loss
    grad_y_pred = 2.0 * (y_pred - y)
    grad_a = grad_y_pred.sum()
    grad_b = (grad_y_pred * x).sum()
    grad_c = (grad_y_pred * x ** 2).sum()
    grad_d = (grad_y_pred * x ** 3).sum()

    # Update weights using gradient descent
    a -= learning_rate * grad_a
    b -= learning_rate * grad_b
    c -= learning_rate * grad_c
    d -= learning_rate * grad_d

print(f'Result: y = {a.item()} + {b.item()} x + {c.item()} x^2 + {d.item()} x^3')

This script is a practical implementation of linear regression through PyTorch Tensors and the gradient descent method. While the objective is to closely fit a cubic polynomial to the sine wave, the essence of gradient descent remains the same — iteratively refining model parameters to reduce the discrepancy between predicted outcomes and actual data. As the code executes, it will display the loss metrics at each training milestone, culminating in the revelation of the optimized coefficients.

Setting Up and Connecting to the Container

Dev Containers provide a versatile and expansive technology stack, making them ideal for development. For our purposes, we'll opt for a pre-configured Python image maintained by Microsoft, accessible in their repository. Specifically, the Python development containers we're interested in are found under src/python, with a comprehensive list of available images available at location. We'll select the mcr.microsoft.com/devcontainers/python image tagged 3-bullseye. This container comes equipped with Git, various Python tools, zsh, the Oh My Zsh! Framework, a non-root Visual Studio Code (VSCode) user with sudo privileges, and a suite of common development dependencies. For those curious about the construction of the Docker image, further details can be found here.

Moving forward with the setup, we'll first create a .devcontainer folder within the project repository. Within this folder, a devcontainer.json file is created to specify container configuration:

{
    "name": "u11d-devcontainers-example",
    "image": "mcr.microsoft.com/devcontainers/python:3-bullseye",
    "workspaceMount": "source=${localWorkspaceFolder},target=/development,type=bind,consistency=cached",
    "workspaceFolder": "/development",
    "postCreateCommand": "pip install torch==2.2.0 numpy==1.26.4",
    // Configure tool-specific properties.
    "customizations": {
        // Configure properties specific to VS Code.
        "vscode": {
            // Set *default* container specific settings.json values on container create.
            "settings": {
                "python.formatting.provider": "black",
                "editor.formatOnSave": true,
                "python.languageServer": "Pylance",
                "python.analysis.typeCheckingMode": "basic"
            },
            // Add the IDs of extensions you want installed when the container is created.
            "extensions": [
                "ms-python.python",
                "ms-python.vscode-pylance",
                "ms-python.black-formatter"
            ]
        }
    },
    // Container user VS Code should use when connecting
    "remoteUser": "vscode"
}

Once the folder and file are in place, Visual Studio Code (VSCode) will detect them and prompt you to build and open the folder within a container. Alternatively, you can initiate the container by selecting the appropriate action from the command palette (F1) or by opening a remote window through the icon at the bottom left corner of the IDE.

Opening the folder in a container allows for debugging or executing Python code directly within VSCode or via the terminal, offering a streamlined development workflow.

Exploring the devcontainer.json configuration:

This section explores into the devcontainer.json file, a key component in defining the configuration for a development container tailored to Python projects, specifically using the mcr.microsoft.com/devcontainers/python:3-bullseye image. Let's dissect the critical elements of this configuration:

Core Configuration:

name: Optionally names the development container for easy identification.
image: Determines the base Docker image for the container.
workspaceMount: Specifies how the local project folder (${localWorkspaceFolder}) is mounted inside the container (/development).
workspaceFolder: Sets the working directory inside the container. postCreateCommand: Executes a command to install specific Python libraries (e.g., pip install torch==2.2.0 numpy==1.26.4) after container initialization.

VS Code Customizations:

Settings: Adjusts default settings for VS Code within the container, such as:
- python.formatting.provider for selecting the Python code formatter.
- editor.formatOnSave to enable automatic code formatting upon saving.
- python.languageServer and python.analysis.typeCheckingMode for enhanced Python language support.
Extensions: Lists VS Code extensions to be auto-installed in the container, including the official Python extension, Pylance language server, and Black formatter.
Additional Configuration:
- remoteUser: Identifies the user account that VS Code should utilize when connecting to the container (typically vscode).

This setup, which doesn't require profound Docker knowledge, demonstrates fundamental Docker practices like utilizing a pre-made Docker image for a specified development setting (Python 3), seamlessly integrating the local project directory into the container, and executing commands to install additional software within the container. The devcontainer.json file thus offers a streamlined approach to create a consistent and reproducible Python development environment leveraging Docker and VS Code.

For scenarios requiring more complex configurations, the devcontainer.json file allows for the inclusion of a Dockerfile and Docker-compose files, enhancing the container's setup. By incorporating a "build" section, one can direct the file to utilize a specific Dockerfile and define the build context (relative to devcontainer.json file), ensuring that all necessary instructions and files are in place for constructing the Docker image.

{
    "name": "u11d-devcontainers-example",
    "build": {
        "dockerfile": "Dockerfile",
        "context": ".."
    },
    "workspaceMount": "source=${localWorkspaceFolder},target=/development,type=bind,consistency=cached",
    "workspaceFolder": "/development",
    "postCreateCommand": "pip install torch==2.2.0 numpy==1.26.4",
…    
    // Container user VS Code should use when connecting
    "remoteUser": "vscode"
}

This section specifies the instructions and files needed to build a Docker image.

Using a Dockerfile: the "dockerfile": "Dockerfile" part indicates that the build process will use the file named "Dockerfile" located in the same directory as the configuration file. This file contains the commands and instructions to create the image layers.
Building context: the "context": ".." part defines the location of the files and folders that will be available inside the container during the build process. In this case, it specifies the parent directory ("..") of the configuration file. This means all files and folders in that directory (except those ignored by a .dockerignore file, if present) will be accessible to the build process.

Advantages of Utilizing a Custom Dockerfile:

Customized environment: tailor the environment with only the necessary tools and libraries, optimizing image size and efficiency.
Version control: maintain the Dockerfile alongside project code, guaranteeing uniformity and reproducibility.
Enhanced security: gain greater oversight over package sources and the security framework of your development environment.

For further insights on configuring and employing development environments via Dev Containers, consult the comprehensive documentation.

Connecting to a Running Container in Kubernetes

In this section, we'll explore the scenario of connecting to a container that's running within a Kubernetes cluster pod. For demonstration purposes, we're using the Google Kubernetes Engine (GKE) service.

Assume the cluster is operational, and our objective is to deploy a new container equipped with all necessary dependencies to run our Python code effectively. We're elevating complexity by utilizing PyTorch Tensors, capable of leveraging GPU for accelerated computation, and thus, we'll opt for a Google-recommended image encompassing the necessary tech stack.

To adapt our code for GPU acceleration, we'll switch the computation device from CPU to CUDA.

# -*- coding: utf-8 -*-

import torch
import math


dtype = torch.float
**device = torch.device("cuda:0")**

# Create random input and output data
x = torch.linspace(-math.pi, math.pi, 2000, device=device, dtype=dtype)
y = torch.sin(x)

# Randomly initialize weights
a = torch.randn((), device=device, dtype=dtype)
b = torch.randn((), device=device, dtype=dtype)
c = torch.randn((), device=device, dtype=dtype)
d = torch.randn((), device=device, dtype=dtype)

learning_rate = 1e-6
for t in range(4000):
    # Forward pass: compute predicted y
    y_pred = a + b * x + c * x ** 2 + d * x ** 3

    # Compute and print loss
    loss = (y_pred - y).pow(2).sum().item()
    if t % 100 == 99:
        print(t, loss)

    # Backprop to compute gradients of a, b, c, d with respect to loss
    grad_y_pred = 2.0 * (y_pred - y)
    grad_a = grad_y_pred.sum()
    grad_b = (grad_y_pred * x).sum()
    grad_c = (grad_y_pred * x ** 2).sum()
    grad_d = (grad_y_pred * x ** 3).sum()

    # Update weights using gradient descent
    a -= learning_rate * grad_a
    b -= learning_rate * grad_b
    c -= learning_rate * grad_c
    d -= learning_rate * grad_d

print(f'Result: y = {a.item()} + {b.item()} x + {c.item()} x^2 + {d.item()} x^3'

Because our container will be hosted in a deployed Kubernetes cluster then the VSC Kubernetes extension and kubectl command-line tool is needed.

Initial Steps:

Ensure connectivity to the cluster and correct namespace usage with commands like kubectl cluster-info and kubectl get nodes, verifying the cluster's accessibility.

Set context and namespace:

Before deploying resources or executing commands with kubectl, it's a best practice to set both the context and namespace explicitly. The context determines which cluster you're interacting with, while the namespace scopes your operations to a specific area within that cluster. This preparatory step ensures that your commands are executed against the correct cluster and within the intended namespace, reducing the risk of unintended actions. Notably, objects created without a specified namespace are placed in the Kubernetes "default" namespace by default. Relying excessively on the "default" namespace can complicate object segregation and management, as it becomes a catch-all space for various unrelated resources. Properly setting your context and namespace helps maintain a clean, organized cluster environment, facilitating easier resource tracking and management.

# permanently save the namespace for all subsequent kubectl commands in that context
kubectl config set-context --current --namespace ml-experiments

# display list of contexts
kubectl config get-contexts

# display the current-context
kubectl config current-context

Creating a GPU-Enabled Pod:

We aim to create a pod hosting a container on a GPU-enabled node (specifically, an NVIDIA L4 instance). This involves applying a Kubernetes manifest detailing our pod configuration, named ml-runner-gpu within the ml-experiments namespace.

apiVersion: v1
kind: Pod
metadata:
  namespace: ml-experiments
  name: ml-runner-gpu
  labels:
    app: ml-runner-gpu
spec:
  containers:
    - image: gcr.io/deeplearning-platform-release/pytorch-gpu.1-13.py310
      name: ml-runner
      command: ["/bin/sh", "-ec", "tail -f /dev/null"]
      resources:
        limits:
          cpu: 3
          memory: "12Gi"
          nvidia.com/gpu: 1
  tolerations:
    - effect: NoSchedule
      key: nvidia.com/gpu
      operator: Equal
      value: present
  dnsPolicy: ClusterFirst
  restartPolicy: Never

Pod manifest breakdown:

Kind: identifies the resource type as Pod.
Metadata: specifies the Pod's namespace (ml-experiments), name (ml-runner-gpu), and labels for organization.
Containers: outlines the container setup, including the image (gcr.io/deeplearning-platform-release/pytorch-gpu.1-13.py310) equipped with PyTorch and GPU support, and a command to keep the container running.
Resources: defines resource limits, including CPU, memory, and GPU usage.
Tolerations: allows for scheduling flexibility, prioritizing GPU-equipped nodes but permitting scheduling on non-GPU nodes under certain conditions.

This Pod configuration is tailored for deep learning tasks with PyTorch, emphasizing GPU utilization. Despite the indefinite running command, the primary goal is to ensure the container's readiness for development tasks.

Connecting via Visual Studio Code (VSC):

Apply the manifest: kubectl apply -f ml-runner-gpu.yaml
confirm the Pod's active state: kubectl get pods
use VSC to attach to the pod directly. This is achieved by navigating to Kubernetes in VSC, right-clicking the pod, and selecting "Attach Visual Studio Code".

Working with source code:

To work with the Python script inside the container, transfer it via kubectl cp. This places the file in the container's /home directory, ready for execution or modification. kubectl cp pytorch-example.py ml-runner-gpu:/home/

Retrieving modified code:

Post-modification, the script can be copied back to the local machine using a similar kubectl cp command, facilitating easy iteration on the code. kubectl cp ml-runner-gpu:home/pytorch-example.py pytorch-example.py

Cleanup:

Conclude experiments by deleting the Pod via kubectl delete pod ml-runner-gpu, freeing up resources. kubectl delete pod ml-runner-gpu

This approach showcases the capability to leverage remote resources, like GPU acceleration, not readily available locally, enhancing the development and testing of compute-intensive applications.

This container setup not only facilitates the execution of Python scripts but also supports running Jupyter notebooks, thanks to a Jupyter server installed within the container. This addition enhances the container's versatility, allowing for an interactive development environment that's ideal for data analysis, visualization, and testing complex algorithms directly in a IDE interface.

From traditional setups to Dev Containers

Traditionally, setting up a development environment locally involves a series of time-consuming steps:

installing the correct versions of languages, libraries, and tools;
configuring these components to work together; and
ensuring compatibility across team members' machines. This process not only demands a substantial initial investment of time but also ongoing maintenance to keep the environment updated and in sync with project requirements. The complexity escalates with the project's growth, as more dependencies and configurations are required, increasing the potential for discrepancies among team members' environments.

Dev Containers streamline this process by encapsulating the development environment within a container. This approach eliminates the need to manually set up and maintain individual development environments on each developer's machine. Instead, developers can instantly spin up pre-configured containers that mirror the project's exact requirements, ensuring consistency across all team members' environments. This not only accelerates the initial setup process but also significantly reduces the effort involved in onboarding new team members and transitioning between projects. Moreover, Dev Containers abstract away the underlying OS differences, providing additional value by ensuring that the development environment is truly cross-platform and reproducible, regardless of whether the developer is working on Windows, macOS, or Linux.

In essence, the concept of Dev Containers shifts the focus from managing development environments to actual development work, offering a more efficient, consistent, and scalable solution to the challenges of modern software development.

Conclusion

The introduction of Visual Studio Code's Dev Containers marks a pivotal shift in the software development paradigm, simplifying the creation and maintenance of consistent development environments across diverse platforms. By encapsulating development tools and configurations within containers, Dev Containers not only facilitate a seamless transition to cloud-based workflows but also empower developers to focus more on innovation and less on configuration. This breakthrough addresses the unique needs of both solo developers and teams, enhancing productivity, fostering collaboration, and ensuring a stable development experience.

It's important to acknowledge certain limitations, but the advantages they offer significantly overshadow these concerns, positioning Dev Containers as an essential asset in a developer's arsenal.

Embracing Dev Containers goes beyond a simple enhancement; it signifies a fundamental change that lays the groundwork for continuous innovation and progress. Why wait? Explore the transformative potential of Dev Containers and witness firsthand the impact they can have on your projects.

For those seeking to bolster their Docker expertise, our Docker series offers a wealth of knowledge, beginning with strategies to accelerate Docker image builds through efficient cache management. Start enhancing your Docker skills today: Speed Up Docker Image Builds With Cache Management.

For insights into the latest website optimization trends, explore these recommendations.

Templating Values in Kustomize: Unlocking the Potential of Dynamic Naming for Kubernetes Resources

Tomasz Fidecki — Mon, 07 Jul 2025 08:48:18 +0000

In the world of Kubernetes, managing and customizing configurations across multiple environments or instances can be both crucial and complex. Enter Kustomize – a tool that enhances Kubernetes' native configuration management capabilities. Among its many features, one stands out for its potential to significantly streamline and dynamize configuration: the ability to template values using the replacements feature. Though not widely explored, this feature can be a very handy in DevOps life, particularly when it comes to dynamically building resource names and other values within Kubernetes manifests.

Understanding replacements in Kustomize

Before diving into examples, let's understand what replacements in Kustomize are. As detailed in the official documentation, replacements allow you to specify fields from one resource that should be used to replace fields in another. This can include anything from simple value substitutions to more complex scenarios like dynamically building names based on other resource attributes.

This feature opens up a variety of possibilities for making your configurations more flexible and adaptable to different environments, deployment scenarios, or naming conventions.

Dynamic naming with replacements

One of the most compelling applications of the replacements feature lies in constructing dynamic names for resources such as PersistentVolumeClaims (PVCs), ConfigMaps, Deployments, and more. This capability unlocks the potential to not only copy data from a single source manifest into multiple specified targets but also to refine selection with precision. Developers can specify targets using the select field and exclude specific matches by utilizing the reject field. This granularity introduces the flexibility needed to dynamically create manifests.

Let's explore some practical examples.

Example 1: Dynamically named PVCs

Consider a scenario where you have a PVC with a base name and want to append a dynamic segment to it based on the deployment name. For simplicity, let's say our base PVC name is fast-pvc-, and we want to create a naming convention like fast-pvc-{deployment-name}. In addition we want to append to PVC also a namespace from deployment.

Here's how you could achieve this using Kustomize replacements:

Define the base PersistentVolumeClaim in pcv.yaml file.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: fast-pvc-
spec:
  capacity:
      storage: 10Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Recycle
  storageClassName: fast
  resources:
    requests:
      storage: 8Gi

Next create the deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-nginx-deployment
  namespace: ml-experiments
  labels:
    app: nginx
    type: server
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx:1.25.4
          ports:
            - containerPort: 80
          resources:
            limits:
              memory: 512Mi
              cpu: "1"
            requests:
              memory: 64Mi
              cpu: "250m"

Lastly, create a kustomization.yaml file with an additional section that specifies the replacement rules:

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

resources:
  - pvc.yaml
  - deployment.yaml

replacements:
  - source:
      kind: Deployment
      name: my-nginx-deployment
      fieldPath: metadata.namespace
    targets:
      - select:
          name: fast-pvc-
          kind: PersistentVolumeClaim
        fieldPaths:
          - metadata.namespace
        options:
          create: true
  - source:
      kind: Deployment
      name: my-nginx-deployment
      fieldPath: metadata.name
    targets:
      - select:
          name: fast-pvc-
          kind: PersistentVolumeClaim
        fieldPaths:
          - metadata.name
        options:
          delimiter: "-"
          index: 2

This configuration instructs Kustomize to perform two actions:

Extract the metadata.namespace field from the Deployment manifest and replicate it within the PersistentVolumeClaim under the same metadata.namespace field. Notably, the options parameter is specified and set to true, enabling the addition of the field in the target if it is absent. Essentially, the value from the Deployment will either overwrite the existing one or be newly created in the PVC.
Retrieve the metadata.name from a Deployment resource and concatenate it with the metadata.name of the PVC, leading to a dynamically generated PVC name: fast-pvc-my-nginx-deployment. This manipulation leverages optional parameters such as delimiter and index for partial string replacement.

To generate the Kustomize output, use the command below:

kubectl kustomize example-pvc

Please note that in this example, the relevant files are located within the example-pvc directory, and the kubectl command is executed from the parent directory.

The output of kustomize build will be as follows:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: fast-pvc-my-nginx-deployment
  namespace: ml-experiments
spec:
  accessModes:
  - ReadWriteOnce
  capacity:
    storage: 10Gi
  persistentVolumeReclaimPolicy: Recycle
  resources:
    requests:
      storage: 8Gi
  storageClassName: fast
  volumeMode: Filesystem
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: nginx
    type: server
  name: my-nginx-deployment
  namespace: ml-experiments
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - image: nginx:1.25.4
        name: nginx
        ports:
        - containerPort: 80
        resources:
          limits:
            cpu: "1"
            memory: 512Mi
          requests:
            cpu: 250m
            memory: 64Mi

In the context of this example, dynamic naming and namespace adjustments were illustrated using the replacements feature. It's important to highlight that the specific action of namespace replacement serves merely as an example to showcase the versatility of Kustomize. This particular task of adjusting the namespace can also be directly achieved using a tool specifically designed for this purpose within Kustomize. The namespace transformer offers a straightforward method to set or change the namespace for all resources in a kustomization at once, simplifying the process for common namespace adjustments. For more details on this transformer and its usage, please refer to the official Kustomize documentation: Setting the Namespace with Kustomize. As always, developers should choose the most effective tool for their specific configuration needs.

Example 2: ConfigMap values based on deployment environment

Suppose you aim to adjust ConfigMap values based on the deployment's environment (e.g., development, staging, production) and the parameter count of deploying a machine learning model. You can dynamically template these values using replacements.

Define your ConfigMap in configMap.yaml file:

apiVersion: v1
kind: ConfigMap
metadata:
  name: ai-app-config
data:
  environment: ""
  modelVersion: llm--v.05

Create a deployment in deployment.yaml file:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-ai-app
  namespace: ml-experiments
  labels:
    environment: production
    modelParameters: 7B

Define replacements in a separate file, contrasting with the inline method used previously. Create a file named model-replacement.yaml with the following content:

source:
  kind: Deployment
  name: my-ai-app
  fieldPath: metadata.labels.modelParameters
targets:
- select:
    kind: ConfigMap
    name: ai-app-config
  fieldPaths:
    - data.modelVersion
  options:
    delimiter: "-"
    index: 1

Create the kustomization.yaml file as the final step:

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

resources:
  - configMap.yaml
  - deployment.yaml

replacements:
  - source:
      kind: Deployment
      name: my-ai-app
      fieldPath: metadata.labels.environment
    targets:
      - select:
          name: ai-app-config
        fieldPaths:
          - data.environment
  - source:
      kind: Deployment
      fieldPath: metadata.namespace
    targets:
      - select:
          name: app-config
        fieldPaths:
          - metadata.namespace
        options:
          create: true
  - path: model-replacement.yaml

This configuration dynamically updates the ConfigMap's data.environment with the environment label from the Deployment, facilitating environment-specific settings. It demonstrates the use of inline replacements (directly in the kustomization.yaml file) and the capability to define replacements in an external file (model-replacement.yaml), specified by the path field. By leveraging optional delimiter and index fields, it also incorporates the machine learning model's parameter count into the modelVersion value.

Again, to generate the Kustomize output, use the command below:

kubectl kustomize example-configMap

Please note that in this example, the relevant files are located within the example-configMap directory, and the kubectl command is executed from the parent directory.

Kustomize build output this time as as follows:

apiVersion: v1
data:
  environment: production
  modelVersion: llm-7B-v.05
kind: ConfigMap
metadata:
  name: ai-app-config
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    environment: production
    modelParameters: 7B
  name: my-ai-app
  namespace: ml-experiments

Advantages of Dynamic Naming

Implementing dynamic naming and value templating with Kustomize offers numerous advantages for Kubernetes configuration management:

Consistency: Achieves naming consistency across Kubernetes resources, significantly reducing the risk of manual errors and inconsistencies in your deployments.
Automation: Facilitates the automation of deployment processes across varied environments, ensuring that customizations are applied consistently and efficiently.
Flexibility: Enables the modification of configurations dynamically without the need to directly alter the base manifests. This approach enhances the maintainability and scalability of your Kubernetes setup, allowing for easier adaptations as requirements evolve.

Wrapping Up

The replacements feature in Kustomize represents an exceptionally versatile yet underexploited capability within the Kubernetes ecosystem. As demonstrated through the examples of dynamically named PersistentVolumeClaims, ConfigMaps adjusted based on deployment environments, and the incorporation of deployment-specific parameters into ConfigMaps, this feature substantially augments the flexibility and dynamism of Kubernetes configurations.

By applying dynamic naming and value templating, you can more effectively manage and streamline complex Kubernetes environments. This encompasses everything from resource naming and configuration value adjustments to tailoring settings for specific deployment contexts. The ability to precisely control these aspects through Kustomize not only simplifies administrative tasks but also empowers developers and operators with a more resilient and adaptable infrastructure.

As Kubernetes continues to evolve, leveraging advanced features like replacements in Kustomize will be crucial for staying ahead in the fast-paced world of container orchestration. The potential for innovation is vast, and by incorporating these practices into your Kubernetes strategy, you can unlock new levels of efficiency and flexibility in your deployments.

As Kubernetes continues to evolve, the integration of advanced features like replacements in Kustomize becomes crucial, especially for staying at the forefront of container orchestration's rapid development. This is particularly true in fields like machine learning, where deploying and verifying models demand unparalleled efficiency and adaptability. By weaving these practices into your Kubernetes strategy, you're not just enhancing current deployment processes; you're also laying the groundwork for future innovations. This approach ensures that your infrastructure is primed for the dynamic needs of machine learning model deployment and verification, unlocking new potentials for automation and scalability.

We encourage you to experiment with these techniques, explore the capabilities of Kustomize further, and consider how dynamic naming and templating can enhance your Kubernetes projects. The journey towards more agile and responsive infrastructure management starts here.