Sayed Imranali Haffizali

F-2, Kareem manzil, 1 B Main, Ganga nagar Ext, behind HMT Bhavan, Bangalore, 560 012. imran.sayed [at] gmail.com http://www.it.iitb.ac.in/~sayed/ +91 9620266067, +91 8867744657 23rd June 1980. Education
st

M.Tech., Information Technology, KReSIT (now part of CSE), IIT Bombay, 2004. B.E., Computer Science and Engineering, JNEC, Aurangabad University, 2002. All India Rank 145 at GATE 2002 in Computer Science and Engineering. CPI 9.06 out of 10 in M.Tech, Computer Science and Engineering, IIT Bombay.

Academic Achievements

Experience (Overall Experience of 6 years, 8 months) Amazon.com. (Mar 2010 Present); SDE 2 for Amazon Web Services (AWS) Platform. Service Oriented Architecture based Design and Implementation for AWS Platform team responsible Account Management, Billing and Payment System for AWS. Developed Scalable and Highly Available Generic Payment Gateway supporting multiple Payment providers. Designed and Implemented flexible and extendible multi-tiering pricing model for AWS Billing. Nevis Networks,Pune. (August 2004 Mar 2010) Worked on Design and Implementation of a Stream Processing Server on Linux platform using C. Had over seen 5 major releases (version upgrades) for the server with industry standard develop-testintegrate-debug-release cycles. Gained immense insights into software product life cycle having worked on the server, right from first server specifications to 30 major customer deployments. Interacting with and handling server issues at customer deployments for the last 3 years. Skills Fundamentally Problem Solving that proliferates as Software Design. Independently architect server modules and device Data Structures and Algorithms for them. Software Design Patterns. Services Oriented Architecture using Java. System Programming using majorly C for Linux platform and to a lesser extent using C++ for Windows platform. Ajile Software Development DB design for high availability and reliability. Scalable Software Architecture using horizontal and vertical partitioning. Cloud Computing. Using Amazon popular cloud offerings like EC2, S3. Have implemented interfaces to databases MySQL and PostGreSQL. Have exposure to C++, SQL, Python, Perl, PHP, XML, Screening and mentoring junior engineers for last 3 years. Awards Work Details Amazon.com Amazon Web Services (AWS) Platform Team. I work for the Cloud computing business of Amazon.com. The platform team for AWS supports Account Management, Billing and Payment for around half a million AWS Customers and a billion dollar business. AWS is one of most rapidly moving business for Amazon. Increasing Customer adoption is still a one of the key goals for the AWS. The platform needs to keep changing its account management and billing sub-systems to keep up with the dynamic needs of the business. Awarded with Nevis Employee Recognition Award at Nevis in 2007.

Projects worked on 1. Billing with multi-tiered pricing model. Contributed to the design and implementation of multi-tiered pricing for AWS Offerings. The tiering with a special Free Tier led to tremendous increase in customer adoption for AWS. In terms of architecture it needed implementing a fairly complex min-cost algorithm so that the customer is always assured of the lowest possible bill and is not required to do any planning or strategizing for optimizing overall AWS Usage cost. This is useful feature for customer as it takes away worry for cost optimization. 2. Incremental Billing Currently the billing follows a model in which all customer bills to be re-computed every few hours. This model is clearly not scalable and with AWS customer base increasing at rate of 4X every year and pricing model getting more complex ( to provide user multiple flexible usage models ) there is a need for the billing to move to incremental billing. This a fundamental change affecting all billing sub-systems.

3. Integrating AWS Payment System with Amazon.com

Until recently AWS Payments was not integrated with the main Amazon.com Payment and Accounting System. In order for AWS Payments to be able talk to multiple Payment systems ( Amazon.com would be one such payment system), I implemented a Payment Gateway that allows AWS payments to use multiple providers. Since last 2 months the payment sub-system has been successfully interacting with 2 payment distinct payment providers. Nevis Nevis is an exclusively product based startup working in network security and network management domain. The Nevis security offering is an unique combination of Network Admission Control; Identity based Policy Enforcement; End Point Integrity Control and Threat detection using Signatures and Traffic anomaly. Nevis makes Network Switches (hence forth referred as NS) that sit in-line in the network. Along with normal switching operations, NS also acts as sensors for all the network activities. NS conveys network and security information to a central correlation server in the form of binary messages. We refer to these messages as Events and the central server as Event Correlation Server (henceforth referred as ECS). ECS is hosted on a FC4 Linux box. It is implemented entirely in C. It is a massively multi-threaded event stream processor and uses a pipe-lined architecture to process events in parallel. ECS generates reports that range from overall network statistics to specific user statistics. ECS can use either MySQL or PostGreSQL for its archival storage. I am one of the founding members of ECS and have been the principal contact point for all ECS related information and discussions for last two years. Contribution: I have designed and implemented the following components in ECS. ECS Network monitoring module ECS tracks major network hogs, network attackers, popular servers, non-complaint hosts, mis-behaving hosts etc., by monitoring the network activity using events. ECS maintains in-memory hash maps and sorted priority lists to provide a real time view of the network activity. The monitoring module is further divided based on the specific characteristic being tracked. ECS provides major network statistics network administrator via XML. It is also reported to DB in the form of canned reports for forensic and accounting purposes. As these modules deal with events at high rate and huge volume, code efficiency is of para mount importance. ECS Incident Co-relation Module ECS refers security to threats as Incidents. NS has threat detection built-in. As NS sits in-line in the network, it control network logins and network access. NS is capable of deep packet inspection and can detect malicious signatures in network packets. When NS detect suspicious user behavior like login failures, failed connections, too many connections attempts or malicious signature matches in network packet, it alerts ECS by sending appropriate events with threat information. ECS tracks security state of all network hosts. ECS can further correlate this alert information, from one or more NSes, with its own knowledge base. It correlates these evidences to form a concrete security incident and raises alarms for the network administrator. It provides him a detailed view of the threat comprising of the type, sub-type, source, target, time, duration, evidence, severity level of the threat. It can detect network scans, worm outbreaks, network intrusions and denial of service attacks. The most common technique involved is tracking the number of connections and in particular the number of failed connection emancipating from a specific source or ending at a specific destination. ECS Internal Event Generation ECS is an event stream processor. It receives events from multiple NS. In order to sequence these events, ECS timestamps the events on arrival, resulting in a time ordered event stream. It processes the event stream by passing it through

various processing stages. Along with event processing the stages also need to carry out maintenance tasks depending upon the current timestamp in the event stream. ECS generates internal events to trigger these maintenance tasks. These internal events partition the stream into minutes, 15-minutes, and hour and day intervals and hence are referred to as timer events. The fact that intervals are now triggered by events in the stream itself enables ECS to process events off-line, process events in time delayed manner and de-couple system time artifacts. Internal events also trigger server activities like system check point and system shutdown. Implementation of PostGreSQL DB access layer ECS has it own DB access library which provides back-end independent database API to various event processing stages of ECS. Till recently the DB access library itself supported only MySQL. When we decided to also support PostGreSQL for event and report data storage, the DB access layer implementation had to be extended to supporting PostGreSQL C API. The transparent API supports. 1. 2. 3. 4. 5. Connection creation and destruction Unprepared and Prepared Queries Bulk read and write Result set storage Automatic connection maintenance and query retries.

ECS Event Insertion Optimization After the events are processed by various stages, ECS stores these events in standard DBs MySQL or PostGreSQL. The event insertion path also executes many stored procedures to populate auxiliary ECS DB tables, these stores procedures typically end up being the bottle neck in achieving higher event insertion speeds. To scale the number of users and hence the event processing rate of the system, the DB schema and the stored procedures had to analyzed and optimized, the incoming event stream had to characterized. The analysis led to a proposed solution that involved changing primary key order to be more in-line with the incoming data, correcting, adding and dropping database indices, re-phrasing queries to use the more appropriate keys and be in-line with data characteristics, re-writing procedures to be more space and time efficient, addition of newer temporary tables and fine tuning DB parameters. The Event insertion speed scaled by order of 3x from about 1.5 Keps to 5Keps after the optimization drive. This activity turned out to be a good experience in database optimization. Implemented Parallel Event Queries The network administrator can have access to the events and canned reports using DB access layer. However, the database access module was single threaded and not thread-safe and hence cannot be used by multiple administrators at the same time. To allow concurrent administrators, the access layer was upgraded. Connection pooling was implemented; access to connection pool was serialized using mutexes. Static query and result variables were encapsulated in connection structures. Event Relay File API Event Relay is windows service that can receive, gather and transmit events periodically from remote NS to the main ECS in a scheduled manner. I have designed and implemented a lock-less, crash-recoverable, fault tolerant file system for events in Event Relay. The file system exposes a API for the producer and consumers of the events. The Event Receiver module uses the API to store events. The transmitter uses it to read and transmit events. The internal details of the events and the event files are hidden completely within the API. The API does not expect any knowledge about events or the event file structure and the implementation is modular. It could be re-used for any other message store and forward system. Event Gateway I have been updating and maintaining the Event Gateway Subsystem. Its a event buffering sub system that accepts and buffers events before they are processed by ECS processing stages. It is optimized for append operations and uses memory mapped read and write for performance. It is multi threaded and can support one writer and multiple readers. I have upgraded the sub system to include rate limiting, volume control and crash recovery. Other Interests : Sports, Music, Stocks, Movies. Sayed Imranali Haffizali Date 03/08/2011 Bangalore.