<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title><![CDATA[Max Ivashchenko]]></title><description><![CDATA[Personal blog about technology leadership, solutions architecture and performance engineering]]></description><link>https://miva.sh</link><generator>RSS for Node</generator><lastBuildDate>Tue, 14 Apr 2026 00:07:48 GMT</lastBuildDate><atom:link href="https://miva.sh/rss.xml" rel="self" type="application/rss+xml"/><language><![CDATA[en]]></language><ttl>60</ttl><item><title><![CDATA[How to implement security standard? In simple words]]></title><description><![CDATA[Case Overview
Security standards are different and might be complex from implementation perspective. Steps in this article are generic, but in order to make it practical, let’s use PCI DSS as a reference case. PCI DSS is an important standard designe...]]></description><link>https://miva.sh/how-to-implement-security-standard</link><guid isPermaLink="true">https://miva.sh/how-to-implement-security-standard</guid><category><![CDATA[Security]]></category><category><![CDATA[Financial Services]]></category><category><![CDATA[PCI DSS]]></category><dc:creator><![CDATA[Max Ivashchenko]]></dc:creator><pubDate>Sun, 17 Nov 2024 15:07:05 GMT</pubDate><enclosure url="https://cdn.hashnode.com/res/hashnode/image/stock/unsplash/q10VITrVYUM/upload/5c95306e45d20694620825376ac52bfd.jpeg" length="0" type="image/jpeg"/><content:encoded><![CDATA[<h2 id="heading-case-overview">Case Overview</h2>
<p>Security standards are different and might be complex from implementation perspective. Steps in this article are generic, but in order to make it practical, let’s use PCI DSS as a reference case. PCI DSS is an important standard designed to ensure customers' payment card data is stored, processed, and transferred securely. The standard was originally established in 2004 by credit card companies like MasterCard, Visa, Discover, American Express, and JCB. It's important to understand that PCI DSS is not a legal or regulatory requirement, but rather a contractual obligation businesses need to follow when storing and processing debit, credit, and payment card transactions in general. There are 4 compliance levels organized by volumes of transactions processed by business: (L1) 6M+ transactions; (L2) 1M to 6M transactions; (L3) 20K to 1M transactions; (L4) Less than 20K transactions. Cloud can simplify regular PCI DSS audits for infrastructure with existing security controls, compliant services, and products. Cloud service providers focus on security of the cloud, while the customer focuses on security in the cloud, in other words Shared Responsibility Model (ex. <a target="_blank" href="https://aws.amazon.com/compliance/shared-responsibility-model/">AWS</a>, <a target="_blank" href="https://learn.microsoft.com/en-us/azure/security/fundamentals/shared-responsibility">Azure</a> and <a target="_blank" href="https://cloud.google.com/architecture/framework/security/shared-responsibility-shared-fate">GCP</a>).</p>
<h2 id="heading-implementation-steps"><strong>Implementation Steps</strong></h2>
<p>PCI DSS has six directions which requires companies attention: infrastructure security, card data protection, vulnerability management process, robust access control mechanism, regular monitoring and maintaining information security policies. In order to implement proper controls at these directions, there are multiple steps which needs to be done.</p>
<p><strong>Step 1 - Create Artifacts</strong></p>
<p>Organizations need to fully understand their environment, including system and networking architecture diagrams, and data flow documentation. This step is crucial and requires significant resource investment.</p>
<p><strong>Step 2 - Review Scope</strong></p>
<p>Companies must identify their cardholder data environment, including all system components that process, transmit, or store card data directly or indirectly. Components can be excluded if they: 1/ Don't process, transmit, or store card data; 2/ Cannot connect to systems that handle card data; 3/ Are not in the same network (subnet or VLAN);</p>
<p><strong>Step 3 - Define Segmentation and Required Changes</strong></p>
<p>System architecture evolves over time and may have technical debt and inconsistencies with the original design due to various constraints (ex time, budget and scope). Based on identified artifacts and scope, companies can define environment segmentation and boundaries for PCI DSS audit, and determine necessary changes.</p>
<p><strong>Step 4 - Implement Requirements</strong></p>
<p>PCI DSS requirements are practical but require proper interpretation within the assessment scope. Companies should conduct a self-audit using the original standard before proceeding with the formal audit. Cloud services can assist by providing professional guides for implementing specific requirements (ex from <a target="_blank" href="https://d1.awsstatic.com/whitepapers/compliance/pci-dss-compliance-on-aws-v4-102023.pdf">AWS</a>).<br />Education of employees is crucial. Internal trainings and knowledge sharing are great accelerators for future audits.</p>
<h2 id="heading-summary"><strong>Summary</strong></h2>
<p>PCI DSS implementation becomes manageable when approached systematically. The framework's four compliance levels have clear requirements, from comprehensive on-site audits for L1 to self-assessment questionnaires for lower levels. By following these steps, defining timeline and utilizing available cloud resources, organizations can effectively implement the necessary security controls and meet PCI DSS requirements. We’ve used PCI DSS as a reference case, but in general, the steps can be applied to other security standards as well.</p>
]]></content:encoded></item><item><title><![CDATA[Performance Engineering 101 - Introduction]]></title><description><![CDATA[Performance engineering encompasses techniques applied during systems development to ensure non-functional requirements for performance will be met. Unlike traditional testing approaches, it takes a comprehensive view that extends beyond just softwar...]]></description><link>https://miva.sh/performance-engineering-intro</link><guid isPermaLink="true">https://miva.sh/performance-engineering-intro</guid><category><![CDATA[performance-engineering]]></category><category><![CDATA[performance]]></category><category><![CDATA[Performance Optimization]]></category><dc:creator><![CDATA[Max Ivashchenko]]></dc:creator><pubDate>Wed, 23 Oct 2024 22:00:00 GMT</pubDate><enclosure url="https://cdn.hashnode.com/res/hashnode/image/stock/unsplash/sb7RUrRMaC4/upload/fb8271ee91f06d8c63cefafd58b28ef9.jpeg" length="0" type="image/jpeg"/><content:encoded><![CDATA[<p>Performance engineering encompasses techniques applied during systems development to ensure non-functional requirements for performance will be met. Unlike traditional testing approaches, it takes a comprehensive view that extends beyond just software and infrastructure components.</p>
<h3 id="heading-understanding-performance-engineering"><strong>Understanding Performance Engineering</strong></h3>
<p>Performance engineering has evolved into a distinct discipline at major corporations, operating parallel to systems engineering while remaining deeply integrated with information technology organizations. The discipline focuses on three primary metrics: <strong>1/ Response Time</strong>, which measures duration between user request and system response; <strong>2/ Throughput</strong>, which tracks transaction processing rates; <strong>3/ Latency</strong>, which measures delays between request initiation and response;</p>
<h3 id="heading-performance-engineering-lifecycle"><strong>Performance</strong> <strong>Engineering Lifecycle</strong></h3>
<p>The performance engineering lifecycle begins during the conceptual phase, where critical business processes are identified based on revenue value and cost savings. During this initial stage, high-level performance risks are documented, and necessary activities are planned for subsequent phases. In the defining phase, these business processes are decomposed into critical use cases, which are further refined into single-page transitions for script-driven performance testing. This systematic approach ensures comprehensive coverage of all performance-critical components.</p>
<h3 id="heading-engineering-vs-testing-distinction"><strong>Engineering vs Testing Distinction</strong></h3>
<p>Performance engineering takes a broader, more strategic approach compared to performance testing. While testing focuses on specific metrics and scenarios, engineering encompasses the entire system lifecycle. Performance engineering integrates performance considerations from the earliest design phases through to production deployment, whereas testing typically occurs at predetermined points in development.</p>
<h3 id="heading-operational-aspects"><strong>Operational Aspects</strong></h3>
<p>In production environments, performance engineering operates within three crucial domains: <strong>1/ Service level management</strong>, which monitors and validates compliance with performance requirements; <strong>2/ Capacity management</strong>, which ensures systems maintain performance standards through predictive analysis; <strong>3/ Problem management</strong>, which focuses on resolving root causes of performance issues.</p>
<h3 id="heading-monitoring-and-analysis"><strong>Monitoring and Analysis</strong></h3>
<p>A robust monitoring subsystem is essential for validating that systems meet specified performance metrics. This monitoring enables trend analysis, which proves invaluable for predicting when systems might exceed performance requirements due to increasing user loads or growing data sets. Such predictive capabilities allow organizations to budget and deploy resources proactively, maintaining system performance within specified parameters.</p>
<h3 id="heading-business-impact"><strong>Business Impact</strong></h3>
<p>As the connection between application success and business success gains recognition, particularly in mobile applications, performance engineering has taken on both preventive and perfective roles within the software development lifecycle. This evolution reflects the growing understanding that performance directly impacts business outcomes and user satisfaction.</p>
<h3 id="heading-implementation-challenges"><strong>Implementation Challenges</strong></h3>
<p>Modern performance engineering faces complex challenges in managing multiple system components and environments. Engineers must balance performance optimization with other critical requirements while ensuring systems remain scalable and efficient. The discipline requires continuous monitoring and adjustment, as performance characteristics can change significantly as systems evolve and user patterns shift. This comprehensive approach to performance engineering ensures that organizations can build and maintain robust, scalable systems that consistently meet both technical requirements and business objectives. Through careful attention to performance metrics and continuous monitoring, organizations can predict and prevent performance issues before they impact users or business operations.</p>
<h3 id="heading-conclusion"><strong>Conclusion</strong></h3>
<p>Performance engineering isn’t just about fixing problems - it’s about avoiding them altogether. By considering performance early in the development lifecycle, businesses can avoid costly downtime, improve user satisfaction, and create systems that can scale effortlessly as they grow. In a world where every second counts, performance engineering is critical to ensuring smooth, fast, and reliable digital experiences. If you're building a system that users rely on, performance engineering isn't an option - it's a necessity.</p>
]]></content:encoded></item></channel></rss>