For many years, organizations embracing the public cloud knew there were two main types of compute services — customer-managed (i.e., IaaS) and fully managed or Serverless compute (i.e., PaaS). The main difference is who is responsible for maintenance of the underlying compute nodes in terms of OS maintenance (such as patch management, hardening, monitoring, etc.) and the scale (adding or removing compute nodes according to customer or application load). ...

If you give an AI system the ability to act, you give it risk. In earlier posts, I covered how to secure MCP servers and agentic AI systems. This post focuses on a narrower but more dangerous layer: AI skills. These are the tools that let models touch the real world. Once a model can call an API, run code, or move data, it stops being just a reasoning engine. It becomes an operator. ...

The concept of vendor lock-in existed for many years; organizations chose commercial, and in many cases expensive license to use proprietary software products to run their production workloads. In the past, there was the notion that using a product from a well-known vendor was the best solution, due to support, a large customer base, and, as the famous quote says, “Nobody gets fired for buying IBM.” This was all true for decades, but as the software world matured, organizations began migrating workloads to the public cloud and began building modern or cloud-native applications based on open-source alternatives. ...

In the over-evolving tech world, we often see organizations (from C-Level down to architects and engineers) rush to adopt the latest technology trends without conducting proper design or truly understanding the business requirements. The result of failing to do a proper design is a waste of resources (from human time to compute), over-complicated architectures, or under-utilized resources. In this blog post, I will dig into common architecture decisions and provide recommendations to avoid the pitfalls. ...

When organizations used to build applications in the past (mostly on-prem, but also in the public cloud), a common practice for allowing services to authenticate between each other was to create a service account (sometimes referred to as an application account) and embed its credentials in code or configuration files. Another common way to gain access to services was to use static credentials such as keys. To name a few examples — AWS IAM user access keys, Azure shared access signature (SAS) tokens, or Google service account keys. ...

In 2023, I published a blog post titled Sharing Knowledge as a Way of Life, where I suggested that knowledge sharing should become a habit because it helps raise awareness about neglected topics, build community, and enhance your professional reputation. I agree that the technology world keeps changing every day, from new services announced, new capabilities related to AI, new cybersecurity risks, emerging technologies, etc. The question is — how do you keep up with technology, and by doing so, advance your career, remain relevant and attractive in the tech industry? ...

Today, we hear about so many organizations (from small start-ups to large enterprises) experimenting with GenAI applications, adding GenAI components to their existing workloads, and perhaps even moving from evaluation to production. The increased usage of GenAI services requires organizations to pay attention to the cost of using GenAI services before the high and unpredictable cost generates additional failed projects. In this blog post, I will share some common recommendations for implementing FinOps practices as part of GenAI workloads. ...

In part 1 of this series, I have discussed Ingress controllers and Gateway APIs as a way to control ingress traffic into applications deployed on top of a Kubernetes cluster. In the second of this series, I will discuss intra-cluster (East-West) traffic passed through inside a Kubernetes cluster (i.e., between the Pods) and egress traffic outside the Kubernetes cluster. Terminology Before we deep dive into the article, let’s review some important concepts: ...

When designing cloud-native applications and following the Twelve-Factor App methodology “Config” factor, we should separate config from code to ensure portability, scalability, and security. Common configuration variables include: Database connection strings or URLs (DATABASE_URL)​ API keys and external service credentials (API_KEY)​ hostnames, ports, and environment labels (SERVICE_URL, PORT, ENVIRONMENT)​ Caching or message broker endpoints (CACHE_HOST, CACHE_PORT)​ Debugging or logging levels (LOG_LEVEL, DEBUG_MODE) Application configuration services are especially useful when automating a CI/CD pipeline to build and deploy cloud-native applications, allowing us to retrieve configuration from a central repository for different environments as part of an SDLC process, and to revert configuration in case problems are identified. ...